Testing Database Vulnerabilities

This section peeks at some of the potential points of attack on a database system. It focuses specifically on SQL Server, although most of the principles hold true for all RDBMSs.

The toolkit of the DBA is more often than not the core toolkit of a hacker, and the two standard tools that ship with SQL Server are no exception. Query Analyzer, both the graphical version (see Figure 8-2) and the command-line tool osql (see Figure 8-3), provides an invaluable interface to manipulate data on a compromised server.

Figure 8-2. SQL Server Query Analyzer

Figure 8-3. osql Command-Line Query Tool

Enterprise Manager is a Windows snap-in console (MMC is Microsoft Management Console) that facilitates SQL Server Administration, as shown in Figure 8-4. By familiarizing yourself with this tool, you gain an insight into the typical way in which a SQL server is configured and with some of methods that a DBA might use to perform administrative tasks. For example, you can easily view the various system objects using this tool.

Figure 8-4. SQL Server Enterprise Manager

In addition to these standard tools, many more are available. They are designed as analysis tools to detect SQL Servers and their vulnerabilities, as you will see later in this chapter.

One of the first steps before commencing an attack on a network is to enumerate the possible weaknesses in that network. Because database servers rank highly in that list, various tools are available to make the task simpler. These include SQLPing, SQLPing.NET, and SQLpoke. (See http://www.sqlsecurity.com under the Tools drop-down menu.) These tools scan a specified range of IP addresses looking for an open UDP port 1434. Two versions of SQLPing are currently available: the original command-line tool, and a graphical version known as SQLPing2. Figure 8-5 shows the interface for SQLPing2 when scanning an IP address range.

Figure 8-5. SQLPing2

SQL Injection

Web applications frequently utilize a back-end database, providing the user with the ability to read or write data into the system. However, the lack of sophistication in a surprising number of web applications exposes a vulnerability to SQL injection. What is SQL injection? Well, simply put, it is altering the SQL statements that the web application is trying to send to the database. To understand the concept in more detail, you first need to understand a little SQL.

Each time you visit a website that requires you to log in, the application doubtless sends a query to a database to check out your credentials. It probably builds a SQL query string looking something like this:

"SELECT * from Users where UserName = '" + username + "' and password = '" + password + "'";

where username and password and the values entered on the web page by you, the user, are passed into the string as variables. If you were to log in as Bob with a password of 123, the actual query passed to the database would be as follows:

SELECT * from Users where UserName = 'Bob' and password = '123'

The application expects the database to return a row of data corresponding to that user only if he exists. SQL, like other programming languages, uses characters to "comment out" code. The -- (single line comment) is particularly useful, resulting in everything after it being ignored. If, instead of entering Bob as the username, you instead enter

Bob' or 1=1 --

the resulting SQL statement becomes this:

SELECT * from Users where UserName = 'Bob' or 1=1 -- ' and password = '123'

Of course, 1=1 is always true. Because only one-half of an OR statement must be true, the query engine returns the entire contents of the Users table. Although this data will probably not be displayed to the user, if the application checks only for the existence of a record in the users table, you have successfully logged in.

The limitations of SQL injection do not end there. After you have established that an application has this particular vulnerability, you have an open query window through which you can do many things.

SQL Server has the added value of a batching functionality whereby SQL statements can be tagged together in a batch with each statement separated by a semicolon (;). This further enhances the effectiveness of SQL injection, allowing a straightforward SELECT statement like the one in the preceding SQL statement, to offer much more potential to the hacker if he should add further code such as this:

; EXEC xp_cmdshell 'dir > c:\dir.txt'

This statement takes the listing of the current directory and pipes it out to a text file.

It is worth noting that neither Oracle nor MySQL shares this feature.

System Stored Procedures

A stored procedure is one or more SQL statements that you can execute by calling the procedure by name. Most RDBMS systems support their use. Often, several statements are encapsulated into a stored procedure to carry out a complete logical process.

SQL Server uses various built-in procedures known as system stored procedures and extended stored procedures. These procedures are installed by default during a standard installation. Although many are essential for the database to function, some expose potentially dangerous functionality to an attacker. Table 8-7 lists a selection of extended stored procedures that could provide information or be used as a tool in compromising a SQL Server database.

Table 8-7. SQL Server Extended Stored Procedures Vulnerable to Malicious Use

Procedure Name	Description	Permission
xp_cmdshell	Executes a command string as a command shell and returns the output as text	Sysadmin
xp_dirtree	Returns an entire directory tree	Public
xp_dsninfo	Returns information on DSNs[*]	Sysadmin
xp_enumgroups	Provides a list of local or domain NT groups	Sysadmin
xp_eventlog	Returns the specified Windows event log	Sysadmin
xp_getfiledetails	Returns file information for a specified file	Public
xp_getnetname	Returns the NetBIOS name for the database server	Public
xp_logevent	Logs a user-defined message to both the SQL Server and Windows logs	Sysadmin
xp_loginconfig	Reports the security configuration for logins	Sysadmin
xp_logininfo	Returns the account, type, and level of privilege for a given Windows user or group	Sysadmin
xp_makecab	Allows a user to create a compressed archive of files held on the database server	Sysadmin
xp_msver	Returns the SQL Server version and various environment information	Public
xp_ntsec_enumdomains	Returns a list of the Windows domains to which the server has access	Public
xp_readerrorlog	Displays the SQL Server error log	Sysadmin
xp_regdeletekey	Allows a registry key to be deleted	Sysadmin
xp_regwrite	Allows a registry key to be updated	Sysadmin
xp_servicecontrol	Allows a user to stop or start a Windows service	Sysadmin

^[*] DSNs = data source names

Many of the system stored procedures are highly useful as development aids, but all too often systems are put into production without first removing these extended stored procedures. At one time, it was recommended that the most dangerous stored procedures be dropped entirely from the system, but this can impact other elements of the database server. Instead, you can mitigate the risk by ensuring that their permissions are tightly controlled.

xp_cmdshell

Granting execute permissions on xp_cmdshell to users enables the users to execute any operating system command at the command shell that the account running the SQL Server service has the necessary privileges to execute. If the service account has permissions to start and stop services so, too, does the hacker who can execute xp_cmdshell. What this boils down to is the real possibility that your website grinds to a halt with the following scenario.

Consider the following SQL Injection input at a login screen:

Username: '; exec master..xp_cmdshell 'net stop "iis admin service" Y'; -- Password: [Anything]

Sadly, for the hacker, a server with xp_cmdshell exposed in this way is a rare find indeed, but SQL Injection can reveal other useful information using the helpful error messages that SQL Server returns. You can make particular use of one of its built-in functions, @@VERSION, to reveal some interesting information about your potential target in the following way. Back at the login screen, enter the following:

Username: ' and 1 = (SELECT @@VERSION)--

This command produces the following verbose-looking, but extremely informative error:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07' [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'Microsoft SQL Server 2000 - 8.00.194 (Intel X86) Aug 6 2000 00:57:48 Copyright © 1988-2000 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: ) ' to a column of data type int. /login.asp, line 32

The @@VERSION function returns similar information to that of the extended stored procedure xp_msver (see Table 8-6), namely the date, version, and processor type for the current SQL Server installation. You can ascertain from this that this server is in fact a Windows 2003 server, and the SQL Server version number shows that it is unpatched (and hence vulnerable).

Connection Strings

To authenticate against a database via a web application, web developers often hard code a connection string into a configuration file, such as web.config or global.asa. The string probably looks something like this:

Trusted connection: "Provider=SQLOLEDB;Data Source= MyDBServer;Initial Catalog=MyDB;Integrated Security=SSPI;" SQL Server Security: "Provider=SQLOLEDB;Data Source=MyDBServer;Initial Catalog=MyDB;User Id=sa;Password=;"

In the case of the first few lines, this assumes that the SQL Server is configured to use Windows authentication. (See the section "Authentication" a little later in this chapter.) This poses no risk because no username or password is revealed. However, the final lines show that SQL Server security is being used, and the username and password can be read directly from the file (which in this case shows the "standard" sa user with blank password).

Password Cracking/Brute Force Attacks

SQL Server stores usernames and passwords in its sysxlogins table in the master database. The password is hashed using a stored procedure named pwdencrypt(). Unfortunately, SQL Server not only stores the resulting hash, but also an uppercase version, making brute force attacks simpler.

Note

For more information on password hashes, see the whitepaper at http://www.ngssoftware.com/papers/cracking-sql-passwords.pdf.

Various tools are available to assist in brute forcing a SQL Server password, including the following:

• SQLBF Password auditing tool that runs in bruteforce mode or in dictionary attack mode. Available from http://www.cqure.net.

• SQLDict Dictionary attack tool available from http://ntsecurity.nu.

In addition, the following stored procedures (based on an idea by David Litchfield at http://www.ngssoftware.com/) perform similar tasks:

• FindSA Brute force attack for finding the SA password. (See Figure 8-6.)

  Figure 8-6. FindSA Running in Query Analyzer

  
  
  

• FindSADic Dictionary attack for finding passwords.

These and other available tools generally run in either brute force mode, where every possible character combination is tested, or in dictionary attack mode. In dictionary attack mode, the tool requires a wordlist. You can find various sources for these tools at ftp://ftp.ox.ac.uk/pub/wordlists.