SQL injection

The OWASP Guide defines SQL injection as follows:

A SQL injection attack consists of injection of a SQL query via the input data from the client side to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

sql-1.png

Although a common problem with web applications, this vulnerability can affect any application that communicates with a database management system via Structured Query Language.

A SQL injection occurs when the application fails to properly sanitize user-supplied input used in SQL queries. In this way an attacker can manipulate the SQL statement that is passed to the back-end database management system. This statement will run with the same permissions as the application that executed the query.

Modern database management systems are powerful applications. They usually provide built-in instruments to interact with the underlying file system and, in some cases, with the operating system. However, when they are absent, a motivated attacker can still access the file system and execute arbitrary commands on the underlying system: this paper will walk through how this can be achieved via a SQL injection vulnerability, focusing on web-based applications.

Many developers and web administrators are complacent about SQL Injection vulnerabilities if the attacker cannot see the SQL error messages and/or cannot return the queries result directly to the browser. This topic was first addressed in a white paper written by Chris Ansley of NGSSoftware (http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf). This paper will expand on possible ways this threat can be used. When trying to exploit SQL Injection in an application, an attacker needs a method of determining if the SQL injected is executed on the server. As well, a method of retrieving the results is needed. Two built-in functions of SQL Server can be used for this purpose. The OPENROWSET and OPENDATASOURCE functions allow a user in SQL Server to open remote data sources. These functions are used to open a connection to an OLEDB provider. The OPENROWSET function will be use in all the examples but the OPENDATASOURCE function could be used with the same results.

This statement will return all the rows of table 1 on the remote data source:

select * from 
OPENROWSET (‘SQLoledb', 'server=servername;uid=sa;pwd=h8ck3r',
'select * from table1’)

Parameters:

  1. OLEDB Provider name

  2. Connection string (could be an OLEDB data source or an ODBC connection string)

  3. SQL statement

The connection string parameter can specify other options such as the network library to use or the IP address and port to which to connect. Below is an example. 

select * from 
                       OPENROWSET ('SQLoledb', 'uid=sa;pwd=h8ck3r;Network=DBMSSOCN;Address=10.0.0.10,
                        433;', 'select * from table’)

In this example, SQL Server will use the OLEDB provider SQLoledb to execute the SQL statement. The OLEDB provider will use the SQL Server sockets library (DBMSSOCN) to connect to port 1433 on the IP address 10.0.0.10 and will return the results of the SQL statement to the local SQL Server. The login sa and the password h8ck3r will be used to authenticate to the remote data source.

By injecting this SQL statement, an attacker can determine if the statement is being executed. If the SQL is successfully executed, the attacked server will issue an outbound connection attempt to the attacker’s computer on the port specified. It is also unlikely that the firewall will block this outbound SQL connection because the connection is occurring over port 80. This technique allows the attacker to determine if injected SQL statements executed even if error messages and query results are not returned to the browser.

RECOMMENDATIONS

The strongest recommendation is to ensure that you do not have any SQL injection vulnerabilities. This is the most important recommendation because even if you address all the issues brought up by this paper, other issues will surely arise. To prevent SQL injection, it is recommended you use parameterized queries and filter all user input for non-alphanumeric characters.

The most systematic method to do so is to set coding standards that require this to be done. If the code is already written, a code review should be done to detect any vulnerabilities. It is also recommended you look at some of the automated tools available for detecting these types of problems.

Even if you feel you have closed all known vulnerabilities, it is still in your best interest to prevent these specific attacks by disabling some of SQL Server’s functionality. This is not practical if you are using the functionality. Fortunately, the functionality we are looking to disable is not used often.

You should disallow ad hoc queries through OLEDB from SQL Server. Ad hoc queries from SQL Server through OLEDB providers are controlled by setting the value DisallowAdhocAccess in the registry.

If you are using a named instance (Microsoft SQL Server 2000 only), set the value DisallowAdhocAccess to 1 under each subkey of the registry key: 

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL\Server\[Instancename]\Providers.

If you are using a default instance, set the value DisallowAdhocAccess to 1 under each subkey of the registry key: 

HKEY_LOCAL_MACHINE\Software\MSSQLServer\MSSQLServer\Providers.

Follow the steps below to set this value:

  1. Start the Registry Editor (regedit.exe).

  2. Find the registry key listed above.

  3. Select the first provider subkey.

  4. Select the menu item Edit\New\DWORD Value.

  5. Set the name of the new DWORD value to DisallowAdhocAccess.

  6.  Double click on the value and set to 1.

  7. Repeat for each provider.

If you are particularly paranoid, you can also set the registry keys to read-only to be extra sure they cannot be edited.

It is also very important that you keep up to date with the latest security fixes and apply them as quickly as possible. In order to keep up with the security holes, it is recommended that you sign up for the AppSecInc Security Alerts targeted specifically at Microsoft SQL Server: http://www.appsecinc.com/resources/mailinglist.html

As a final precaution, configure and test firewall filters to block all unnecessary outbound traffic. This not only helps secure your databases but helps secure the entire network.