Problem solve Get help with specific problems with your technologies, process and projects.

Top hacker tricks to exploit SQL Server systems

Stay one step ahead of attackers by testing your SQL Server systems against some of the most common hacking techniques.

Whether 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 bad guys are doing it, you need to carry out the same attacks to test the security strength of your systems.

Here are nine hacker tricks used to gain access and abuse systems running Microsoft 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). 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. We occasionally hear about such incidents in the media. Nevertheless, these direct attacks can lead to denial of service, buffer overflows, remote control, and more.

2. Uncovering hidden and overlooked systems on the internal network

The bad guys are crafty at not only uncovering default SQL Server installations, but also “hidden” SQL Server instances such as those running on odd ports, located on systems running Windows Firewall or other host-based protection. Chip Andrews' SQLPing is a great tool for finding all live SQL Server systems regardless of the configuration. Many of these non-default systems are overlooked and under-protected, providing the ideal attack scenario for an insider with ill intent. 

3. Vulnerability scanning

Vulnerability scanning often reveals weaknesses in the underlying operating system (OS), the Web application or the database system itself. Everything from missing SQL Server patches to Internet Information Services (IIS) configuration weaknesses can be uncovered by attackers, compromising the database server.

The bad guys may use open source, home-grown or commercial vulnerability scanners. 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 or Rapid7 (for general scanning), Acunetix Web Vulnerability Scanner or WebInspect (for Web application scanning) and NGSSquirrel for SQL Server or AppDetectivePro (for database-specific scanning). They're easy to use, offer the most comprehensive assessment and, in turn, provide the best results.

4. Cracking passwords

Deciphering Software Assurance and Windows domain passwords is also used by attackers to get into SQL Server systems. In many cases, cracking is not needed since no password has been assigned, providing yet another use for the handy-dandy SQLPing tool mentioned earlier. AppDetectivePro, NGSSQLCrack, and SQLdict -- the freebie tool that’s also packaged in the BackTrack toolset -- also have this capability. Furthermore, if physical access is available, an attacker can use a tool like Proactive System Password Recovery to gain control.

5. Direct-exploit attacks

Direct exploitation tools such as Metasploit  can be used to exploit certain vulnerabilities found during normal scanning. This is typically the silver-bullet hack for attackers because it can lead to complete remote access of the server and database environment with full administrative rights.

6. SQL injection

SQL injection attacks are executed via front-end Web applications that don't properly validate user input. SQL queries can be inserted directly into Web URLs and forms which can return informative errors that lead to enumeration of the SQL Server environment, and eventually, full database access. These attacks can be carried out manually if you have a lot of time, but it’s much wiser to use automated tools to your advantage.

Once you discover that a server has a SQL injection vulnerability using a Web application vulnerability scanner, you can use an automated SQL injection tool such as Absinthe or the SQL Injector tool built into WebInspect to carry out the process.

7. 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 and how you can use them to root out SQL Server vulnerabilities.

8. 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 (GHDB). (Look in the sections titled, Error Messages and Files containing passwords.)

The bad guys 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 website names via Google's 'site:' operator often turns up juicy info you never imagined you could unearth. The same concept can be carried out using text/PII search tools, such as FileLocator Pro and Identity Finder on network shares inside the network as discussed in this article on unstructured information.

9. Perusing website source code

Source code can also turn up information that may lead to a SQL Server break-in. Specifically, hard-coded SQL Server configuration and authentication information may be stored in ASP scripts, Flash files, etc. for simplicity’s sake. Through a manual assessment, using Google or a tool such as SWFScan you can uncover this information quickly and easily.

Kevin Beaver (CISSP), is an information security consultant, expert witness, as well as a seminar leader and keynote speakerwith Atlanta-based Principle Logic, LLC. Kevin can be reached at

Dig Deeper on SQL Server Security