Advanced evasion techniques for defeating SQL injection Input validation mechanisms

[cemama]

Web applications are becoming more and more technically complex. Web applications, their supporting infrastructure and environments use various technologies and can contain a significant amount of modified and customized code.

The availability of these systems and the sensitivity of the data that they store and process are becoming critical to almost all major online businesses.

Since the network security technology market has matured, hackers have found it relatively harder to breach information systems through networkbased vulnerabilities, hackers are switching their focus to attempting to compromise web applications.

SQL injection is an attack in which SQL code is inserted or appended into application or user input parameters that are later passed to a back-end SQL server for parsing and execution.

In this mini-howto I will concentrate on “First Order Attack” SQL injection.

NOTE:

Hackers are using timing or other performance indicators to deduce the success or results of an attack.

There are many ways to exploit SQL injection vulnerabilities, the success of the attack is highly dependent on the database and its hosting operating systems that are under attack. (same database could be hosted on a Linux system or Windows). It might take a great deal of skills and perseverance to exploit a vulnerability to its full potential.

In this mini-howto, we’ll explore more advanced techniques which you can use to enhance your SQL injection attacks, and to overcome difficulties that you may encounter. We’ll discuss methods for evading input validation mechanisms, and look at various ways in which you can bypass defenses such as Web application firewalls (WAFs) or intrusion prevention systems (IPSs).

We will discuss some attack techniques to deliver a more complex attack to compromise adequately well-defended applications.

Web applications frequently employ input filters that are designed to defend against common attacks such as XSS, code injection, CSRF, including SQL injection. These filters may exist within the application’s own code, in the form of custom input validation, or may be implemented outside the application, in the form of Web application firewalls (WAFs) or intrusion prevention systems (IPSs) or intrusion detection systems (IDSs).

In the context of SQL injection attacks, the most interesting filters you are likely to encounter are those which attempt to block any input containing one or more of the following:

SQL keywords:

such as ‘SELECT’, ‘INSERT’, ‘FROM’, ‘UPDATE’, ‘WHERE’, ‘ALTER’, ‘SELECT’, ‘SHUTDOWN’, ‘CREATE’, ‘DROP’, ‘DELETE FROM’ and so on.

Specific individual characters

such as quotation marks (‘) or hyphens (-)

Whitespace

You may also come across filters which, rather than blocking input containing the items in the list above, the application code attempts to modify the input to make it safe, either by encoding or escaping problematic characters or by stripping (dropping) the offending items from the input and processing what is left in the normal way. But quite often, the application code, that these filters protect is vulnerable to SQL injection, and to exploit the vulnerability you need to find a means of evading the filter to pass your crafted input to the vulnerable code.

Welcome to the main part of this mini-howto. We will examine some techniques that you can use to do just that.

Null Bytes:

Often, the input filters which you need to bypass in order to exploit an SQL injection vulnerability are implemented outside the application’s own code, in IDSs or IPSs or WAFs. To perform a null byte attack, you simply need to supply a URL-encoded null byte (%00) prior to any characters that the filter is blocking.

Suppose that we want to inject a UNION attack as below:

' UNION SELECT password FROM Users WHERE username='admin'-- 

Using the example above, you may be able to circumvent the input filters using an attack string as the following:

%00' UNION SELECT password FROM Users WHERE username='admin'-- 

SQL Comments:

You can use inline comment sequences to create snippets of SQL which are syntactically unusual but perfectly valid, and which bypass various kinds of input filters. You can circumvent various simple pattern-matching filters in this way.

For example:

Let’s suppose that the application and its defenders filter out whitespaces and the equal sign (=).

You can easily bypass these filters using inline comments to separate each keyword without the need for

whitespace. For example:

'/**/UNION/**/SELECT/**/password/**/FROM/**/Users/**/WHERE/**/username/**/ 
LIKE/**/'admin'-- 

Many Web Developers wrongly believe that by restricting input to a single token they are preventing SQL injection attacks, forgetting that inline comments enable an attacker to construct arbitrarily complex SQL without using any spaces.

With MySQL, you can even use inline comments within SQL keywords, enabling many common keyword blocking filters to be bypassed.

For example:

If the back-end database is MySQL the attacking string above could be re-written like this below:

'/**/UN/**/ION/**/SEL/**/ECT/**/password/**/FR/**/OM/**/Users/**/WHE/**/RE/**/ 
username/**/LIKE/**/'admin'-- 

NOTE:

In MySQL, the “– ” (double-dash) comment style requires the second dash to be followed by at least one whitespace or control character (such as a space, tab, newline, and so on).

URL Encoding:

URL encoding is a versatile technique that you can use to defeat many kinds of input filters. In its most basic form, this involves replacing problematic characters with their ASCII code in hexadecimal form, preceded by the % character.

For example, the ASCII code for a single quotation mark is 0×27, so its URL-encoded representation is %27.

A vulnerability was discovered in 2007 in the PHP-Nuke application employed a filter which blocked both whitespace and the inline comment sequence /*, but failed to block the URL-encoded representation of the comment sequence. In this situation, you can use an attack such as the following to bypass the filter:

(see Security Alerts - Secunia)

'%2f%2a*/UNION%2f%2a*/SELECT%2f%2a*/password%2f%2a*/FROM%2f%2a*/Users%2f%2a*/ 
WHERE%2f%2a*/username%2f%2a*/LIKE%2f%2a*/'admin'-- 

NOte:

/ URL-encoded to %2f

* URL-encoded to %2a

Sometimes, this basic URL-encoding attack might not work, however you can circumvent the filter by double-URL-encoding the blocked characters (in this case /*). In the double-encoded attack, the % character in the original attack is itself URL-encoded in the normal way (as %25) so that the double-URL-encoded form of a single quotation mark is %2527. If you modify the above attacking string above to use double-URL encoding, it looks like this:

 '%252f%252a*/UNION%252f%252a*/SELECT%252f%252a*/password%252f%252a*/ 
FROM%252f%252a*/Users%252f%252a*/WHERE%252f%252a*/username%252f%252a*/ 
LIKE%252f%252a*/'admin'-- 

After the double-URL-encoding, the application URL decodes the input as ‘/**/ UNION so on …

and the application would process the input within an SQL query, and the attack would be successful.

Another variation on the URL-encoding technique is to use Unicode encodings of blocked characters. As well as using the % character with a two-digit hexadecimal ASCII code, URL encoding can employ various Unicode representations of characters. Because of the complexity of the Unicode specification, decoders often tolerate illegal encodings and decode them on a “closest fit” basis. If an application’s input validation checks for certain literal and Unicode-encoded strings, it may be possible to submit illegal encodings of blocked characters, which will be accepted by the input filter but which will decode appropriately to deliver a successful attack.

The table below shows couple of some standard and non-standard Unicode encodings of characters ' and * that are useful for SQL injection attacks.

Literal Character Encoded Equivalent'

	
			%u0027
			%u02b9
			%u02bc
			%u02c8
			%u2032
			%uff07
			%c0%27
			%c0%a7
			%e0%80%a7

*	
			%u002a
			%uff0a
			%c0%2a
			%c0%aa
			%e0%80%aa

Automating SQL Injection

Once you have found a vulnerable application, you can apply the different techniques we discussed above.

However, these attacks may require hundreds (or even thousands) of requests to extract a decent amount of information from the remote database. Manually crafting such a huge number of requests would be time consuming and tedious. That is where automating tools come in.

There are several tools that can automate the whole process:

Sqlmap

(MySQL, Oracle, PostgreSQL, Microsoft SQL server, Blind SQL, UNION querey, Batch queries, time based Blind Sql injection).

SqlNinja

(cracks password, priviledge escalation).

SQLPower

(sql server, PostgreSQL, Oracles, Sybase and DB2).

SQLiX

(www.owasp.org/index.php/Category:OWASP_SQLiX_Project)

Absinthe

(http://0×90.org/releases/absinthe/)

Sursa