Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mass SQL Injection Attack Hits Sites Running IIS

Soulskill posted more than 4 years ago | from the oft-repeated-headlines dept.

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

cancel ×

288 comments

Sorry! There are no comments related to the filter you selected.

Wrong tag (1, Interesting)

unity100 (970058) | more than 4 years ago | (#32538390)

its not 'sql'. its IIS. sql accepts any query given to it by the program. its the script's job not to let in any malicious queries. its a script fault.

Re:Wrong tag (0)

Anonymous Coward | more than 4 years ago | (#32538462)

It matters not, inb4theonslaughtofZOMGapachemysql

Re:Wrong tag (4, Informative)

endikos (195750) | more than 4 years ago | (#32538518)

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 (3, Informative)

unity100 (970058) | more than 4 years ago | (#32538558)

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.

Re:Wrong tag (4, Insightful)

Michael Kristopeit (1751814) | more than 4 years ago | (#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 (3, Insightful)

BitterOak (537666) | more than 4 years ago | (#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!

holy shit. (1)

unity100 (970058) | more than 4 years ago | (#32539754)

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, IT IS NOT SQL'S PROBLEM. sql is just doing what it is given to it, properly. it is the script's fault for allowing you to be able to break the script, and run a query that was limited to only admins.

Re:holy shit. (0)

Khyber (864651) | more than 4 years ago | (#32540072)

"You don't know what you are talking about."

As someone that exploits these attacks for testing my business site DAILY, *YOU* don't know what you are talking about.

So... it is really due to CPU's? Re:Wrong tag (3, Insightful)

Fubari (196373) | more than 4 years ago | (#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?

Re:So... it is really due to CPU's? Re:Wrong tag (1)

ashridah (72567) | more than 4 years ago | (#32538922)

So it's Silicon's fault? Clearly this means we need to ban sand immediately.

That's it! No Sand In The Datacenter!

Re:So... it is really due to CPU's? Re:Wrong tag (1)

Michael Kristopeit (1751814) | more than 4 years ago | (#32539104)

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?

Re:So... it is really due to CPU's? Re:Wrong tag (0)

Anonymous Coward | more than 4 years ago | (#32539352)

the answer is house right?

Re:So... it is really due to CPU's? Re:Wrong tag (1)

Michael Kristopeit (1751814) | more than 4 years ago | (#32539544)

you're not even sure what you yourself consider?

Re:So... it is really due to CPU's? Re:Wrong tag (1)

drachenstern (160456) | more than 4 years ago | (#32539692)

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 que trolls who don't recognize this is not a troll-starting-post)

Re:So... it is really due to CPU's? Re:Wrong tag (1)

panda (10044) | more than 4 years ago | (#32539750)

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, very wrong.

Re:So... it is really due to CPU's? Re:Wrong tag (1)

Michael Kristopeit (1751814) | more than 4 years ago | (#32539954)

so the thing that requires "replacing/fixing" in this example is direct use of SQL, but the user is to blame for the exploit?

why is "microsoft" and "internet" still keywords, but now "sql" has now been removed after a few people wrongly complained? you're basically saying using SQL on it's own is very wrong, but SQL is not to blame.

Re:So... it is really due to CPU's? Re:Wrong tag (2, Insightful)

DaTroof (678806) | more than 4 years ago | (#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.

Re:So... it is really due to CPU's? Re:Wrong tag (1)

Michael Kristopeit (1751814) | more than 4 years ago | (#32540054)

if the database server required queries to use parametrized variables, there would be no room for injection exploits.

Re:So... it is really due to CPU's? Re:Wrong tag (1)

AndrewNeo (979708) | more than 4 years ago | (#32539134)

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.

Re:So... it is really due to CPU's? Re:Wrong tag (1)

Michael Kristopeit (1751814) | more than 4 years ago | (#32539292)

most scripts use query parametrization libraries on top of SQL... so when the script author chose to not use a more secure way of utilizing SQL it suddenly becomes an exploit of something else?

on 9/11 was the airplane exploited, or the gasoline? everyone is to blame, and protecting a method of instructing a server to do something that doesn't inherently protect against malicious user input serves nothing.

Re:So... it is really due to CPU's? Re:Wrong tag (5, Informative)

squiggleslash (241428) | more than 4 years ago | (#32539614)

Geez guys. There's more finger pointing in here than a meeting between BP, Transocean, and Haliburton.

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!

Re:So... it is really due to CPU's? Re:Wrong tag (1)

Michael Kristopeit (1751814) | more than 4 years ago | (#32539846)

the line of thought is that SQL is the last place that malicious input penetrated in this attack.... SQL's inherent non-use of variable parametrization was exploited. SQL was exploited.

Re:Wrong tag (2, Insightful)

endikos (195750) | more than 4 years ago | (#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:Wrong tag (4, Interesting)

LurkerXXX (667952) | more than 4 years ago | (#32539998)

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.

Re:Wrong tag (1)

magarity (164372) | more than 4 years ago | (#32539110)

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:Wrong tag (0)

Anonymous Coward | more than 4 years ago | (#32538536)

Nor is it IIS. This is a third party script that utilizes a database. The script apparently allows external data to be provided, doesn't validate it and then performs unsafe database access. It could be PHP on Apache on Windows with MySQL just as easily as it could be VBScript on IIS on Windows with SQL Server. The platform itself is irrelevant.

What makes this interesting and problematic is that the third party script is common, but that's what you get for trusting third party code to display ads on your web site.

Re:Wrong tag (1)

jsnipy (913480) | more than 4 years ago | (#32538572)

Sounds to me like the liability rests on the third party who produces the script. Has there ever been such a case?

Re:Wrong tag (1)

unity100 (970058) | more than 4 years ago | (#32538694)

its possible that its script's fault. it is also possible that its iis's fault, if it is not providing proper functions for easily filtering sql queries, or sanitizing them.

Re:Wrong tag (1)

jsnipy (913480) | more than 4 years ago | (#32538766)

However as others have pointed out, that is not really the role of IIS (by default). It is a development issue of building parameters rather than concatenating a statement string together.

If it is platform independent (1)

Presto Vivace (882157) | more than 4 years ago | (#32538702)

why are only IIS sites affected?

Re:If it is platform independent (1)

$RANDOMLUSER (804576) | more than 4 years ago | (#32538806)

why are only IIS sites affected?

Maybe one of the people with the imaginary friend can give us the chapter and verse about "building your house on sandy ground".

Re:If it is platform independent (1)

toastar (573882) | more than 4 years ago | (#32538882)

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:If it is platform independent (1)

jimicus (737525) | more than 4 years ago | (#32539358)

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 (4, Insightful)

Dragonslicer (991472) | more than 4 years ago | (#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.

Re:If it is platform independent (1)

capnchicken (664317) | more than 4 years ago | (#32539490)

It looks like, to me, that it is an attack on Google Analytics and MS SQL Server.

So the target base HAS to have MS SQL (for the code that loops through the specific tables to find your table names to work) and you have to be running Google Analytics (could be wrong about that though) for this to work, IIS and ASP.NET might just be targeted because you are more likely to run into an MS SQL Server. My gut tells me that the attack could possibly be modified to attack other databases still using Google Analytics.

Re:Wrong tag (1)

Monkeedude1212 (1560403) | more than 4 years ago | (#32538580)

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:Wrong tag (0)

Anonymous Coward | more than 4 years ago | (#32539818)

when i hear "SQL Injection" I think of a giant hypodermic needle, full of alphabet soup, being injected into Bill Gates' nose.

I am so fucking high right now.

Here let me fix that for you (1)

DaveV1.0 (203135) | more than 4 years ago | (#32538708)

its not 'sql'. its not IIS. sql accepts any query given to it by the program. its the script's job not to let in any malicious queries. its a scripter's fault.

Re:Wrong tag (1)

Michael Kristopeit (1751814) | more than 4 years ago | (#32538852)

if SQL forced variable parametrization, there would be no injection risk. this most certainly is an exploit of SQL, not IIS.

Re:Wrong tag (0)

Anonymous Coward | more than 4 years ago | (#32539084)

If SQL forced variable parametrization people would look around for a language that allows not parametrized queries. It's so hard to understand?

Re:Wrong tag (1)

Michael Kristopeit (1751814) | more than 4 years ago | (#32539374)

so because people want the feature that was used to exploit it, exploiting that feature is no longer considered an exploit. not hard to understand at all.

Sounds like (5, Funny)

by (1706743) (1706744) | more than 4 years ago | (#32538400)

Bobby Tables [xkcd.com] strikes again.

Re:Sounds like (0)

Anonymous Coward | more than 4 years ago | (#32538538)

Nope, nothing like it at all. Take it you didn't read TFA? Or just trying to be the first to jump on the Bobby Tables meme without actually understanding what it means?

Re:Sounds like (5, Funny)

by (1706743) (1706744) | more than 4 years ago | (#32538652)

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 (4, Informative)

Nohea (142708) | more than 4 years ago | (#32538824)

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.

Re:Sounds like (1)

crow_t_robot (528562) | more than 4 years ago | (#32539308)

Pro-tip: Both relate to not sanitizing inputs before running them in your SQL database.

INJECT THIS !! (0)

Anonymous Coward | more than 4 years ago | (#32538440)

DROP DA TABLE AND REACH FOR IT MISTER

You are not logged i

n. You can log in now using the convenient form below, or Create an Account, or post as Anonymous Coward.

wow (1)

pROCKrammer (1246962) | more than 4 years ago | (#32538460)

how webserver could work with SQL? Maybe its scripts problem?

in b4 (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32538476)

in b4 legions of freetards blame this on microsoft and the usual HURR DURR IM RUNNAN LUNIX. even though anyone with half a brain would recognize this as an sql injection, which is 100% platform independant.

But... (1)

MrEricSir (398214) | more than 4 years ago | (#32538732)

But I thought platform independence was a good thing!

Re:in b4 (1)

wygit (696674) | more than 4 years ago | (#32538832)

from the article:

"What do all these sites have in common? They are all hosted on IIS servers and using ASP.net. This is the output of our scanner against www.intljobs.org:"

Re:in b4 (1)

Lunix Nutcase (1092239) | more than 4 years ago | (#32539128)

Of which you then leave out:

So it looks like a SQL injection attack against a third party ad management script.

WHY (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32538560)

Why would ANYONE use IIS for a high traffic, high-profile site? Ridiculous.

Re:WHY (1)

GordonBX (1059078) | more than 4 years ago | (#32539182)

Someone please mod parent clueless rather than insightful. Neither IIS nor SQL are at fault in this case, it is a third party add-on that is being exploited. There is nothing here that uniquely makes IIS or SQL more or less vulnerable than, say, Apache and MySQL. It is perfectly possible to code a LAMP application that is equally vulnerable, and recent attacks on applications such as Wordpress prove this is true. The article IMHO is being needlessly attacking towards IIS. It's like saying 'Mass SQL injection attack hits x86 servers' therefore somehow implying that servers running on Arm would be secure.

Re:WHY (0)

Anonymous Coward | more than 4 years ago | (#32540150)

Called it,
http://news.slashdot.org/comments.pl?sid=1683322&cid=32538476

enjoy being a freetard.

Poor programing practices, NOT IIS or SQL at fault (4, Informative)

CharlieHedlin (102121) | more than 4 years ago | (#32538604)

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 (3, Interesting)

ComaVN (325750) | more than 4 years ago | (#32538750)

What is wrong with using regular parameterized queries instead of SPs?

Re:Poor programing practices, NOT IIS or SQL at fa (1)

D Ninja (825055) | more than 4 years ago | (#32538970)

A Stackoverflow answer [stackoverflow.com] explains the advantages very nicely.

Re:Poor programing practices, NOT IIS or SQL at fa (2, Informative)

PolyDwarf (156355) | more than 4 years ago | (#32539294)

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:Poor programing practices, NOT IIS or SQL at fa (1)

StuartHankins (1020819) | more than 4 years ago | (#32539492)

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.

Re:Poor programing practices, NOT IIS or SQL at fa (1)

capnchicken (664317) | more than 4 years ago | (#32539770)

Way to open up a techno religious debate. You might as well have said what's wrong with using Linux over BSD or Vi over Emacs or vice versa.

Re:Poor programing practices, NOT IIS or SQL at fa (1)

slifox (605302) | more than 4 years ago | (#32539010)

Generating SQL statements in a script is fine...

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 (4, Insightful)

Galestar (1473827) | more than 4 years ago | (#32539170)

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:Poor programing practices, NOT IIS or SQL at fa (1, Informative)

Anonymous Coward | more than 4 years ago | (#32539282)

IBM seems to think that "validate input" is an appropriate term for this
http://www.ibm.com/developerworks/library/l-sp2.html [ibm.com]

Re:Poor programing practices, NOT IIS or SQL at fa (1)

Alien1024 (1742918) | more than 4 years ago | (#32539764)

Why? If my postcode is " ' ; DROP DATABASE master; " I should be perfectly able to enter it.

Re:Poor programing practices, NOT IIS or SQL at fa (1)

Kjella (173770) | more than 4 years ago | (#32540076)

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, clean strings on the other and a sanitizing layer in the middle. But in practice nobody notices if you don't, a string is a string is a string because someone forgot or took a shortcut, in many cases being completely oblivious to the problem. In an application with heavy user interaction, I'd almost be tempted to have a dirty string and clean string subclass. But I figure someone will just cast it to a clean string to make it work anyway.

Re:Poor programing practices, NOT IIS or SQL at fa (1)

barzok (26681) | more than 4 years ago | (#32539480)

Or at least Prepared Statements (if your DBA is a PITA and won't let you go heavy on the Stored Procedures).

I suspect.... (0, Troll)

8127972 (73495) | more than 4 years ago | (#32538640)

... That the volume of Apache and PHP downloads are about to go up.

Re:I suspect.... (1)

Darkness404 (1287218) | more than 4 years ago | (#32538680)

Not really because most of the people who use IIS use it either because they run an all MS shop/have support contracts or they don't know how to configure Apache/PHP.

Re:I suspect.... (1, Insightful)

bsDaemon (87307) | more than 4 years ago | (#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:I suspect.... (1)

Yvan256 (722131) | more than 4 years ago | (#32538976)

That's why I use a LAXP setup. /duck

Re:I suspect.... (1)

Khyber (864651) | more than 4 years ago | (#32540118)

This is why I use a card catalog and filing cabinet.

Re:I suspect.... (1, Troll)

Foofoobar (318279) | more than 4 years ago | (#32539120)

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 Apache systems. So yes, I'd say Apache is pretty darn immune from not only this kind of attack but from your sarcasm as well.

Re:I suspect.... (1)

bsDaemon (87307) | more than 4 years ago | (#32539320)

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 the articles state, the issues are with non-sanitized input in the web apps, and they just happen to be running on an IIS server. If 12 drunk drives die in car accidents over a weekend and they're all driving Mustangs, do we blame Ford for that? No.

Re:I suspect.... (2, Interesting)

Lou57 (78812) | more than 4 years ago | (#32539522)

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

"Also, the SQL contains multiple SQL statements. I use PHP and MySQL databases which by default will only execute one command. That makes it much harder to hack. So switching to PHP and MySQL might be a good security choice."

Re:I suspect.... (1)

recoiledsnake (879048) | more than 4 years ago | (#32540202)

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:I suspect.... (0)

Anonymous Coward | more than 4 years ago | (#32538974)

i can write shitty code in any language

Re:I suspect.... (1)

Lord Ender (156273) | more than 4 years ago | (#32539202)

From a security standpoint, PHP developers are the worst of the web app world. By far.

malicious code writers should DIAF (1)

Em Emalb (452530) | more than 4 years ago | (#32538698)

With their families watching.

I hate people. No, not you, but them. Over there. Next to the oranges.

more info on malware? (0)

Anonymous Coward | more than 4 years ago | (#32538778)

The threatpost article says "which then installs malware on the victims' machines" -- anyone have info as to what malware they're referring to? Is it known? Detected?

graceful (5, Funny)

MagicMerlin (576324) | more than 4 years ago | (#32538800)

It was nice of them to deallocate the cursor when done. Thanks!

utm query parameters? (1)

the_one_wesp (1785252) | more than 4 years ago | (#32538844)

Reading through the Sucuri article, the script piggy backed on a utm_content query parameter. Aren't these used in metrics tracking like Google Analytics? Has anyone mentioned a name of the 3rd party that let this one slip?

Re:utm query parameters? (0)

Anonymous Coward | more than 4 years ago | (#32538996)

This is a generic MS-SQL injection and is NOT targeted at any specific 3rd party app/module. I have sample attempts against parameters other then utm_* that are completely custom. In the past the speculation has been that they just harvest URLs from google looking for .asp/.aspx and parameters. This is a good indicator of a MS-SQL backend. Once you have this list you just spray n' pray.

http://nsmjunkie.blogspot.com/2010/06/anatomy-of-latest-mass-iisasp-infection.html

Whoa! (-1, Troll)

Jaysyn (203771) | more than 4 years ago | (#32538848)

Companies actually use IIS?!?

It's Sloppy Development by a Sloppy Developer (1)

BSDetector (1056962) | more than 4 years ago | (#32538892)

If it is a SQL Injection attack - then it's sloppy development by a sloppy developer. Platform/DB... independent!

talk about forgetting/pretending. (0)

Anonymous Coward | more than 4 years ago | (#32538914)

http://dealbook.blogs.nytimes.com/2010/06/11/morgan-stanley-jpmorgan-to-take-lead-on-a-g-m-i-p-o/?hpw

george orwell taught these guys well. everything will be doublegood soon?

We Got Hit By This (5, Informative)

Anonymous Coward | more than 4 years ago | (#32538930)

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:We Got Hit By This (1)

lgw (121541) | more than 4 years ago | (#32539012)

Somone please mod parent AC up - first useful information in this discussion!

Re:We Got Hit By This (0, Offtopic)

Anonymous Coward | more than 4 years ago | (#32539296)

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. If you want information on the issue RTFA and comment there!

Naturally your post has been modded up more than the top one just for amusement.

Don't you mean... (1)

the_one_wesp (1785252) | more than 4 years ago | (#32539576)

Slashdot is about:

1) dropping memes in at every available opportunity.
2) making puns based on something unrelated
3) ???
4) PROFIT!!

Re:We Got Hit By This (1)

Arthur Grumbine (1086397) | more than 4 years ago | (#32539758)

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:We Got Hit By This (4, Informative)

MisterZimbu (302338) | more than 4 years ago | (#32539476)

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.

Copy and pasted story? (0)

Anonymous Coward | more than 4 years ago | (#32538940)

I think I recall reading the *exact* same story in 1996 and 1998 or so. And... about once a year every other year too.

Back to Basics (3, Informative)

achbed (97139) | more than 4 years ago | (#32539046)

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.

Today's crapptacular news media (0)

Anonymous Coward | more than 4 years ago | (#32539062)

This is SQL injection, and they play it out as though it is a fault of IIS. If today's news media knew anything about security they would know its just poorly written websites that are at fault.

They make out as though this is a vulnerability that will affect everyone running IIS - without some level of competence, the average reader would deduce that "CRAPPY MS SOFTWARE FUHFUHFUH!"

Not a day goes by where a popular online news outlet gets the whole story ass-backwards. This is the second one today (the first was a "Zero-day" five-day vulnerability on computerworld).

Seriously, when are we going to get people that actually know what they are talking about writing the news??? Or at the very least, slashdot mods, stop linking to the retards

</rant>

It's Happened Before... (1)

neorush (1103917) | more than 4 years ago | (#32539266)

I was in my first week or so on the job with a firm about 2 years ago when this same thing happened. The IIS servers they ran were getting hit with a few thousand attempts / sec. There were a bunch of old coldfusion sites with SELECT * FROM table WHERE id=#url.id# floating around and many sites were compromised. Getting rid of the IIS header and the .cfm extension got rid of the bots attempts as we added filters to coldfusion. It was one of the worst weeks ever, I don't work there any more. There was even a slashdot post about the massive attack then to.

Anonymous Coward (0)

Anonymous Coward | more than 4 years ago | (#32539446)

WSJ runs Apache, this article is probably bogus.

Frost pIDst (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32540018)

wouOld you Like to

Defiantone64 (0, Troll)

DefiantOne64 (1829914) | more than 4 years ago | (#32540114)

why is anybody running IIS anyway... Is this not another outdated technology from mickey$oft.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?