How to Hack Databases: Hunting for Microsoft's SQL Server

Welcome back, my fledgling hackers!

The database is the hacker's "pot-of-gold," as it contains information that is very valuable to both the business and the hacker. In this, the second of my series on hacking databases, we're on the "hunt" for Microsoft's SQL Server.

Although far from the most commonly used database (Oracle hold's that title), Microsoft's SQL Server is very often found in small-to-medium sized businesses. Even a few big businesses use it.

These businesses are most ripe for hacking as they often have little in the way of security defenses and very often no dedicated security staff, unlike Oracle databases, which are often found in the richest environments (large corporate and financial institutions) with more security.

Before we can hack SQL Server, we need to able to find it. In this tutorial, I will show you some ways to find the servers that house the SQL Server database. Remember, reconnaissance is critical in hacking. We could spend hours teaching you how to hack SQL Server, but if you can't find it, well... it's all just wasted time.

Step 1: Scan for SQL Server with Nmap

Nmap is an excellent scanning and reconnaissance tool, one that I've showcased before here on Null Byte in my guide on conducting active recon and DOS attacks. So, if you want to brush up, make sure to check that out.

Nmap can help us find MS SQL Server instances, as well. We know that SQL Server runs on port 1433 over TCP. This port is unique to MS SQL Server as other databases use other ports. For example, MySQL uses TCP port 3306. So, we scan scan our target network for open port 1433 with an nmap version scan (-sV).

• nmap -sV -p 1433 192.168.1.0/24

• -sV tells nmap to do a version scan
• -p tells nmap what port to scan for
• 192.168.1.0/24 designates the class C network (in CIDR notation) that we're scanning

Notice in the screenshot above that I've highlighted the output from nmap where it has found an open port on 1433. Not only does nmap find and report the port as open, but it also tells us that Microsoft's SQL Server 2000 is running on it and provides us the version and service pack.

Step 2: Find Those Hidden Database Servers

Astute network managers and security engineers will often run services over non-default ports to deter hackers. Just because a machine does not show port 1433 open does not necessarily mean that it's not running SQL Server.

We know that SQL Server Browser service runs on port 1434 over UDP (this enables external users to connect to the database). Usually, if the network admin changes the default port, they will leave the Browser service on port 1434 as it's far more complex to change it.

We can use nmap to find these hidden SQL Server instances by scanning the network for open port 1434 running UDP. We can do this by typing:

• nmap -sV -sU -n -p 1434 192.168.1.0/24

• -sU tells nmap to scan UDP ports

Notice here that nmap found another hidden instance of SQL Server version 10 (SQL Server 2008) running on port 6666! Since this is the newer SQL Server, it's likely that this company is storing its valuables on this server and not on the older SQL Server 2000. In fact, the SQL Server 2000 might be a honeypot meant to entrap hackers, so be careful here!

Step 3: Use Metasploit's Tool for Locating SQL Server

Although nmap is an excellent general purpose scanning tool, Metasploit has a tool specifically designed to find instances of MS SQL Server named msql_ping. It's found among the auxiliary modules in Metasploit. Remember, Metasploit has exploit modules, auxiliary modules, post exploitation modules, payload modules, encoder modules, and nops modules.

To use mssql_ping, we first need to load Metasploit. We can do this by typing in a terminal:

• >msfconsole

Once Metasploit opens up (be patient, it loads slowly), we can simply tell Metasploit to use this module by typing:

• msf> use auxiliary/scanner/mssql/mssql_ping

Once we have successfully loaded this module, we next need to tell Metasploit the nework we want to scan:

• set RHOST 192.168.1.0/24

Then the number threads we want to run:

• set THREADS 50

And then, finally, tell Metasploit to run the exploit:

• run

As we can see, mssql_ping found BOTH of the MS SQL Server instances on this network that nmap found through two scans, and it also gave us detailed information on the ServerName, the InstanceName, the version number, and what TCP port the database service is running on.

With the version information in hand, we can then identify vulnerabilities and other flaws in the database software. Among other places, we can go to the SecurityFocus database to search for vulnerabilities and exploits of these database instances.

Now that we know what machines house the MS SQL Server instances, we can move on to actually hacking those databases, so keep coming back as we go after that pot of gold!