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.
For more information on this topic, visit these resources:
- Article: Top 10 SQL Server security blunders
- Tip: SQL Server security
- Tip: Preventing SQL injections
This was first published in September 2003