If you're performing a penetration test or higher-level security audit of your SQL Server systems, there's one test you must not miss. It seems obvious, but many people overlook it: SQL Server password testing. Given the inherent weaknesses compared with more secure Windows authentication, you should especially test for password flaws if you're using SQL Server authentication in mixed mode. Password testing will help you determine how easily others can break into your database and help you ensure SQL Server users are being responsible with their accounts.
To get things rolling, you need to determine which systems are available to test. You may know your environment like the back of your hand, but it doesn't hurt to ferret out servers you may have forgotten or those someone else connected to the network. You should at least run SQLPing2, but I highly recommend SQLRecon to find SQL instances you might not otherwise be able to discover. Both tools are downloadable at Chip Andrews' site.
In the figure below, you'll see how SQLPing2 discovered various SQL Server systems and determined that one of the systems has a blank sa password. This is SQL Server password cracking at the most basic level.
SQLPing2: Discovering a blank sa password
SQLPing2 can also run dictionary attacks against SQL Server. This is as simple as loading your own user account and password lists, as shown in the following figure.
SQLPing2: Running dictionary attacks
Another free tool, Cain and Abel, allows you to dump and crack SQL Server hashes, as shown in the following figure:
Cain and Abel: Dumping and cracking SQL Server hashes
On the commercial side, NGSSoftware's NGSSQLCrack product is a good tool for performing both dictionary and brute-force password cracking. There's also Application Security's AppDetective, which comes with built-in password cracking functionality as shown in the following figure:
AppDetective: Built-in password cracking
It's important to remember that SQL Server password cracking shouldn't be taken lightly. Treat this as a formal penetration test or audit and get the approval of management and carefully plan things out. You don't want to create trouble. Speaking of that, there are a few downsides to password cracking to keep in mind:
- Password cracking can eat up valuable system resources including CPU time, memory and network bandwidth literally to the point of creating a denial-of-service attack on the system.
- Dictionary and brute-force attacks can take a lot of time -- something you may not have, especially if you can only test your systems during a certain window of time.
- Dictionary attacks are only as good as the dictionary you're using, so make sure you've got reliable dictionaries at your disposal. I have found the following to be good resources:
Finally -- and perhaps most importantly -- make sure you follow up on your findings. That may mean sharing your findings with upper management, tweaking your password policy and making others aware that they need to be more security conscious.
About the author: Kevin Beaver is an independent information security consultant, author and speaker with Atlanta-based Principle Logic, LLC. He has more than 18 years of experience in IT and specializes in performing information security assessments. Kevin has written five books including "Hacking For Dummies" (Wiley), "Hacking Wireless Networks For Dummies," and "The Practical Guide to HIPAA Privacy and Security Compliance" (Auerbach). He can be reached at kbeaver@principlelogic.com.
More information from SearchSQLServer.com
Tip: Ten hacker tricks to exploit SQL Server systems
Tip: Tool to configure and lock down SQL Server services
Tip: Using Metasploit for real-world security tests
