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."
Sounds like (Score:5, Funny)
Re:Sounds like (Score:5, Funny)
Take it you didn't read TFA?
Nope.
Or just trying to be the first to jump on the Bobby Tables meme...
Yup.
...without actually understanding what it means?
It means you shouldn't name your kid with SQL in his name?
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.
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:Poor programing practices, NOT IIS or SQL at fa (Score:4, Interesting)
What is wrong with using regular parameterized queries instead of SPs?
Re: (Score:2)
A Stackoverflow answer [stackoverflow.com] explains the advantages very nicely.
Re: (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: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Here's a more accurate version: Anyone writing code that doesn't validate input needs to find a new line of work.
Re:Poor programing practices, NOT IIS or SQL at fa (Score:5, Insightful)
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
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Or at least Prepared Statements (if your DBA is a PITA and won't let you go heavy on the Stored Procedures).
Re: (Score:2)
95% or the people I talk
Re: (Score:2)
If you think you're writing secure code, you have two problems.
Re: (Score:2)
graceful (Score:5, Funny)
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.
Re: (Score:2)
Somone please mod parent AC up - first useful information in this discussion!
Re: (Score:2)
Don't be absurd, /. isn't about being informative. It's about dropping memes in at every available opportunity and making puns based on something unrelated.
Your injection of antagonism iis not contributing to everyone else's enjoyment of this site. What does this help us see? Quell humor and all you end up with is a dry, boring forum. Natalie Portman. :-P
Re: (Score:2)
Clippy meme?
I see you are trying to do a SQL injection attack. Do you want to:
1/ find out what a SQL injection is?
2/ find out how to stop SQL injections?
3/ let me show you how to do the SQL injection properly?
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.
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: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.
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: (Score:2)
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
Headline just totally wrong (Score:2)
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
How exactly? (Score:2)
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
Re: (Score:2)
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)
Not IIS (directly) ... could it happen to anybody? (Score:2, Insightful)
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.
Re: (Score:2)
Thanks for that. But it seems my rant was pointless and irrelevant. Turns out this is, in fact, just another MS SQL injection exploit after all.
http://nsmjunkie.blogspot.com/2010/06/anatomy-of-latest-mass-iisasp-infection.html [blogspot.com]
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
list of vulnerable apps? (Score:2)
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?
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)
Re:Wrong tag (Score:4, Insightful)
Re:Wrong tag (Score:4, Insightful)
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!
holy shit. (Score:2)
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,
Re: (Score:2)
Re: (Score:2)
So... it is really due to CPU's? Re:Wrong tag (Score:4, Insightful)
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?
Re: (Score:2)
So it's Silicon's fault? Clearly this means we need to ban sand immediately.
That's it! No Sand In The Datacenter!
Re: (Score:2)
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.
Comment removed (Score:5, Informative)
Re: (Score:2)
Geez guys. There's more finger pointing in here than a meeting between BP, Transocean, and Haliburton.
Yeah. Stop pointing the finger, people!
It's not a flaw in any of the technologies used, it's a flaw in how they were used together. The programmers who wrote the scripts didn't properly validate incoming data. That's all there is too it.
Yes, aspects of SQL probably didn't help, but quite honestly, it was a programming decision to use SQL in the first place.
Either way, fix it!
Um.. wait. Now you've done it too. :P
Re: (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
Re: (Score:2)
Obviously I would blame the federal government :p
Ok, that was too easy, I'm gonna stand back and watch the flame war grow right off the very trail of this post :p
No, wait, I blame the robber. He should've set the Evil Bit and then I would've known to deny him entry...
No wait, I blame the lock, because
Hold on, I should probably blame myself, for having anything I considered my own ...
Oh wait, now we're back to blaming the federal gov't...
Oh, I give up! Take it all!!!
(Que mods who don't recognize a joke and q
Re: (Score:2)
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,
Re: (Score:2)
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
Re: (Score:2)
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?
Re: (Score:2, Insightful)
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.
Re: (Score:2)
He's saying if the query language had been written differently, it would not require the scripting language to sanitize inputs.
Re: (Score:2)
Re: (Score:2)
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.
Seems to me that this is a validation problem.
Re: (Score:2)
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.
Re: (Score:2)
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
...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"
Assembling SQL statements by co
Re: (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: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
I'm not sure what the payoff would be in doing it the
Re: (Score:2)
Re: (Score:2)
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.
A query language that doesn't allow literals? That is not very practical.
Or a website framework that doesn't allow you to construct queries at runtime? That is not very practical either.
This is not SQL's fault (although MS SQL is particularly susceptible) - it is the fault of programmers who do not have a clue.
Re: (Score:2)
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 .....
Re: (Score:3, Insightful)
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:Wrong tag (Score:5, Interesting)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
it's absolutely a SQL injection attack
Exactly; just look at the logs in the second link. How hard is it anyway to program your scripts to ignore commands in aLtErNaTiNg CaPs?
Re: (Score:2)
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".
Re: (Score:2)
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).
Here let me fix that for you (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If it is platform independent (Score:2)
Re: (Score:2)
Maybe one of the people with the imaginary friend can give us the chapter and verse about "building your house on sandy ground".
Re: (Score:2)
That's still better than building your castle on top of a swamp! [imdb.com]
Re: (Score:2)
why are only IIS sites affected?
While this might not relate to the article.
There are quite a few bugs that require case insensitivity, It wouldn't surprise me to see and bug that's 'only on IIS' actually cause problems on a server with mod_speling.
Re: (Score:2)
The parent only said it COULD be PHP. If only IIS sites are affected, I'd imagine it's probably a language that's exclusive to Windows.
Re:If it is platform independent (Score:5, Insightful)
Re: (Score:2)
SQL injection is completely independent of web server
No it isn't [slashdot.org]
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
Re: (Score:2)
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
Re: (Score:2)
why are only IIS sites affected?
It is not an IIS problem. This particularly severe type of attack only works with MS SQL and Sybase applications, and MS SQL only runs on Windows servers, which typically run IIS.
MS SQL in combination with Apache would be just as vulnerable, given the same sloppy programming practices. Other databases as well, just not to the same degree.
Re: (Score:2)
Re: (Score:2, Insightful)
'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: (Score:2)
That's why I use a LAXP setup. /duck
Re: (Score:2)
This is why I use a card catalog and filing cabinet.
Re: (Score:2, Troll)
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2, Interesting)
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 [blogspot.com] stated it quite well:
Re: (Score:2)
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.
And MySQL doesnt' seem to be reliably safer. http://www.google.com/search?hl=en&client=opera&hs=u5U&rls=en&q=mysql+sql+injection&revid=634420364&sa=X&ei=mowSTNjUJoT7lweXo-32Bw&ved=0CF8Q1QIoAw [google.com]
One has to balance the featureset as well before relying on PHP and MySQL.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
From a security standpoint, PHP developers are the worst of the web app world. By far.
But... (Score:2)
But I thought platform independence was a good thing!
Re: (Score:2)
Of which you then leave out:
So it looks like a SQL injection attack against a third party ad management script.