Slashdot Mirror
Mass SQL Injection Attack Hits Sites Running IIS
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."
Bobby Tables strikes again.
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.
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. its NOT related to sql. it is named a sql injection attack, but its not due to sql.
Read radical news here
Anyone writing scripts that don't use parametrized stored procedures for the database or Linq needs to find a new line of work.
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.
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, but with SQL instead...
What is wrong with using regular parameterized queries instead of SPs?
Be wary of any facts that confirm your opinion.
It was nice of them to deallocate the cursor when done. Thanks!
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!
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
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?
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.
http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
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.
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
AccountKiller
I think he was more asking about a parameterized-SP vs parameterized-TSQL, not a SP vs LINQ debate (which is what you linked)
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.
1. The payload is IIS/MSSQL specific. The author WANTS that platform.
2. The method of injection normally doesn't work on mySQL. jameswilkes over at http://nsmjunkie.blogspot.com/2010/06/anatomy-of-latest-mass-iisasp-infection.html stated it quite well:
Lou
It certainly is SQL injection. A query was allowed to run which did bad things. I run everything through well parametrized stored procedures. The webserver client isn't allowed to look directly at any tables, insert, delete, or do ANYTHING other than run those set stored procedures. No 'bad' queries are allowed to run on my server because of that. These folks used an easy-to-use but insecure framework, and got the results that very often happen in that circumstance.
It happened again since the 8th: http://blog.sucuri.net/2010/06/mass-infection-of-iisasp-sites-2677-inyahoo-js.html
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 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.
Take off every 'sig' for great justice.
Perhaps someone should describe variable parametrization 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.