Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Direct Attacks
Now that you understand the basics of SQL commands and the requirements that must be met for a client to make a database connection, let's take a look at how a hacker can abuse these technologies for his own purposes. Like many other computer-based technologies, it is often not the product that is at fault; instead, the fault lies in the implementation.
Every SQL server application has a default administrator account. This account is used by the database administrator to set up databases, create user accounts, assign permission, and more. However, when a database server application is installed, this account must have a default password so that the database administrator (DBA) can access the database software for required setup and configuration tasks. The following is a list of the most common database applications and their default DBA accounts:
|
Name |
User |
Password |
|
Oracle |
sys |
oracle |
|
mySQL (Windows) |
root |
null |
|
MS SQL Server |
sa |
null |
|
DB2 |
dlfm |
ibmdb2 |
This list of usernames/passwords is not complex and can be found at any number of Web sites. For this reason, one of the first tasks a DBA is urged to perform when setting up and configuring the SQL server is to assign a strong password to the database program administrator account (root, sa, sys, dlfm). Unfortunately, this is often completely ignored or procrastinated until it is forgotten. In other words, any hacker who stumbled upon this server connected to the Internet could completely own the data on it—and perhaps the network to which the server is attached.
In addition to a lack of passwords, many DBAs use weak passwords that can be found in a dictionary, that are short (less than six characters), or that are common names, places, or events. These databases are also sitting targets for almost any hacker that detects the SQL server software via a port scan. As we will next illustrate, using programs, a hacker can simply throw passwords at the SQL server until it cracks. If the password is missing or is weak, it will be only a matter of minutes before he has access to the data. The following illustrates how a hacker would first probe for and subsequently attack a SQL server.
Finding a SQL server is a simple task. It merely takes a properly configured port scanner or a scripted SQL scanner, to create a list of targets. For example, SQLScanner, which is a program available online (included in the SQLTools suite), allows a hacker to scan tens of thousands of computers at one shot looking for MS SQL Servers. (See Figure 1.)
)
Figure 1 SQLScanner probing for SQL servers on the Internet.
Once a hacker has a list of targets, the next step is to probe each server for more information about the version, port, and method by which it accepts incoming requests. Figure 2 illustrates the program SQLPing, which is also part of the SQLTools suite.
)
Figure 2 SQLPing gathering information on a potential target.
This program tells the hacker how to connect to the database and what methods may or may not work. In addition, it provides the SQL server's name, which can be handy when guessing passwords and determining the purpose of the server.
Next, a hacker probes the SQL server for weak accounts. Using a program such as SQLDict or SQLCracker (also included with the SQLTools suite), a hacker can quickly and systematically take a dictionary file and test the strength of a SQL server. Unfortunately, a scan lasting no more than five minutes often returns some positive results.
Once a hacker has access to a DBA account, or even a normal user account, the next step is to use that username and password to connect to a database server and take ownership of that data. In other words, this hacker can now download, updated, and delete data at his whim. This type of control may not come as a surprise, but were you aware that a database account can also give a hacker full access to the file system on a server, or even to the files on the network to which it is connected?
To show the power of DBA access, we will illustrate one of the many ways a hacker can abuse a SQL server to anonymously gain access to its files via a hijacked DBA account.
First, a hacker needs a method of sending anonymous requests to a database server. Fortunately, this requires only a Web site that is hosted at a company that supports scripting. On a remote Web site, a hacker can program or just upload a script that connects to and delivers a request to SQL server. One example of this type of application can be found at www.aspalliance.com/mtgal/source_code/tsql.exe. Once extracted, this ASP file provides its user with the ability to manually enter a connection string that sets up a connection to a remote SQL server. Once connected, this ASP application sends the entered SQL command to the target and outputs the results. Although a script like this has great legitimate uses, it is easy to see how it can also be abused.
The next step is to send an authenticated SQL request to the database server containing a command that helps the hacker gain full access to the server. One popular method is to use the xp_cmdshell extended stored procedure included with MS SQL Server. This script actually serves as a portal to the cmd.exe file of the server. In other words, a SQL command can move files or perform a directory listing. However, this command can take nefarious forms, including using TFTP to download ncx99.exe (a popular remote shell Trojan) or copying the server's SAM user account file to the Web server root folder so that it can be downloaded anonymously and then cracked. The point is, the database program on the server is only one of many possible items that can be compromised by a direct SQL attack.
For example, Figure 3 illustrates an attack on an MS SQL Server that exploits a DBA account using a null password. In this example, we are using the previously discussed tsql.asp application (with a slight modification) to send a series of requests to the target that will result in the downloading and execution of a Trojan from an online FTP server.
)
Figure 3 Using TSQL.ASP to send.
From this illustration, you can see the power that a DBA account can have on a SQL server. Using methods like this, a hacker can have full control of a server in a matter of seconds.