SQL Injection Attack Claims 132,000+

An anonymous reader writes "A large scale SQL injection attack has injected a malicious iframe on tens of thousands of susceptible websites. ScanSafe reports that the injected iframe loads malicious content from 318x.com, which eventually leads to the installation of a rootkit-enabled variant of the Buzus backdoor trojan. A Google search on the iframe resulted in over 132,000 hits as of December 10, 2009."

Comments

Re:hey

[jo42]

dd if=/dev/zero of=/dev/sda bs=8192 will fix it.

why don't these go away?

[v1]

If they know where the site is that's hosting the payload why don't they just shut them down? I realize the locations for the hosting are carefully chosen to provide maximum insulation, but still you'd expect that by now (years after this sort of thing became common) that there'd be mechanisms and procedures in place to break these down swiftly?

Re:why don't these go away?

[jimicus]

You are assuming that all the systems are hosted at reputable hosting companies that pro-actively monitor all their systems.

There are millions of systems worldwide that are exposed to the public internet (even though they probably shouldn't be) that are sitting in the corner somewhere waiting for someone to "get around to decommissioning them" - and in the meantime they're pumping out spam and taking part in DDoS attacks.

Reminds me of xkcd

[BountyX]

Seriously people stop naming your kids with ');DROP TABLE at the end...

Details?

[HangingChad]

I love the way they fail to mention what server systems might be effected. Is it SQL Server? MySQL? .NET? PHP? Windows servers? Linux? Both? What web sites are vulnerable?

It's always fun to snicker when you get to the registry entries which points to Windows. Although there was a trojan for Ubuntu in a desktop theme a few days ago, so enjoy the time to mock Windows users while it lasts.

Re:Details?

[Yvan256]

But a Trojan needs user access and approval to get installed. No OS on the planet can protect itself from a user with the admin password.

Re:Details?

[Bert64]

Windows 9x used to due a pretty good job, can't own a system once it's bluescreened.

Re:Details?

[LordKaT]

Even still, this blog post is fucking useless. What CMS? What input is not being validated? Is it an underlying problem with Drupal? Wordpress? Joomla? What version?

On top of that, it doesn't give any recommendations for what end users could do to protect themselves. Does anti-virus software already detect it? Can you simply alter your hosts file? Disable Javascript?

The blog post is completely fucking useless.

Re:hey

[Yvan256]

Call a comedy club and get your computer on stage?

How is SQL involved?

[Bromskloss]

The article said "SQL" in the headline, but never mentioned it again after that.

Re:Windoze

[TheNinjaroach]

All I can tell (from TFA), is it affects Windows servers.

SQL injection attacks affect any number of platforms. It's not a Windows problem, it's not a database problem, it's a "we hired cheap, unskilled developers" problem.

Now the people who browse these sites and get hit with malware, that looks to be specific to Windows.

Obvious, but needs to be said

[GreenTom]

Add to windows\system32\drivers\etc\hosts:

127.0.0.1 318x.com

And you should be safe, for the moment.

No...

[Oxford_Comma_Lover]

The assumption is that once there are a hundred thousand servers hit, and maybe fewer, if the hosting company doesn't shut down the site within an hour or two a responsible upstream router blocks traffic from the site. Every delivered payload costs society more time and money.

Re:Let's say it all together now...

[Vellmont]

validate your SQL inputs before posting them against an Internet-facing database.

Or simply use prepared statements (or whatever the equivalent term is in your language of choice). Prepared statements are far safer and easier than trying to validate all the current potential and future potential for breaking out of a SQL statement. It won't protect you from people putting in their own parameters into your SQL statement (like say someone elses userID), but that's a different class of vulnerability.

Re:Lame coders who don't care about security!

[DNX Blandy]

Very true, at which point this function simply doubled up the string delimiters, breaking the SQL injection. The major problem with Classic ASP was the casting of variables, if not done properly you were asking for it. If it's numeric, check it. .NET does not suffer from this problem unless the coder specifically passes a numeric value thou to an SQL statement as a string, which would be stupid. If everyone used stored procedures to deal with the SQL data, none of this would happen. My above checks alert you to the fact that someone if having a go, you can't do that when checking for string delimiters as they are valid characters, but yes, if your code uses a shitty "execute" command, check it. If you use proper stored procedures, this will no affect you.

Re:hey

[Arancaytar]

I actually post all my comments via a dead-man's-switch proxy that logs my keystrokes in real time and submits the post once it detects inactivity. This way I can type things like Candlejack and still publish my po