This is the first time I have ever seen SQL injection this widespread and in an automated fashion. Before it’s all said and done this could be !!! HUGE !!!. News of this has been trickling out since the end of April with the first hint of it at the beginning of the year.
Basically what’s happening is attackers are using SQL injection, in some sort of automated fashion, to insert Javascript malware into databases of some popular websites, the United Nations for example. Once a user visits an infected website (un.org) they will unknowingly be sent to a malicious site where attackers try numerous exploits to see if they succeed. Keep in mind the user will remain on un.org as if everything is fine and dandy but in the background exploits are being launched.
What’s so scary about these widespread infections is that the Javascript malware will remain on the database until the webmaster removes it. Even then the websites will still be vulnerable to SQL injection so attackers could reinsert malware until the vulnerability is fixed. Also attackers could easily update the location of their malicious site through SQL injection. For example lets say attackers are using http://evilattacker.com for launching their exploits but this URL gets blacklisted, they could then update infected databases with a new URL, say http://maliciousattacker.com. So this type of widespread epidemic is the gift that keeps on giving.
I’ve seen these attacks come across the IDS (intrusion detection system) where users are visiting infected URL’s. Of course attackers could easily move their operations to different URL’s. Some exploit URL’s I’ve seen so far are nihaorr1.com, nmidahena.com, aspder.com, rirwow.cn, and wowyeye.cn. I performed searches to get an idea of the infection numbers, now doing a search for the offending URL won’t give you a 1 to 1 relationship but it will give you a ballpark figure. Take a look at the “Results” numbers in the following screen shots.
Also check out this screen shot from ririwow.cn, you’ll get a laugh from it.
So the ballpark infection just from these three URL’s is 500,000, scary isn’t it. Even if this number is 400,000 off that still leaves 100,000 sites infected. There’s no way at this point to verify the number but this is definitely the largest SQL injection campaign I have ever seen. It’s these URL’s along with others that are hosting the Javascript malware. It’s common to see the attackers use Javascript to open zero pixel iframes so the attack appears hidden. The Javascript files I’ve seen so far are short names with either a single letter or number (e.g. m.js, 1.js, jp.js, etc). So the request that happens in the background will look like http://ririwow.cn/jp.js. In order to see the request one would have to use a local web proxy. Without a proxy you would never see the request. So I’m going to keep my eyes peeled in the coming months to see how this epidemic plays out.
Below are some other good articles related to this topic
4 replies on “Widespread SQL injection & Javascript malware”
Another thing to consider is how dynamic the attack can be. Consider that what is stored to the victim-site is the call to the external js file and NOT the js file, itself.
This means that the person/people who serve the malicious js files can constantly update the code with different or newly crafted attacks.
…Of course, this is assuming that the injection goes unnoticed by the victim-sites’ owners. But given the widespread success, how many of the victim-sites’ owners are aware that they are victims? 🙂
Eric,
you’re right about mixing up the javascript on the sites performing the exploits, i didn’t really think about that. the possibilities are some what endless when the attacker has a hold of your web apps database.
also something interesting that PJ McGarvey out of Philly pointed out is that some of the javascript used is obfuscated to try and hide the attack. i haven’t personally analyzed much of this attack but the 50,000 ft view is scary enough.
The internet worm is back. My only surprise is that it took them this long to innovate.
Second, being that the exploits are being served up by the database, the Database Admin will see no problems, because we’re not dealing with corruption here. They would need to delve into the tables and find the offending code… and how the heck are they supposed to do that?
Apparently history does repeat itself, the attackers have gone back to defacing websites.
Joel,
you make a good point, i’m surprised this didn’t happen months or years ago. as far as offending code you can do it but it’s not the easiest solution. Eric Jenko above pointed me to a link on how to fix the problem.
http://phreakhead.livejournal.com/2008/05/12/
in phreakhead’s case he searches for and replaces wowyeye.com/m.js, you would of course have to search for other offending URL’s also.
speaking of worms Joel, Eric also pointed to an article yesterday saying that the likely culprit is a botnet. who would’a thunk it?
http://www.darknet.org.uk/2008/05/new-botnet-malware-spreading-sql-injection-attack-tool/