This excerpt is from SQL Server Security, written by David Litchfield and published by McGraw-Hill/Osborne Media. Read the entire chapter here.
Database servers are a soft target for hackers even though they should be the most secure boxes within an organization's IT infrastructure. Customer information, human resources data -- pretty much everything that lends itself to the continued success of the organization is stored in its database. Yet the one place that's designed to keep this information safe and accessible is the thing that ends up allowing the data to be compromised. How is Microsoft SQL Server hacked? The answer to this question depends on by whom, why, and where the hacking is done.
It's a well-known fact that most attacks occur from the "inside" by people who have already been given access. The way this kind of person, be they a disgruntled employee or an industrial spy, attacks a SQL server usually is completely different from the way an "outsider" approaches an attack. Defending against "insider" attacks can be extremely difficult; if the SQL Server DBA has a chip on their shoulder, then there's not a lot that can be done to prevent a successful attack. Ensuring that offsite daily backups occur can help mitigate the risk, but prevention is obviously better than a cure. "Outsider" attacks are considerably easier to mitigate. Keep in mind that offsite backups can also represent a physical security threat if they are not handled properly. They only mitigate the threat of data tampering or loss, not the theft of data or data tampering.
Attacks fall pretty much into two categories: exploitation of software vulnerabilities and exploitation of configuration issues. Keeping a system patched helps to mitigate the first category, and following best practices helps to mitigate the second category. But patching a system is no easy or fast task. Before patches can be applied, they must be fully tested to ensure they are not going to cause problems like applications breaking—this can take time and gives the potential attacker a window of opportunity in which to take advantage of a new vulnerability. In addition, SQL Server patches (not service packs) usually do not include an installer and thus require manual file copying and script execution on every instance of SQL Server installed on the machine. Remediation of configuration issues can be problematic, too. SQL Server comes installed with a set of default permissions, and even following published best practices can leave holes.
The best way to defend a computer system is to learn how it is attacked. While unsolicited attacking of computer systems is not condoned, learning about the techniques of attack is essential. One of the vulnerabilities demonstrated in this chapter is the very one that spawned the SQL Slammer worm, so keep in mind the damage that can be caused when people abuse this type of information. This chapter covers both software vulnerabilities and configuration issues, but it must be stressed that new issues are being discovered weekly in both areas and vigilance is the best way to counter this. SQL Server administrators should periodically check the Microsoft Security Site for new SQL patches and should be subscribed to a good security mailing list such as Bugtraq or NTBugtraq.
Picking the right tools for the job
Before any job is undertaken, be it grouting the shower or paving a patio, a lot of unnecessary grief can be avoided by getting the right tools beforehand. Attacking a computer system is no different. As far as compromising Microsoft SQL Server is concerned, the tools of the trade are a combination of the SQL Server client tools, such as Query Analyzer, SQLPing and a C compiler. One of the most important tools is a copy of SQL Server itself. It's far better to examine vulnerability and then code an exploit for it on a system in the lab than to experiment on the live target system.
Although SQL Server is generally good at handling exceptions and remaining up, there are some areas where an access violation will bring the server down, which generally is not a good thing. Further, for every exception raised and caught, an entry is added to the Application Event Log, again something that should be avoided where possible if the attacker wants to avoid raising alarms. If the attacker is intent upon breaking into the SQL server, and it's fully patched, then they may need to discover their own new vulnerability. Having access to the server software, in this scenario, is an absolute must. A good decompiler, such as Datarescue's IDA Pro, helps enormously too, where stress testing turns up nothing and one must turn to reverse engineering. Finally, a network capture tool (sniffer), such as NGSSniff or Ethereal, is enormously handy on occasion, too.
The author's SQL Server toolkit consists of the following:
- MS SQL Server 2000, Developer Edition
- MS SQL Client tools such as Query Analyzer and odbcping
- Microsoft Visual C++
In addition to these, there are the author's own tools created using the compiler. You never know what you're going to need in any attempted penetration, so the compiler provides a method to create new tools on the fly. Some of the tools listed above will be discussed throughout various sections of this chapter.
Read the entire chapter here
For More Information
- Feedback: E-mail the editor with your thoughts about this tip.
- More tips: Hundreds of free SQL Server tips and scripts.
- Tip contest: Have a SQL Server tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize -- submit your tip today!
- Ask the Experts: Our SQL, database design, SQL Server, DB2, and data warehousing gurus are waiting to answer your toughest questions.
- Forums: Ask your technical SQL Server questions--or help out your peers by answering them--in our active forums.
- Best Web Links: SQL Server tips, tutorials, and scripts from around the Web.