When managing internal SQL Server accounts and passwords, it's easy to assume that everything is reasonably secure. After all, your SQL Server systems are behind the firewall, you're forcing Windows authentication and all users are required to have a strong password. Sounds pretty secure -- especially since you're thinking everyone else is doing it, right? Well, not so much.
There are several risky assumptions about SQL Server passwords that can get you into a bind quite easily. Here's what not to assume:
- 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.
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
- 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.
- 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.
- 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.
- 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.
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.
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.
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