Posted
by
Soulskillon Friday June 11, 2010 @01:41PM
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."

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.

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

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 &amp; 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

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.

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.

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.

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.

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.

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.

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.

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

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.

The analysis is very good and even I could follow it -- and believe me, I'm not all that good at following things like that. And discussion also spells out why this wouldn't likely happen in a LAMP scenario -- no multiple query commands by default. It would seem to me that Microsof

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.

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!

you dont know what you are talking about. there is no 'rogue' query here. the query that is passed in in a sql injection attack has NO difference from the queries that are put in by the script itself. ie, UPDATE users SET group = admin WHERE user_id = X. this is an example of a possible VALID query that passes in by the system when an admin decides to make someone admin.

IF, you find a hole in the script, and are able to break the script code, and insert this query with your own userid and send it to sql,

does NOT differ anything. DELETE FROM users is STILL a valid sql query. the guy allowed it for that particular sql user in the database so that its script would be able to do delete operations, his/her script failed authorization and passed a delete query that was unauthorized to sql. sql, seeing that that db user was allowed delete queries, performed the query. everything is LEGIT.

You don't even have to go that far down. Technically, the script was doing as it was told! Just because the injection wasn't what you wanted, didn't mean the script didn't let it do it, just like the SQL server, and just like the CPU.

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

None of the above. It's the fault of the owner for having such a thing installed and/or not replacing/fixing it so it does not work that way.

"SQL Injection Attacks" are not the fault of SQL, but of programmers who don't realize that people will either deliberately or accidentally submit bad data, and that data might even include executable code.

There are many, very simple ways to avoid SQL injection attacks. If your web programming environment doesn't help you avoid them, then you are doing something wrong,

Your response interestingly demonstrates the cognitive dissonance required by the question. In the first paragraph, you blame the owner. In the second, the programmer. That's like saying on the one hand it's the property owner's fault for having a bad lock, and on the other it's the fault of the contractor he hired to build/install it. Both are true, from a certain point of view (Luke). The general public, cops, insurance company and the wife blame the guy who hired the contractor; the guy blames the contra

you're basically saying using SQL on it's own is very wrong, but SQL is not to blame.

SQL isn't to blame, is the script that doesn't use it properly (and the person who wrote it) that are to blame.
If I accidentally shot you, would you blame the gun or the idiot using the gun improperly?

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.

You're saying that the scripting language should sanitize the inputs given to the query language.
He's saying if the query language had been written differently, it would not require the scripting language to sanitize inputs.

f your front door had a lock that could be opened by anyone pushing a button clearly marked on the outside, and a robber pushed the button and came in, would you consider that a fault of the lock, the door, or the house?

You failed to give the correct option. The correct answer is: the idiot that installed such a lock.

if your front door had a lock that could be opened by anyone pushing a button clearly marked on the outside, and a robber pushed the button and came in, would you consider that a fault of the lock, the door, or the house?

It would be the fault of the eejit that set it up like that. Locks, doors and houses have no free will - it's not "the door's fault" that it works as designed.

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

Yes (or rather, no- see below), but it would be at the expense of making SQL a PITA for the very common cases where we're using hardcoded parameter values and there isn't a cats chance in hell of any risk; e.g. you wouldn't be able to say

SELECT * FROM Foods WHERE type = "hamburger"

It'd have to be

SELECT * FROM Foods WHERE type = "$1"
PARAM1 = "hamburger"

...or whatever syntax was used. And the reason would be that which caused SQL injection problems in the first place.

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.

No it isn't; the SQL is parsed before it looks at the hamburger. It doesn't blindly plug parameter values into the query string and then parse the resulting SQL.

Given that it's hypothetical syntax (or was meant to be), that does depend how it's implemented. It's quite possible that another string- rather than "hamburger" contains an embedded quote followed by some further commands.

Though it might not need to be that way, as the other reply to my original post said (and I accept that the second point I made may have been incorrect, though I still think that my main point- that requiring parameters for *all* variables would be a PITA compensation for some people's

In theory it could be implemented either as "plug then parse" or "parse then plug", but realistically the "parse then plug" approach is going to appeal much more to a database writer- who only cares about translating the query into the correct internal data structures with pointers to different parameters in the correct places. (Whether they point at literals, or subqueries, or arrays, or are still NULL waiting for their parameter settings, or whatever.)

I think the issue is a particular application or framework that may be popular. ASP.Net has been the tool of choice for about 8-9 years now with IIS based apps. I think it's wrong to suggest it's IIS or SQL specifically. ASP.Net's recommended input methods have been parametrized queries from the beginning. I'm more curious to find which application specifically is being targeted, not that it is IIS. This is very different from the worms in the late 90's and early 2000's that targeted IIS specifically.

Stored procedures CAN help with this issue. Not making parameters optional at the end, serializing data, using magic quotes etc... etc.....are all small things you can make your sites safer with....

Also QUERY LANGUAGE.... allows you to run queries. It is the badly written web app (or webserver) that allows the queries to be executed, it is not SQL's fault, wether it is Oracle (sql), MySWL or M$ Sql.....

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...

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.

sql was given a query that was exactly the same with other queries script gives it. with the SAME database user that script uses. its SCRIPT's fault for allowing an unauthorized user to run a sql query as s/he wants.

it is NOT a fault of SQL. sql does what query you give it. if you fail at the point of GIVING that query, you cant blame sql for it.

Apparently you aren't familiar with SQL injection. It almost always occurs the the SAME user database as the databases scripts use. And no one said it's the fault of the SQL language or database. SQL injection happens, almost always, because of bad app developers. In this case the ones designing and using the 3rd party scripts. Using well parametrized stored procedures in the RDBMS prevents it. Even if the web developers are idiots.

No one is saying that SQL Injection is a SQL vulnerability, it's just a nifty way to alter a database without exactly hacking into it. As such, when I hear "SQL Injection" I think "Someones not following security protocols". Or they thought "That will never happen to us".

This particular form of SQL injection *is* an MS SQL vulnerability. You couldn't mount an attack a tiny fraction as severe as this on on any other database other than Sybase (which MS SQL was originally derived from).

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.

And your general implication that "all code is equally vulnerable" is nonsense.

A nonsense typically promulgated by unethical companies (such as M$, anti-virus companies, even PHP promoters to some extent) trying to cover up the fact that some programming systems are more vulnerable, and more likely to encourage, allow or cause security errors, than others. Any programming system that assumes programmers or users are superhuman and never mak

The post you're referencing is BS. Most SQL databases support multiple statements seperated by semicolons, including MySQL and Postgres. The reason is simple, because batching statements into a single query is an optimization that improves performance.

However, even if we ignore that obviously false claim, you seem to be misinterpreting the point. The point is not about PHP or ASP or anything else. The point is about applications written in those languages, if done poorly are vulnerable to this kind of a

Honestly, no sql injection attack affecting THOUSANDS of sites and THOUSANDS of systems on Apache systems. Yes. Singular attacks by bonehead developer who don't know their head from a singularity. But Microsoft seems to have a record for allowing these things to continue to occur on THOUSANDS of system over and over (ie Code Red, Nimda, etc etc).

While Apache (which is installed on nearly twice as many systems) still remains far more secure and you never hear of anything like this happening on Linux or Ap

I've been a system admin at a fairly popular web hosting company before. Most of the attacks of this nature where not system-related at all, but were attacks against software such as WordPress, Joomla, etc: vulnerabilities in third party, cross-platform software that would have worked on Windows or Linux (We were using CentOS + cPanel). The issues weren't necessarily SQL injections, just software bugs. If this problem actually had anything to do with IIS, then perhaps mentioning it would be valid, but as

On the other side of the argument, how do you explain code red, nimda and the others whereas Linux and Apache has never had an event of such magnitude while having a greater server share (according to Steve Ballmer)? I work with dotnet developers and the way their inputs are cleaned but the framework is nonexistent. I can insert bad data a million different ways because they aren't cleansing it properly prior to insertion. I mentioned this and they looked at me clueless to what i was talking about but insis

The SQL code may be MSSQL specific, but there's nothing stopping anyone from making a MySQL version of it. And it has absolutely nothing to do with IIS. Even Apache running on top of MSSQL would be vulnerable.

The SQL code may be MSSQL specific, but there's nothing stopping anyone from making a MySQL version of it.

Not even close. MSSQL and Sybase are the only databases that are vulnerable to this form of SQL injection (in combination with sloppy programming).

With most databases, an SQL injection attack may result in predicate modification leading to information disclosure, too many rows getting updated, or too many rows deleted. No other databases allow an SQL statement to be trivially injected in the middle of

Technically, you are correct. But in this incident, the web server being used IS relevant.

1. The payload is IIS/MSSQL specific. The author WANTS that platform.

The platform should be more accurately described as Windows and MS SQL.

IIS has nothing to do with it - other than IIS and MS SQL are commonly used together. The attack works on ANY website that utilizes MS SQL as a database. Since many smaller websites have both the web server and database server on the same machine, they use IIS and MS SQL. This will also work if you have Linux/Apache as your web server and a separate server with Windows/MS SQL for your database. It will also work if you have Windows/Apach