SQL Injection Lilupophilupop style, Part 2

Published: 2012-08-09
Last Updated: 2012-08-09 06:33:57 UTC
by Mark Hofman (Version: 1)
7 comment(s)


Just as a quick follow up on Daniel's diary from last week  (https://isc.sans.edu/diary.html?storyid=13813) regarding the liluhophilupop SQL injection run which has started up again as of approximately the 1st of August. 

This particular run is very similar to the one back in December 2011 with one minor variation, so far. The platform being attacked is still applications with MSSQL as the backend.  The target is to inject a php script which redirects, etc, etc (the usual rabbit hole).  The main difference between the two attacks is that this time many different domains are being injected rather than the one main domain as was the case in December.  Some of the comments on the previous diary entry provided some of the domains.  These are the ones I have found so far.  

  • lasimp04risoned.rr.nu
  • eighbo02rsbarr.rr.nu
  • reque83ntlyin.rr.nu
  • tentsf05luxfig.rr.nu
  • andsto57cksstar.rr.nu
  • brown74emphas.rr.nu
  • tartis78tscolla.rr.nu
  • senior78custome.rr.nu
  • sfl20ewwa.rr.nu
  • ksstar.rr.nu
  • enswdzq112aazz.com
  • www.bldked98f5.com
  • www1.mainglobilisi.com
  • xinthesidersdown.com
  • inglon03grange.rr.nu
  • senior78custome.rr.nu

rr.nu seems to be a nice spot for malicious domains.

The attack is ramping up slightly with search engines reporting approximately 235K pages infected at the moment.  BTW previous sites that were affected back in December are being revisited as part of this run.  So if that was you, then you may wish to check your log files to make sure you haven't been affected again. 

If you look through your logs look for  

--snip-- /somedirectory/somepage.asp  somevar=38272%27+declare+%40s+varchar% --snip--

(I usually just grep/search for declare, or varchar or char, that usually does the trick)
If that does not find it look for large URL queries (say longer than 1000 chars) or 500 errors

identify the injection variable used, in this case somevar=38272

When you look through your previous logs you will find entries similar to these.

--snip--  /somedirectory/somepage.asp  somevar=38272%2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%40v --snip--
--snip--  /somedirectory/somepage.asp  somevar=38272%27%2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%4 --snip--
--snip--  /somedirectory/somepage.asp  somevar=38272%27%2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%40  --snip--

These are a initial tests to see if the application has some ready injection points.  

Take the IP address from these log lines and check your web logs again for those IP addresses and you will find other activities.  The user agent string is also good to use, as often these stay the same even though different IP addresses are being used. 

When you are doing remediation make sure the developers understand that any input that results in a SQL query can be used to inject, It does not have to be a form variable, any variable is fair game. All input must be validated prior to being used (and not just at the client end either). 

Thanks to those that provided some log records. Happy logging

Mark H





7 comment(s)


add following domain to list. xinthesidersdown.com seems to be the first point of call by the looks of it then it tries to download code from a secondary site


They're all hosted on the same IP ( belonging to Specialist ISP in Transnistria:
http://blog.dynamoo.com/2012/08/more-malware-sites-to-block-on.html is all evil. It is possible that the injection attack orignates from that range or Specialist's other range of Blocking those ranges at the perimeter could be prudent.
so if our logs show an entry like above, that shows someone tried the attack?

Correct, but if the error code on the log line is 200 it worked and your database has been compromised.

If the error message is 500 then the query was accepted, but your server had some problem executing the command (probably means your DB log file is big as well).

Thanks for the info. What is the remedy for this? (if you find a error code 200)
@david. check whether it really worked or your application threw away the query.if the former, I'd the injection point, get the developers to fix it. recover the server or as a minimum the db from backups .
watch the logs for return traffic.
just recovering the db will mean you'll have to clean again within 24 hours. if you need some help upload log files via the contact form and I'll take a look in the morning.
Thanks for your info. It was the above "string" put after some forms like "oursite.com/search.aspx %2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%40v
I'm not clear on how to tell if the app threw the request away though.

Diary Archives