SQL Server password management: Six risky assumptions

There are several risky assumptions about SQL Server passwords that can get you into a bind quite easily. Here's what not to assume:

1. Basic password testing requires no planning.
   It's a big mistake to just start cracking away at SQL Server passwords when testing. Whether you're doing it locally or across the network (which is much slower), I highly recommend obtaining permission and having a fall-back plan when/if accounts start getting locked. The last thing you want is to have database users unable to do their jobs or applications not working properly because accounts are locked.

2. Your passwords are safe going across the wire.
   For mixed-mode implementations of SQL Server, you could easily use a network analyzer such as OmniPeek or Ethereal to grab passwords right off the wire (or out of thin air in the case of wireless). Cain and Abel can also be used to glean TDS-based passwords. Running switched Ethernet that's immune to network sniffing? Cain's ARP poison

   More on SQL Server Security: FAQ: SQL Server passwords  Tip: Software security tools to improve your skills in a single day

   routing "feature" can take care of that. Within a minute or so, anyone using this free tool can make your Ethernet switches behave like hubs and see all internal traffic on the local network segment facilitating the capture of passwords.

The issues don't stop here. There's a misnomer that using Windows authentication in SQL Server, equals better security. Not true. These same tools can be used to glean Windows, Web, email and related passwords right off the network as well -- all of which very likely tie right back to SQL Server access.

3. There's no need to test your passwords -- you have a password policy.
   Regardless of how stringent your password policy may be, there will always be a gap that provides some way around it. Be it a misconfigured server, a host outside your Windows domain, an unknown SQL Server installation or some fancy tool that can crack even the strongest passwords -- something is bound to introduce password weaknesses and effectively nullify your password policy.

Just as important, never rely on the results of a checklist audit that says your database is secure because strong passwords are being used. Always take your testing to the next level and actually verify whether or not weaknesses exist. Even if you think all is well, you'll likely uncover something predictable.

4. SQL Server passwords aren't recoverable, so why try to crack them if I know they're strong and secure?
   Actually, you can recover SQL Server passwords! In SQL Server versions 7 and 2000, you can recover the password hashes using a tool such as Cain and Abel or the commercial product NGSSQLCrack and then run a dictionary or brute-force attack against them. These tools allow you to dump and then reverse engineer the SQL Server password SHA hashes. Your cracking results aren't guaranteed, but it's a weakness nonetheless.
5. You've used MBSA to check for SQL Server password flaws and nothing serious turned up.
   Microsoft Baseline Security Analyzer is a great starter tool for rooting out SQL Server vulnerabilities, but it's by no means comprehensive -- especially in the password cracking department. For more in-depth SQL Server and Windows password cracking, turn to third-party tools, such as the free SQLat and SQLninja tools (available in BackTrack) as well as Windows-centric password cracking tools such as ElcomSoft's Proactive Password Auditor and Ophcrack.

   Again, just because you're using Windows authentication in SQL Server, it doesn't mean you still don't have password weaknesses. Someone with a little bit of time and know-how can crack Windows passwords and own the entire network -- especially if they're using Ophcrack's LiveCD against a physically-unsecured Windows host like a laptop or easy-to-access server.

6. You only need to worry about your main database servers.
   It's easy to focus on your bread and butter SQL Server systems, but don't forget about MSDE, SQL Server Express and other random SQL Server installations you likely have across your network. Some or all of them may be using unsecured defaults or have no password requirements at all. Use a tool such as SQLPing 3 to track down these "rogue" database servers on your network. You'll likely be surprised at what you uncover.

As with anything else in IT, it's always the little stuff that gets you. Ditch these dangerous SQL Server password assumptions and oversights and you'll undoubtedly improve your SQL Server security.

ABOUT THE AUTHOR:

Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has more than 18 years of experience in IT and specializes in performing information security assessments revolving around compliance and IT governance. Kevin has authored/co-authored six books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley) as well as The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He also created the Security On Wheels audiobook series. Kevin can be reached at kbeaver ~at~ principlelogic.com. Copyright 2007 TechTarget