Half a Million Microsoft-Powered Sites Hit With SQL Injection

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.

Comments

Microsoft's Official View of the Situation

[eldavojohn]

Ignoring corporate spin-doctoring there seems to be plenty of blame to go around. Well, here's a quote directly from Bill Sisk of Microsoft (seems to be in line with this blogger):

Microsoft (NSDQ: MSFT) on Friday found itself trying to clarify that it has nothing to do with the poor coding practices that have enabled a massive SQL injection attack to affect Web sites using Microsoft IIS Web Server and Microsoft SQL Server. "The attacks are facilitated by SQL injection exploits and are not issues related to IIS 6.0, ASP, ASP.Net, or Microsoft SQL technologies," said Bill Sisk, a communications manager at Microsoft, in a blog post. "SQL injection attacks enable malicious users to execute commands in an application's database." Sisk said that to defend against SQL injection attacks, developers should follow secure coding practices. So if you want Microsoft's side of the story, they can't help it that people use bad coding practices.

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 ... Donald Knuth. So you will see Java rise in popularity without ever being able to live up to speed of C.

Wow, for flaim retardant reasons, take the above paragraph as my meager opinion.

Re:Microsoft's Official View of the Situation

[duplicate-nickname]

So, I suppose all of the LAMP sites out there vulnerable to SQL injection are the fault of Microsoft too?

http://www.google.com/search?hl=en&q=site%3Asecurityfocus.com+php+sql+injection

Re:Microsoft's Official View of the Situation

[techno-vampire]

You make a tool/language/framework for developers, you better make it idiot proof

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

[0racle]

Do you post something similar when it's a PHP app on Apache being exploited with a SQL injection and the PHP authors say it's not their fault a whole bunch of their users are idiots?

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

[dedazo]

As a coder, I don't agree with that. You make a tool/language/framework for developers

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:Microsoft's Official View of the Situation

[Sigma 7]

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. A seg fault is a form of idiot proofing - it prevents rogue C-style pointers from ruining the system. The absence of seg fault means your program is overwriting various locations in memory, which potentially causes the system to crash.

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

[dedazo]

it looks like it would have been prevented if Microsoft had disallowed multiple statements in the driver.

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:Microsoft's Official View of the Situation

[Allador]

why is it only MSFT IIS and MS SQL that's affected Because the code they used is based on the MS-SQL particular dialect, with some MS-SQL specific conventions.

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.

while the flaw may not be MSFT's sole fault how could 500,00 people setup a server wrong including the DHS? This has nothing, zero, to do with server setup or configuration. This is purely and soley, only has to do with web app developers allowing uncleansed commands to be sent from a web-browser to the underlying db server.

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:Shameless Hibernate Plug

[Cecil]

I can't speak about Hibernate specifically, but I can tell you what my first concern would be. Database frameworks usually tend to have trouble dealing with complex database designs, and if they can deal with them they are invariably much slower and less efficient than a SQL statement could be.

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:Shameless Hibernate Plug

[Blakey Rat]

The kind of people who write code susceptible to SQL Injection attacks don't read Slashdot, buddy. They don't go to programming classes, they don't read literature, they just do the absolute bare minimum to get by with their VB6 knowledge in the modern world.

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

[Jeff Molby]

...it's weak idiot-proofing. Strong idiot-proofing makes it so the problem is never even encountered.

Re:MS SQL Server is particularly vulnerable

[Allador]

Microsoft SQL Server is particularly vulnerable to SQL injection in a way that most other databases aren't. The problem is multiple statement execution just by inserting semicolons. That is incorrect.

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.

Catalog access isn't much of a vulnerability if an attacker cannot trivially execute SQL ad lib. with a single unchecked parameter. /quote.

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.