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
- NGSSniff
- NGSSQLCrack
- NGSSQuirreL
- 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.
