Plenty of malicious outsiders would love to get into our databases. To block them, we simply put up a firewall and make sure no externally facing Web apps allow SQL injections. Instantly, all's well in Databaseland. Right? As long as we don't have any unknown entry points into the network (like unsecured wireless), those two things can indeed keep most of the bad guys at bay.
When you shift your focus to insider threats, things are not so simple. I'll share some other SQL Server security vulnerabilities that you are likely to find in your SQL Server system.
There's a widespread consensus for securing SQL Server. And that is to make sure every database account has a strong password. Alternatively, just use SQL Server 2005 with its "secure out of the box" settings and things are good to go. These set-'em-and-leave-'em database security measures are good starting points. The problem is that they're not practical for reducing a large number of other security risks that many DBAs haven't thought about.
Those vulnerabilities, when exploited by an otherwise trusted user, can lead to a database hack just as easily as a weak password ever could. Plus, other types of SQL Server attacks can fly under the radar of traditional security controls you may have in place.
Here are some not-so-obvious SQL Server 2000 and SQL Server 2005 security vulnerabilities and what they can lead to when exploited by an otherwise trusted system or user on your network:
- Users or groups are granted permission to execute xp_cmdshell, which allows the execution of OS commands they likely shouldn't have access to.
- Remote databases are granted the ability to login and run remote stored procedures on the local database.
- Registry extended stored procedures are enabled, which permit unauthorized reads/writes of the Windows registry, including everything accessible via the Local System account.
- Standard users are granted permission to execute CmdExec and ActiveX scripts, which allows full access to the OS (2000 only).
- Standard users are granted permission to escalate privileges through the SQL Agent. That can facilitate a user running a malicious job via the extended stored procedures to gain full administrator privileges to the database (2000 only).
- PUBLIC group is granted excessive permissions into the database leading to unnecessary database and OS file access such as:
- SELECT and EXECUTE to the data transformation services
- SELECT to the system tables and metadata
- The msdb.dbo.mswebtasks table (2000 only)
- Guest user is enabled allowing unauthorized (or unaudited) access into the database.
- Error log count is set too low, creating a situation where critical logs can be overwritten, which limits database audit trails.
- Logging of success and failure logins is not enabled, limiting database audit trails.
And, last but not least:
- Missing Windows and SQL Server patches allow full remote command prompt access to the database server.
Keep in mind that there are more SQL Server weaknesses you may come across, but the ones I listed here are the ones I see most often.
So, now let's find out how to find these vulnerabilities. One way is to simply step through your SQL Server configurations and compare them to this list. Or, you can use a commercial database vulnerability scanner that performs authenticated audits, such as NGSSquirreL or AppDetectivePro. Other more OS-centric vulnerability scanners, such as Nessus and QualysGuard, can help to an extent as well. I recommend using vulnerability scanners, but if your time and budget are limited, you can still achieve favorable results doing things manually. The CIS Benchmarks are a good resource as well.
Regardless of how you go about it, if you don't identify all of the risks in your SQL Server system, someone else might end up stumbling across them first. Whether they're found by a rogue insider or a security auditor, don't be caught off guard with chinks in your SQL Server's armor.
Kevin Beaver is an 
