Slashdot Mirror

← Back to Stories (view on slashdot.org)

SQL Injection Attack Claims 132,000+

Posted by CmdrTaco on from the check-yer-code-people dept.

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."

5 of 186 comments (clear)

  1. Details? by HangingChad · · Score: 3, Insightful

    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.

    --
    That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
    1. Re:Details? by Yvan256 · · Score: 4, Insightful

      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.

    2. Re:Details? by LordKaT · · Score: 5, Insightful

      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.

  2. Re:why don't these go away? by jimicus · · Score: 3, Insightful

    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.

  3. Re:Lame coders who don't care about security! by DNX+Blandy · · Score: 3, Insightful

    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.