How are your SQL Server systems standing up to security exploits these days? Are they current with patches? Have they been hardened from the elements? What about passwords – do they meet reasonable complexity requirements and are they changed periodically? Is audit logging enabled?
If you can answer "Yes" to most of these questions then you might assume that everything's hunky dory. In fact, many people would look at such an environment and say the same. Unfortunately, this is rarely the case.
You'd be surprised by how many "audited" and "compliant" SQL Server systems I see that are actually riddled with security flaws waiting to be exploited. It's the curse of the checklist audit where everything's sound and secure at 50,000 feet but once you dig in you start seeing the ugly truth. The following are examples of SQL Server security oversights that can get you in a world of hurt pretty quickly:
- Servers with their C: drives shared out – literally. I often see the C$ share on SQL Server systems providing full share and NTFS access to the 'Everyone' group. If SQL Server is not started, the master.mdf file is accessible, which is all that's needed to crack or reset any/all SQL Server passwords using a tool like Elcomsoft's Advanced SQL Password Recovery.
If SQL Server is started, odds are pretty good that another vulnerability (weak Windows passwords or a missing patch, for example) is all it'll take for an attacker to gain full access to the system and SQL Server.
- Unprotected disk images (such as Acronis TrueImage .tib files) and basic folder-level backups of entire SQL Server systems sitting on servers and storage systems. It's a problem related to the point above – unsecured share and NTFS permissions. Again, master.mdf and all of SQL Server are fair game.
- Unprotected instances of SQL Server Express and MSDE running on workstations. These seemingly unimportant databases actually house very important data that shouldn't be exposed to insiders. The only way to find all the live SQL Server systems on your network is to use a good vulnerability scanner such as QualysGuard or LANguard.
An even simpler method is to use the SQLPing3 tool which is made for not only seeking out default SQL Server installations, but also uncommonly-configured or otherwise locked-down SQL Server instances.
- Web applications that are not properly validating input and facilitating SQL injection. Even the most secure SQL Server controls can't ward off this attack. In a recent Web application security assessment, I came across a SQL injection exploit that provided full and complete access to an otherwise rock-solid SQL Server environment -- effectively negating most database security controls.
There are endless ways to exploit a seemingly secure SQL Server system The reality is that the higher-level audits commonly performed on SQL Server are missing the boat. You've got to look at every level if you want true visibility into the security status of your databases.
From the OS to the Web application and everything in between, you've got to consider all the variables. Otherwise you may look good to the auditors and the regulators, but you're only setting yourself up for failure.
ABOUT THE AUTHOR
Kevin Beaver, is an information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC. Kevin specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security on Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at email@example.com.