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."
Re:Wrong tag (Score:5, Informative)
While the faulty script on a specific platform may be allowing the attack, it's absolutely a SQL injection attack, which is iterating through tables and appending strings to data it finds.
Re:Wrong tag (Score:4, Informative)
Poor programing practices, NOT IIS or SQL at fault (Score:5, Informative)
Anyone writing scripts that don't use parametrized stored procedures for the database or Linq needs to find a new line of work.
Re:Sounds like (Score:5, Informative)
actually, if you read the actual description of the attack is IS a SQL Injection attack on a web script. More advanced than "bobby tables", but basically the same problem.
We Got Hit By This (Score:5, Informative)
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.
Back to Basics (Score:4, Informative)
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.
Re:Poor programing practices, NOT IIS or SQL at fa (Score:1, Informative)
http://www.ibm.com/developerworks/library/l-sp2.html [ibm.com]
Re:Poor programing practices, NOT IIS or SQL at fa (Score:3, Informative)
I think he was more asking about a parameterized-SP vs parameterized-TSQL, not a SP vs LINQ debate (which is what you linked)
Re:We Got Hit By This (Score:4, Informative)
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.
Comment removed (Score:5, Informative)
AGAIN! AGAIN! (Score:2, Informative)
Re:We Got Hit By This (Score:5, Informative)
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.
Re:Wrong tag (Score:3, Informative)
SELECT * FROM Foods WHERE type = "hamburger" It'd have to be SELECT * FROM Foods WHERE type = "$1" PARAM1 = "hamburger"
This functionality you propose is available today, although not required (at least in Oracle where I'm familiar). Look into bind variables. in fact, let me google it for anybody reading this who wants to know how to prevent sql injection. http://www.lmgtfy.com/?q=bind+variables [lmgtfy.com] The positive side effect (again in Oracle) is that use of bind variables reduces the CPU cost of parsing SQL statements, so not only should you use bind variables, you should REALLY use bind variables.
Re:We Got Hit By This (Score:5, Informative)
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.
Re:So... it is really due to CPU's? Re:Wrong tag (Score:2, Informative)
Yes, aspects of SQL probably didn't help
More accurately, aspects of MS SQL didn't help. No other database (other than Sybase) is even remotely as vulnerable as MS SQL is (in the presence of bad programming) due to way it lets you combine multiple statements.
Other databases that let you combine multiple statements have a block syntax that makes it impossible to inject one statement in the middle of another one. That MS SQL "feature" is practically designed to make poorly written applications vulnerable to attacks in the worst possible way. If Microsoft has a clue, they will deprecate it, provide an option to turn it off, and require some sort of block syntax to do the same thing.