Forgot your password?
typodupeerror
Microsoft Security The Internet IT News

Mass SQL Injection Attack Hits Sites Running IIS 288

Posted by Soulskill
from the oft-repeated-headlines dept.
Trailrunner7 writes "There's a large-scale attack underway that is targeting Web servers running Microsoft's IIS software, injecting the sites with a specific malicious script. The attack has compromised tens of thousands of sites already, experts say, and there's no clear indication of who's behind the campaign right now. The attack, which researchers first noticed earlier this week, already has affected a few high-profile sites, including those belonging to The Wall Street Journal and The Jerusalem Post. Some analyses of the IIS attack suggest that it is directed at a third-party ad management script found on these sites."
This discussion has been archived. No new comments can be posted.

Mass SQL Injection Attack Hits Sites Running IIS

Comments Filter:
  • Sounds like (Score:5, Funny)

    by by (1706743) (1706744) on Friday June 11, 2010 @01:43PM (#32538400)
    Bobby Tables [xkcd.com] strikes again.
  • by CharlieHedlin (102121) on Friday June 11, 2010 @01:54PM (#32538604)

    Anyone writing scripts that don't use parametrized stored procedures for the database or Linq needs to find a new line of work.

    • by ComaVN (325750) on Friday June 11, 2010 @02:01PM (#32538750)

      What is wrong with using regular parameterized queries instead of SPs?

      • by D Ninja (825055)

        A Stackoverflow answer [stackoverflow.com] explains the advantages very nicely.

        • Re: (Score:3, Informative)

          by PolyDwarf (156355)

          I think he was more asking about a parameterized-SP vs parameterized-TSQL, not a SP vs LINQ debate (which is what you linked)

      • Sp's provide a significantly higher degree of control over allowed values without having to resort to app-level scrubbing. They also tend to perform a little bit quicker.

        That said, things like multiple optional parameters will cause you to tear your hair out as a bad execution plan can be chosen. You have dynamic SQL inside sp's but there's no way I would use that on a public-facing site. Maybe 2008 solves some of this; I am anxious to try it out after skipping the mess that was 2005.
        • by Jaime2 (824950)
          Parameterized queries provide the exact same level of control without any app-level scrubbing. Performance is almost always nearly identical.

          Dynamic SQL inside sp's defeats the entire point of sp's. The only difference is that you have to do data sanitization with T-SQL instead of a language that has evolved since the 1980s.
    • by slifox (605302) *
      Generating SQL statements in a script is fine...

      Here's a more accurate version: Anyone writing code that doesn't validate input needs to find a new line of work.
      • by Galestar (1473827) on Friday June 11, 2010 @02:26PM (#32539170)

        Here's a more accurate version: Anyone writing code that doesn't sanitize input needs to find a new line of work.

        Fixed that for you

        • by blhack (921171)

          How can you even possibly *not* sanitize the inputs? Python's mysql module, for instance, does the work for you:

          cursor.execute("select grade from grades where student = %s", ("bobby; drop table grages"))

          would be completely fine.

        • I was able to generate some errors by putting carefully crafted data into a website form once. I notified the company that made the software and their two programmers were such arrogant jackasses. "Oh well they are stored procedures so it's not a problem." I was so annoyed at their arrogance I got permission to attempt to crack the website and basically got full access to the box and all the data and a lot of data on their network through windows file sharing (sql server had some stored procedures to execut
      • by Kjella (173770)

        Here's a more accurate version: Anyone writing code that doesn't validate input needs to find a new line of work.

        How often does this happen in a one-developer situation (outside newbie projects)? The problem is that there's supposed to be exactly one sanitizing layer, for example if you percent encode or HTML encode or whatever twice, you often get a wrong result like "Barnes & Noble" instead of what you expected. Every function validating everything is likely to be both a performance killer and the results being plain wrong. On the drawing board it's easy, draw a big line and say dirty strings on this side, c

        • by ranton (36917)

          Here's a more accurate version: Anyone writing code that doesn't validate input needs to find a new line of work.

          How often does this happen in a one-developer situation (outside newbie projects)?

          I have worked on multiple e-commerce sites written by other original authors, and developers allowing unvalidated text into SQL queries is more common than I would like to admit. Plenty of small companies pay inexperienced web developer peanuts to put up their websites, and they sure get what they pay for.

          I would agree that it doesnt happen often outside of inexperienced web developers, but far too many sites are written by them for it to be discounted as a rare phenomenon.

    • by barzok (26681)

      Or at least Prepared Statements (if your DBA is a PITA and won't let you go heavy on the Stored Procedures).

    • by Jaime2 (824950)
      I just found out the guy who works in the office next to me has never heard of the practice of parameterizing database statements to avoid SQL injection. He has about five years of development experience at several major US companies. This was the first project that I worked with him on that he wrote data access code. Apparently a lot of people still don't get the point. I recommended that he be "quarantined and trained" to my boss, but I'm sure he'll go right on writing code.

      95% or the people I talk
      • by tsm_sf (545316)
        If your coworker thinks he's writing secure code, you have a problem.

        If you think you're writing secure code, you have two problems.
        • by Jaime2 (824950)
          You too need a demonstration. BTW, I don't need stored procedures to handle permissions because all of my applications are three tier and frond end users can't even log in to the database server.
  • graceful (Score:5, Funny)

    by MagicMerlin (576324) on Friday June 11, 2010 @02:04PM (#32538800)
    It was nice of them to deallocate the cursor when done. Thanks!
  • We Got Hit By This (Score:5, Informative)

    by Anonymous Coward on Friday June 11, 2010 @02:14PM (#32538930)

    I run a site that got hit by this. It's hosted by Rackspace Cloud, so one presumes that IIS and MSSQL were patched up. We aren't using any kind of ad network, so I think the attackers were just looking for ASP sites that used queries. We got hit because we failed to sanitize inputs in one spot.

    We were lucky, though. Since the attack blasts the script code into every column of every table it can get its hands on, it actually broke the SQL queries that pull up the page content, so users just saw an error message instead of page content + malware.

    • by lgw (121541)

      Somone please mod parent AC up - first useful information in this discussion!

    • by MisterZimbu (302338) on Friday June 11, 2010 @02:41PM (#32539476)

      Just as a followup to this, it's not actually a fault or exploit in MSSQL or IIS; just that the SQL being injected is specific to MSSQL and completely valid. This can and will happen in any future version of IIS or MSSQL unless specific action is taken by Microsoft to prevent the underlying technique used to do it, which is unlikely as it will break a large percentage of perfectly legitimate applications.

      The same attack could probably be modified to hit Oracle, MySQL, or other DBMSes with minimal effort. I don't even really know why IIS is even mentioned as the actual server software is irrelevant. This attack would just as easily hit MSSQL databases with website front ends hosted on Apache or pretty much anything else, no code changes needed. This isn't even the first time this has happened. A couple years pretty much the exact same script was used to deface sites on about the same scale as this one did.

      The blame should be placed on the developers of the poorly written 3rd party software that doesn't sanitize its inputs or (preferably) use parameterized queries and stored procedures.

      • by gbrayut (715117) on Friday June 11, 2010 @04:48PM (#32541596) Homepage

        Here is a great overview of the technique that was used:

        http://www.virusbtn.com/pdf/conference_slides/2009/Maciejak-Lovet-VB2009.pdf [virusbtn.com]

        While they are targeting IIS and MSSQL the real issue is developers that don't sanitize the parameters that get sent to the database. The SQL is encoded in at least 2 different layers, so the only keywords that appear in the URL are ;dEcLaRe%20@s%20vArChAr(8000) and ;EXEC%20(@S); and It would be pretty difficult for Microsoft to block those without affecting legitimate usage. If you are using LINQ, Stored Procedures, or Parameterized Queries based on SqlCommand then this wouldn't work against your site or library. Mainly queries created as raw text strings have this vulnerability, and in this case it appears that some library or module used by a number of sites used raw SQL strings instead of the best practices recommended by Microsoft and every other SQL and web server vendor.

      • by butlerm (3112) on Friday June 11, 2010 @06:44PM (#32543508)

        it's not actually a fault or exploit in MSSQL

        Actually, it is. Or rather MS SQL Server is much more susceptible to these kind of attacks (in combination with poorly written code) than virtually any other database.

        The reason why is because in SQL Server is perfectly legal to include more than one SQL statement at a time separated by semicolons. So if you have an incompetent programmer who doesn't bind variables or sanitize input properly, an attacker can trivially inject any SQL he wants.

        Other databases are vulnerable to SQL injection attacks to a degree. but in a much more limited fashion because an attacker *cannot* start an entirely new SQL statement in the middle of another one.

        Other databases (notably Oracle) that support multiple statement execution require you to wrap the whole thing in "begin"/"end" blocks so they are not vulnerable to the particularly severe form of this attack that SQL Server is vulnerable to. That is why if an SQL injection attack is in the news, it is inevitably an attack on a poorly written MS SQL application.

  • Back to Basics (Score:4, Informative)

    by achbed (97139) * <sd@noSpAm.achbed.org> on Friday June 11, 2010 @02:20PM (#32539046) Homepage Journal

    http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet [owasp.org]

    How many times do we need to say the same thing before people start listening? Oh, that's why we still have STDs. Because people don't take basic steps to reduce risk by orders of magnitude.

    • http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet [owasp.org]

      How many times do we need to say the same thing before people start listening?

      Nice cheat sheet but I was a bit surprised to see "* Also Enforce: Least Privilege" listed under "Additional Defenses". Perhaps it is just my opinion but it seems least privilege should be very high on the list as has the potential to negate many application code and query instances where a developer may make a mistake or is simply lax in their methods.

      When I had

  • SQL injections don't target SQL servers or web servers. They target poorly written scripts. This does not "target Web servers running Microsoft's IIS software" as the summary says. It targets some stupid advertising script that all the sites had in common. Look at the analysis of the attack. It does s GET on /page.aspx and passes it utm_content which contains an escaped SQL statement.

    A quick Google search shows that utm_content is part of Google Analytics. Does this mean it is a bug in Google Analyti

    • As far as I know using Google Analytics is nothing more then including a strong on your html output that instructs the browser to get some javascript from google to record the traffic. The server itself never executes anything from google, it would be the same as if you included the google logo on your pages. Your server ain't involved.

      For a 3rd party script to have an effect it somehow needs to be run or the server or have at a minimal its values parsed. Google Analytics (at least for small customers, don

    • by butlerm (3112)

      SQL injections don't target SQL servers or web servers.

      This particularly severe type of attack only affects poorly written MS SQL and Sybase applications, due to the way those two database allow SQL statements to be combined.

      Other databases are vulnerable in combination with poorly written applications too, just not nearly as badly.

  • AGAIN! AGAIN! (Score:2, Informative)

    by Ashcrow (469400)
  • Well yes... yes it could. I read the article completely. It is caused by a weakness in some ad placement code... ad placement code that runs on IIS through ASP or something like that. It sounds as if this could just as easily happen to a LAMP server if the same shoddy code were inserted into a Linux/Apache/MySQL/PHP stack. But why hasn't it happened?

    The article doesn't go into what ad company put the code out there or if that company also supports LAMP servers. I think those bits would be good to know.

  • So my impression is that the script isn't targeting specific apps but ASP-based servers and trying to do generic SQL-injection?

    The question is, can people identify which apps have been exploited by the attack vector?

NOWPRINT. NOWPRINT. Clemclone, back to the shadows again. - The Firesign Theater

Working...