Slashdot Mirror
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."
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
If it were kiddy porn it would be shutdown already.
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.
Uhhhhh, you really RTFA? It doesn't matter what the server is running to get compromised by an SQL injection, does it? Could be MySQL running on a RedHat server. Could be SQL Server running on a Windows server. Why would an SQL injection be platform-dependent? After all, isn't that why SQL is ANSI and _relatively_ portable betwen platforms? I did say "relatively" of course ::rollseyes::
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.
that's the point
it's not a security issue if you deliberately do something ignorant
like, say, using the internet
THE INTERNET IS NOT SECURE
says so right on the packaging, and always has
You don't need stored procedures, all you need are parametrized statements/commands, so long as your API provides it. And plain ADO, which was used with classic ASP, did provide parametrized commands.
Any attempt to defeat SQL injection by blacklisting syntax is inherently error-prone if only because it may break on a future version of database (when its syntax gets extended). Not to mention that, unless you have perfect knowledge of 100% of the SQL dialect that your implementation uses, you may forget to blacklist some corner case.
In short, if you use text substitution to counter SQL injection, you're not doing it right.
No you're wrong. People attack Windows because the most people use it AND it is conveniently also less inherently secure than anything else in current production. If everyone stopped using Windows and switched to XYZ then XYZ would eventually become the new biggest target, that is true but it is just as completely naive to assume the same percentage of attacks would be successful on an entirely different platform as Windows as it is to assume that you would have a remotely accurate clue about what that new percentage would be unless you were fluent in the use of "XYZ" which I'm assuming you are not because you can't even spell Linux right.