Stop direct attacks on SQL servers

If you've got a SQL server running, it's a good bet that you don't want to see it hacked. This tip, excerpted from InformIT, offers some ideas on how to try and stop any hacking happening with your server. Forewarned is, of course, forearmed.

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 (

    Requires Free Membership to View

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 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.

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.

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.

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.

To read the entire article from which this tip is excerpted, click over to InformIT. You'll have to register there, but the registration is free.

This was first published in December 2002

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.