Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Microsoft Security The Internet IT News

Mass SQL Injection Attack Hits Sites Running IIS 288

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:
  • Re:Wrong tag (Score:4, Insightful)

    by Michael Kristopeit ( 1751814 ) on Friday June 11, 2010 @01:55PM (#32538614)
    it is due to sql... if the databases and website frameworks forced a different query language that forced variable parametrization, there wouldn't be any injection risk.
  • Re:Wrong tag (Score:3, Insightful)

    by endikos ( 195750 ) * <bill@endikos.com> on Friday June 11, 2010 @01:58PM (#32538676)

    Not saying it is a problem with SQL. Some SQL statements are being injected into a script, which is then happily executing them. The problem is with the script, but SQL is being injected into it... which is why its known as SQL injection. The term does not imply that the root of the problem is with SQL itself. It's a variant of Code Injection [wikipedia.org], but with SQL instead...

  • Re:I suspect.... (Score:2, Insightful)

    by bsDaemon ( 87307 ) on Friday June 11, 2010 @02:07PM (#32538822)

    'cause, you know... no SQL injection has ever occurred in a LAMP environment before. If the problem is SQL-related, then the web server being used is pretty much irrelevant.

  • Re:Wrong tag (Score:4, Insightful)

    by BitterOak ( 537666 ) on Friday June 11, 2010 @02:10PM (#32538874)

    it is due to sql... if the databases and website frameworks forced a different query language that forced variable parametrization, there wouldn't be any injection risk.

    Mod parent up. According to the GP "it is wrong to picture this as a lack or shortcoming of sql. sql is doing what query it is given to it. nothing else." That's precisely the problem! Most security vulnerabilities are the result of software doing exactly what it is told to do!

  • by Fubari ( 196373 ) on Friday June 11, 2010 @02:10PM (#32538876)

    it is due to sql...

    Huh? It happened because they use sql?
    Following that line of thought,
    isn't it really due to the use
    of CPU's in those servers?

  • by Galestar ( 1473827 ) on Friday June 11, 2010 @02:26PM (#32539170) Homepage

    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 Dragonslicer ( 991472 ) on Friday June 11, 2010 @02:39PM (#32539444)
    SQL injection is completely independent of web server, programming language, and database system. An idiot can write vulnerable code in any language, using any database system, and run it on any web server. My guess about why this is only targeting IIS is that the attack is against some specific ASP.NET code, so the vulnerability isn't in IIS, but the vulnerable code only runs on IIS.
  • by DaTroof ( 678806 ) on Friday June 11, 2010 @03:00PM (#32539820)

    How about we try an analogy that's a little closer to the original topic? Let's say the exploit injected system commands instead of SQL commands. The fault wouldn't lie with the operating system, even though that's what was ultimately compromised. It would lie with the script that failed to sanitize input properly.

    Same thing with SQL. The problem isn't the query language itself. The problem is how the script executes queries.

  • by erroneus ( 253617 ) on Friday June 11, 2010 @04:53PM (#32541698) Homepage

    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. But as many others, I am inclined to blame Microsoft for this somehow.

    Let's face the fact, though, that Microsoft didn't have a direct hand in this. SQL did what it was told to do. IIS did what it was told to do. The script did what it does... and without specific details, I have no way to know if the scripting language itself was compromised or of it is the script itself that enabled this. But I can say that Microsoft has developed a culture that enables all of this.

    What do I mean by that? "Visual X programming" and other RAD tools are designed to get code written and published as quickly as possible. What is the problem with that? I gotta say, if code is to be generated quickly, it will likely receive less QA review... if any at all. So if that programming language doesn't come with seat belts and air bags, then it is just begging to be exploited in this way.

    PHP and many other languages that are typically used in LAMP stacks are edited with a text editor most of the time. Fancy IDEs exist but many people prefer the text editor. It's fast and simple. Hard to beat fast and simple... and programming with clippy at your side is nothing that any coder I know would be interested in.

    Microsoft breeds a culture of sloppy coding practices. This is a large part of the problem and it started with DOS when people started writing directly to the display because using BIOS hooks were too slow. But then it got worse when advanced processors emerged... you know, those i386 processors? They were DESIGNED to make virtual machines. What happened? You know what happened. We could have been using some awesome virtualization technologies decades before now and a lot easier than now. Once again, programmers who don't follow the rules and don't use good practices and procedures strike again. Third parties who have felt the need to insert "virtual device drivers" in order to access more system resources or some such thing, bypassing the OS for whatever reason. They bring instability to Microsoft Windows without question. But who bred the culture in the first place? Who added "compatibility with bad applications" support into their operating systems? That'd be "Developers! Developers! Developers!" Microsoft. They don't care of the developers are good developers. Only that there are a lot of them.

  • Re:holy shit. (Score:2, Insightful)

    by omni123 ( 1622083 ) on Saturday June 12, 2010 @12:41AM (#32546514) Homepage

    Perhaps someone should describe variable parametrization [wikipedia.org] to you? A language that implemented it would take a variable in place of the 'userid' statement from the DELETE FROM users WHERE userid = userid; this variable would not allow any escape characters to be a part of it and therefore destroy injection possibilities.

    When was the last time C had injection (buffer overflows are another story!)? It doesn't. Because if you have void func(int arg) you can't call func(1; exit(1)). This is a fundamental flaw in SQL and technologies that use ORM (i.e. a variable parametrization layer on top) do not regularly deal with issues like this.

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Working...