Half a Million Microsoft-Powered Sites Hit With SQL Injection 222
Titus Germanicus writes to tell us that a recent attack has compromised somewhere in the neighborhood of 500,000 pages with a SQL injection attack. The vulnerability seems to be limited to Microsoft's IIS webserver and is easily defeated by the end user with Firefox and "NoScript." "The automated attack takes advantage to the fact that Microsoft's IIS servers allow generic commands that don't require specific table-level arguments. However, the vulnerability is the result of poor data handling by the sites' creators, rather than a specific Microsoft flaw. In other words, there's no patch that's going to fix the issue, the problem is with the developers who failed follow well-established security practices for handling database input. The attack itself injects some malicious JavaScript code into every text field in your database, the Javascript then loads an external script that can compromise a user's PC." Ignoring corporate spin-doctoring, there seems to be plenty of blame to go around.
Microsoft's Official View of the Situation (Score:5, Insightful)
As a coder, I don't agree with that. You make a tool/language/framework for developers, you better make it idiot proof. Example: C is far from idiot proof (seg fault!) but it's fast. Stupid fast. Unfortunately for C, there are more stupid coders out there like me than genuis coders out there like
Wow, for flaim retardant reasons, take the above paragraph as my meager opinion.
Re:Microsoft's Official View of the Situation (Score:3, Insightful)
http://www.google.com/search?hl=en&q=site%3Asecurityfocus.com+php+sql+injection [google.com]
Re:Microsoft's Official View of the Situation (Score:4, Insightful)
Why? It's not their responsibility to see to it that you can't write bad code for their program any more than it's the responsibility of car manufacturers to build cars that can't crash no matter how they're driven. There's only so much MSFT can do to protect lusers against their own stupidity, and if badly trained developers write vulnerable code, it's their own damned fault. I'm no Microsoft fanboi, but even I only bash them when they deserve it.
Re:Microsoft's Official View of the Situation (Score:3, Insightful)
Microsoft provides a platform, that platform has problems, but in this case the platform had nothing to do with what happened. This rests entirely on web developers who didn't bother to do things correctly.
Re:Microsoft's Official View of the Situation (Score:3, Insightful)
So stock Java protects me from things like "SELECT * FROM users WHERE Name = 'eldavojohn'; DELETE FROM orders", correct?
Wait, it doesn't. Neither does PHP or Python or Perl.
So I guess you can spin it as this somehow being Microsoft's fault, and Slashdot can post it again (and maybe again tomorrow FTW), deliberately confusing pages vs sites and using titillating article titles and editorial bylines about how corporate spin is "bad".
That doesn't change the fact that this is an application vulnerability, much like the endless stream of exploits against applications like phpBB that run on Linux and Apache.
But hey, it's all in the name of freedom and increased ad revenue, right?
Re:Shameless Hibernate Plug (Score:4, Insightful)
Some of these complexity and efficiency issues can be resolved by partial denormalization of the database design, but again, that introduces inefficiency.
Basically, the use of a high-level framework like that introduces significantly more difficulty into the already difficult problem of performance optimization. And for most people, performance is a more immediate and obvious problem that needs solving as opposed to security.
Another problem in my opinion is that there approximately a million and one different database abstraction layers like Hibernate out there. The lack of standardization makes it very difficult for any of them to gain any sort of critical mass of developers and documentation the way SQL has.
Re:Microsoft's Official View of the Situation (Score:4, Insightful)
If you need access to locations of memory normally protected by a seg-fault, your operating system normally provides a means to do so.
Re:Microsoft's Official View of the Situation (Score:3, Insightful)
So what you are saying is that (and quoting the article you reference) Microsoft is at fault for providing these "high end features"? Even considering that it's not necessary to write sloppy VBScript code, and that it's ridiculously easy to use ADO to put together parameterized database commands, regardless of how many resultsets they are supposed to return?
And that the lack of that feature is actually an advantage for platforms like PHP and Perl? I'm curious, is the lack of that feature the reason for the multiple and well-documented injection attacks against LAMP applications? Or is it something else?
You will forgive me here if I imagine for a second what the general sentiment would be if the PHP MySQL driver actually provided this useful time- and bandwidth-saving feature while ADO/ADO.NET didn't. You would be telling me that it's the developers' fault, since all they need to do is write half-decent code that uses simple and well-documented features in the DB framework that prevent exposure to injection attacks. The PHP folks would not to blame, and in fact it would be so cool of them to out-innovate Microsoft.
Re:Shameless Hibernate Plug (Score:3, Insightful)
Sorry, but that's the reality; anybody on Slashdot already knows what you're saying, and the type of people who code these bugs don't read Slashdot.
Right, but... (Score:3, Insightful)
Re:Microsoft's Official View of the Situation (Score:3, Insightful)
The malware authors could have trivially used INFORMATION_SCHEMA views rather than sysobjects, and this would have been a generic attack that would have worked against most mainstream db servers.
Again, the ONLY reason this only works on MS-SQL is because the malware authors made a choice to write the attack in non-portable syntax. They could have done so, but they chose not to.
Re:MS SQL Server is particularly vulnerable (Score:3, Insightful)
Most mainstream databases allow you to do this. Oracle and MySQL off the top of my head that I've personally done this on.
Some db adapter libraries (like one of the real simple ones in PHP for MySQL) dont let both statements get through and/or throw an error, and/or cant handle multiple result sets.
But keep in mind, an attack like this doesnt require both statements to be run in the same batch or in the same transaction, since there's no connection between the two and no result set from the second command.
This simplifies the requirements. Some DB libraries dont allow multiple result sets to come back, but the vast majority allow multiple commands to be sent.
What allows an attacker to trivially execute SQL isnt anything to do with MSSQL, but with the app design that is concatenating sql strings and then passing them unchecked to the db.
This exact problem is hugely rampant on PHP/MySQL sites.
When doing casual pen-testing at prior jobs, I've made this sort of attack work against Oracle WebDB, PHP/MySQL, ASP/MSSQL, and Java/Oracle.