SQL Injection Lilupophilupop style, Part 2
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
Comments
ilsa05mpli.rr.nu
stinson
Aug 9th 2012
1 decade ago
http://blog.dynamoo.com/2012/08/more-malware-sites-to-block-on.html
194.28.112.0/22 is all evil. It is possible that the injection attack orignates from that range or Specialist's other range of 91.211.200.0/22. Blocking those ranges at the perimeter could be prudent.
Conrad
Aug 9th 2012
1 decade ago
so if our logs show an entry like above, that shows someone tried the attack?
David
Aug 13th 2012
1 decade ago
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).
M
Mark
Aug 14th 2012
1 decade ago
David
Aug 14th 2012
1 decade ago
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.
m
Mark
Aug 14th 2012
1 decade ago
I'm not clear on how to tell if the app threw the request away though.
David
Aug 14th 2012
1 decade ago