Whether it is through manual poking and prodding or the use of security testing tools, malicious attackers employ a variety of tricks to break into SQL Server systems, both inside and outside your firewall. It stands to reason then, if the hackers are doing it, you need to carry the same attacks to test the security strength of your systems. Here are 10 hacker tricks to gain access and violate systems running SQL Server.
1. Direct connections via the Internet
These connections can be used to attach to SQL Servers sitting naked without firewall protection for the entire world to see (and access). DShield’s Port Report shows just how many systems are sitting out there waiting to be attacked. I don’t understand the logic behind making a critical server like this directly accessible from the Internet, but I still find this flaw in my assessments, and we all remember the effect the SQL Slammer worm had on so many vulnerable SQL Server systems. Nevertheless, these direct attacks can lead to denial of service, buffer overflows and more.
2. Vulnerability scanning
Vulnerability scanning often reveals weaknesses in the underlying OS, the Web application or the database system itself. Anything from missing SQL Server patches to Internet Information Services (IIS) configuration weaknesses to SNMP exploits can be uncovered by attackers and lead to database server compromise. The bad guys may use open source, home-grown or commercial tools. Some are even savvy enough to carry out their hacks manually from a command prompt. In the interest of time (and minimal wheel spinning), I recommend using commercial vulnerability assessment tools like QualysGuard from Qualys Inc. (for general scanning), WebInspect from SPI Dynamics (for Web application scanning) and Next Generation Security Software Ltd.’s NGSSquirrel for SQL Server (for database-specific scanning). They’re easy to use, offer the most comprehensive assessment and, in turn, provide the best results. Figure 1 shows some SQL injection vulnerabilities you may be able to uncover.
Figure 1: Common SQL injection vulnerabilities found using WebInspect.
3. Enumerating the SQL Server Resolution Service
Running on UDP port 1434, this allows you to find hidden database instances and probe deeper into the system. Chip Andrews’ SQLPing v 2.5 is a great tool to use to look for SQL Server system(s) and determine version numbers (somewhat). This works even if your SQL Server instances aren’t listening on the default ports. Also, a buffer overflow can occur when an overly long request for SQL Servers is sent to the broadcast address for UDP port 1434.
4. Cracking SA passwords
Deciphering SA passwords is also used by attackers to get into SQL Server databases. Unfortunately, in many cases, no cracking is needed since no password has been assigned (Oh, logic, where art thou?!). Yet another use for the handy-dandy SQLPing tool mentioned earlier. The commercial products AppDetective from Application Security Inc. and NGSSQLCrack from NGS Software Ltd. also have this capability.
5. Direct-exploit attacks
Direct attacks using tools such as Metasploit, shown in Figure 2, and its commercial equivalents (CANVAS and CORE IMPACT) are used to exploit certain vulnerabilities found during normal vulnerability scanning. This is typically the silver-bullet hack for attackers penetrating a system and performing code injection or gaining unauthorized command-line access.
Figure 2: SQL Server vulnerability exploitable using Metasploit’s MSFConsole.
6. SQL injection
SQL injection attacks are executed via front-end Web applications that don’t properly validate user input. Malformed SQL queries, including SQL commands, can be inserted directly into Web URLs and return informative errors, commands being executed and more. These attacks can be carried out manually — if you have a lot of time. Once I discover that a server has a potential SQL injection vulnerability, I prefer to perform the follow-through using an automated tool, such as SPI Dynamics’ SQL Injector, shown in Figure 3.
Figure 3: SPI Dynamics’ SQL Injector tool automates the SQL injection process.
7. Blind SQL injection
These attacks go about exploiting Web applications and back-end SQL Servers in the same basic fashion as standard SQL injection. The big difference is that the attacker doesn’t receive feedback from the Web server in the form of returned error messages. Such an attack is even slower than standard SQL injection given the guesswork involved. You need a good tool for this situation, and that’s where Absinthe, shown in Figure 4, comes in handy.
Figure 4: Absinthe tool takes the pain out of blind SQL injection testing.
8. Reverse engineering the system
The reverse engineering trick looks for software exploits, memory corruption weaknesses and so on. In this sample chapter from the excellent book Exploiting Software: How to Break Code by Greg Hoglund and Gary McGraw, you’ll find a discussion about reverse engineering ploys.
9. Google hacks
Google hacks use the extraordinary power of the Google search engine to ferret out SQL Server errors — such as “Incorrect syntax near” — leaking from publicly accessible systems. Several Google queries are available at Johnny Long’s Google Hacking Database. (Look in the sections titled Error Messages and Files containing passwords.) Hackers use Google to find passwords, vulnerabilities in Web servers, underlying operating systems, publicly available procedures and more that they can use to further compromise a SQL Server system. Combining these queries with Web site names via Google’s ’site:’ operator often turns up juicy info you never imagined you could unearth.
10. Perusing Web site source code
Source code can also turn up information that may lead to a SQL Server break in. Specifically, developers may store SQL Server authentication information in ASP scripts to simplify the authentication process. A manual assessment or Google could uncover this information in a split second.
