Slashdot Mirror


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.

28 of 222 comments (clear)

  1. Microsoft's Official View of the Situation by eldavojohn · · Score: 4, Insightful

    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.
    --
    My work here is dung.
    1. Re:Microsoft's Official View of the Situation by duplicate-nickname · · Score: 2, Insightful

      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

      --

      ÕÕ

    2. Re:Microsoft's Official View of the Situation by techno-vampire · · Score: 3, Insightful
      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.

      --
      Good, inexpensive web hosting
    3. Re:Microsoft's Official View of the Situation by 0racle · · Score: 2, Insightful

      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.

      --
      "I use a Mac because I'm just better than you are."
    4. Re:Microsoft's Official View of the Situation by dedazo · · Score: 3, Insightful

      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?

      --
      Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
    5. Re:Microsoft's Official View of the Situation by Lobster+Quadrille · · Score: 3, Informative

      Actually, PHP's mysql engine won't run that query- you cannot execute more than one query in a single mysql_query() call.

      There are plenty of ways around it, but your query will fail.

      --
      "The cup is in turn designed for holding hot or cold liquids, and has an open rim and closed base." --US Patent #5425497
    6. Re:Microsoft's Official View of the Situation by Sigma+7 · · Score: 3, 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. 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.
    7. Re:Microsoft's Official View of the Situation by peragrin · · Score: 2, Interesting

      While I understand that why is it only MSFT IIS and MS SQL that's affected. If apache and MS SQL was being attacked and it has happened then i could fully understand it, but only MS IIS, MS SQL sites are affected. while the flaw may not be MSFT's sole fault how could 500,00 people setup a server wrong including the DHS? Maybe MSFT's history of poor coding and security practices lead to unsafe default options? security should always be over applied and then removed in layers.

      Security like clothing works best in layers. You can always add a layer but you can only remove so many. prepare for an Arctic winter to start with, and you will have everything you need for the beach.

      --
      i thought once I was found, but it was only a dream.
    8. Re:Microsoft's Official View of the Situation by Dekortage · · Score: 4, Informative

      Well, to quote from the Hackademix FAQ on this issue... "Crackers put together a clever SQL procedure capable of polluting any Microsoft SQL Server database in a generic way, with no need of knowing the specific table and fields layouts. There's no Microsoft-specific vulnerability involved: SQL injections can happpen (and do happen) on LAMP and other web application stacks as well. SQL injections, and therefore these infections, are caused by poor coding practices during web site development. Nonetheless, this mass automated epidemic is due to specific features of Microsoft databases, allowing the exploit code to be generic, rather than tailored for each single web site."

      --
      $nice = $webHosting + $domainNames + $sslCerts
    9. Re:Microsoft's Official View of the Situation by Sancho · · Score: 4, Interesting
      As others have posted, it's pretty easy to prevent multiple instruction SQL injection. That's a function of the database driver, which Microsoft controls.

      It's much harder to prevent injection of additional parameters e.g. typing ' or '1'='1 into the text box--that's something that will be language and developer dependent. From my very brief scan of the details of this vulnerability, it looks like it would have been prevented if Microsoft had disallowed multiple statements in the driver.

      This page supports my interpretation. I note, specifically:

      Attackers carefully weighted the easiest spot, being a combination of

              * ASP classic, due to the poor coding standards among the average VBScripters who hardly known about prepared statements (even though they are supported)
              * ADO as the DB client layer, allowing stacked queries (multiple SQL statements together in a single string), which are not supported, for instance, by JDBC or by the mysql_query() PHP API
              * Microsoft SQL Server, because its Transact SQL supports a rich feature set including loops, metadata enumeration and Dynamic SQL (crucial for generalization), and because itâ(TM)s the most common ASP database back-end with such high-end features. Apparently, if stacked queries weren't allowed, this wouldn't nearly so easy to exploit.
    10. Re:Microsoft's Official View of the Situation by Qzukk · · Score: 2, Funny

      It\\'s broken, it\\\\\'s restrictive for normal users, and is a bad idea in the same way that forgiving developer for using bad html was, but it\'s there. never used it, but I know because of some bug that it was introducing in an unrelated application. Magic quotes is the absolute coolest thing since sliced arrays, or my name isn\\'t Jeffery O\\\\\\\\\\\\\\\\'Donnel!
      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    11. Re:Microsoft's Official View of the Situation by Cal+Paterson · · Score: 2, Interesting

      Ref. "National Highway Traffic Safety Administration".

      I'm aware this is pretty tangential, but I found it interesting that the Corvair was eventually rated to be a pretty reasonable car by the government body that Nader's book created.

    12. Re:Microsoft's Official View of the Situation by dedazo · · Score: 2, Insightful

      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.

      --
      Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
    13. Re:Microsoft's Official View of the Situation by Allador · · Score: 2, Insightful

      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.
  2. Dupe? by TubeSteak · · Score: 5, Informative

    500 Thousand MS Web Servers Hacked
    Posted by kdawson on Friday April 25, @11:48AM
    from the scream-and-shout dept.
    http://it.slashdot.org/it/08/04/25/1358234.shtml

    --
    [Fuck Beta]
    o0t!
    1. Re:Dupe? by calebt3 · · Score: 4, Interesting

      At least this one is more accurate in saying 500,000 web pages and not servers.

  3. Shameless Hibernate Plug by eldavojohn · · Score: 4, Informative

    You know, as an incompetent Java developer, I will take the time to explain why none of my web applications suffered from this.

    I use Hibernate. I use it with Java, although I know it's now available for .NET.

    A feature of Hibernate (aside from some efficient connection pooling and resource management like caching) is that you have to actually call a delete method to delete a row. Something like HibernateSession.delete(myObject); would have to be done. And while this might sound annoying or ruin some tools that are used to generate SQL statements, it protects me time and time again. Now, you can use HQL which is a bastardized version of SQL to generate similar things but, again, I think that you can't drop/delete in it (could be wrong, rarely use it).

    Try passing part of an SQL string into an object property and then merge/save it into the HibernateSession. Doesn't do the SQL injection stuff the bad guys want it to. Of course, I still use regular expression common utilities to validate the input, but assuming you didn't do that ...

    So why don't other people use Hibernate? Am I missing something about it that's bad?

    --
    My work here is dung.
    1. Re:Shameless Hibernate Plug by Cecil · · Score: 3, Insightful

      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.

    2. Re:Shameless Hibernate Plug by Blakey+Rat · · Score: 2, Insightful

      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.

  4. Dupe Dance by jd · · Score: 2, Informative
    Yay! We get a re-run of one of the more non-story events of recent times. The problem was spotted very quickly by IIS admins, as was noted before, and it's half a millon pages, not half a million sites. Well, unless all sites have one page and I've only been thinking they used hypertext links to more of their own content. It's unclear what percent of those sites were IIS, what were Apache (an easy server to misconfigure), and what were other web servers. Blaming it on IIS is easy, and there probably is some truth to the allegation that IIS has flaws when it comes to SQL support, but this time they almost (I said almost) have justification in crying foul when Microsoft gets blamed.

    What I don't get, though, is not only does this dupe the earlier story, it dupes ALL OF THE ERRORS as well. Sheesh!

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  5. This is typical for a dupe by panaceaa · · Score: 2, Informative

    Actually, most dupes on Slashdot are a couple days apart like this one. After that they fail to be news and tend not to get reposted.

    The extreme cases are actually measured in the years or hours. There's multiple cases of an article being duped 2-3 years later, especially when they're industry studies on how people use technology or occasionally about scientific discoveries. For the latter, it's often that a university announces they've done something and then publishes the results, which results in two very similar though arguably non-duplicative Slashdot articles.

    On the other side, sometimes there's big news and an editor decides to get it out fast without reading the current front page. I've seen dupes within the same hour, but more likely they're 2-3 articles apart in the worst cases. This was one of the arguments for introducing the Slashdot subscription model, in fact: Subscribers have early access to upcoming articles and can tell editors that an upcoming article is a dupe. In many cases (but not all) the editor pulls the dupe before it gets pushed to the front page.

  6. Re:Coldfusion Anyone? by S'harien · · Score: 2, Informative

    ColdFusion is most certainly vulnerable to SQL injection if you are not religiously using the CFQUERYPARAM tag inside your queries. Of course the database being queried needs to support multiple SQL statements in a single query (MySQL does, Access does not, can't speak for any others). http://www.adobe.com/devnet/coldfusion/articles/cfqueryparam.html

  7. little-bobby-tables-strikes-again dept by cyberstealth1024 · · Score: 2, Funny

    from the little-bobby-tables-strikes-again dept. Awesome xkcd reference! http://xkcd.com/327/
  8. Re:Quicky Question by cervo · · Score: 2, Informative

    I think you misunderstand the article. The attack injects javascript code into the text fields of the database. The attack is done by someone exploiting SQL injection on the website. Nothing to do with a web surfing account on the database computer. The attack inserts Javascript into every text field. If it was a message forum, this might be the from fields of an e-mail, the message text of posts, the subject fields of posts, etc.... Regular users using the forum are suddenly exposed to the javascript.

  9. Re:How does Apache avoid this? by Sancho · · Score: 2, Informative

    That's close.

    http://hackademix.net/2008/04/26/mass-attack-faq/#comment-7742 has a decent explanation of why this is primarily hitting IIS. SQL injection is common to many platforms, but Microsoft's database driver has some features that made it particularly easy to generalize the exploit. Specifically, prior knowledge of the table layout was apparently unnecessary to create the exploit, meaning that it was easy to hit a large number of websites in a short period of time.

  10. This is NOT an IIS problem by ShaunC · · Score: 2, Informative
    The exploit in question has nothing to do with IIS, period, whatsoever. It's being targeted at servers that run IIS because those are the ones most likely to have SQL Server as their database back-end. Plenty of companies have deployed a Linux/Apache/PHP stack that talks to a SQL Server backend via FreeTDS, for example, and some of them will be getting hit by this, despite not running a single instance of IIS.

    The query being used is exploiting features in Microsoft SQL Server, combined with a couple of external factors. Developers who have failed to check and sanitize user input, and DBAs who have not properly secured their databases. In order for your website to be owned through this attack:
    1. You must be running Microsoft SQL Server as your database platform
    2. Your web application must be vulnerable to SQL injection
    3. The SQL Server user that your web application authenticates as must have SELECT and UPDATE access to the sysobjects table
    Notice that nowhere in that list is IIS mentioned. In addition, plenty of shops meet the first criterion above, without meeting either of the other two. Unfortunately it's all too common that web applications are configured to use the "sa" account, or some functionally-equivalent clone thereof.

    If your web application can query dbo.sysobjects and get anything other than "Server: Msg 229, Level 14, State 5, Line 1" in response, it's time to hire an additional DBA. If your web application allows random queries to be passed into SQL Server in the first place, it's time to hire an additional developer. In either case, make "security" a bullet-point on the job posting.
    --
    Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
  11. Right, but... by Jeff+Molby · · Score: 2, Insightful

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

  12. Re:MS SQL Server is particularly vulnerable by Allador · · Score: 2, Insightful

    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.