500 Thousand MS Web Servers Hacked

andrewd18 writes "According to F-Secure, over 500,000 webservers across the world, including some from the United Nations and UK government, have been victims of a SQL injection. The attack uses an SQL injection to reroute clients to a malicious javascript at nmidahena.com, aspder.com or nihaorr1.com, which use another set of exploits to install a Trojan on the client's computer. As per usual, Firefox users with NoScript should be safe from the client exploit, but server admins should be alert for the server-side injection. Brian Krebs has a decent writeup on his Washington Post Security Blog, Dynamoo has a list of some of the high-profile sites that have been hacked, and for fun you can watch some of the IIS admins run around in circles at one of the many IIS forums on the 'net."

ob...

[Anonymous Coward]

Does it run on linux.

Re:ob...

[ArcherB]

Does it run on linux.

That is actually a good question and the first thing I thought of. While I'm not worried about my little webserver being hacked as it runs on Linux without MySQL, I am worried about my browser.

If I run Firefox on Linux without NoScript, is there a danger?

Re:ob...

[RobBebop]

In other words, you can't rely on the site you are visiting to be safe.. so the onus is on the end user to make sure their PC is fully patched and as secure as possible.

The above quote is from the article link which lists "important sites that have been compromised". I think the important thing is that any site running MSSQL could potentially be compromised in a way that would affect a reader of that site who (a) does not have an updated web browser, or (b) doesn't have script disabled.

In 2008... why is it really so easy to put a damned single or double quote into a SQL form and then make it possible to execute your malicious code on that server? Shouldn't disabling this be a fundamental security rule for databases?

Re:ob...

[keithjr]

In 2008... why is it really so easy to put a damned single or double quote into a SQL form and then make it possible to execute your malicious code on that server? Shouldn't disabling this be a fundamental security rule for databases?

It is fundamental. It's called secure input handling, or sanitizing input. Just because it's a rule doesn't mean it is followed.

Re:ob...

[steelclash84]

Did you really name your kid "Robert'); DROP TABLE Students; --"?

Re:ob...

[mhall119]

Obligatory link:
http://xkcd.com/327/ [xkcd.com]

Re:ob...

[hclewk]

Oh, yes. Little Bobby Tables, we call him.

Re:

[jsebrech]

It is fundamental. It's called secure input handling, or sanitizing input. Just because it's a rule doesn't mean it is followed

Just because there are rules, doesn't mean people know about them. I frequent a flash forum where people often ask how to integrate flash with mysql via a php script. The vast majority of the code posted there is open to sql injection. This is not a matter of laziness, it is ignorance.

And this is perfectly understandable if you look at the tutorial sites out there. Take for example

Re:

[jsebrech]

Well, the reality is that people who copy/paste together scripts don't take the time to learn the complete tutorial, they just copy out the parts they need, and often don't even look at the rest. In practice, by shunting security off to a separate lesson, it becomes a lesson most of the hobby coders never learn.

Besides, tutorials have no excuse anymore. In the PHP4 days it required extra code to be secure, but with PDO in PHP5, and bind variables, the easiest way to code things also happens to be the secure

Re:

[Firehed]

Interestingly, you can only do so much damage with PHP's handling of SQL statements. Namely, you can only run one statement per mysql_query() so while you could bypass a login with a ' OR 1=1 ' deal, Bobby Tables couldn't completely kill your DB. Doesn't stop code injection in the slightest which would be the easiest to prevent, but it's a start. Unfortunately it would be rather tricky to write software that knows when to escape characters and when I'm using variables in the statement safely which would

Re:

[AlecLyons]

SQL Injection? Yes.

Re:

[plague3106]

Except that Sql injections can happen on any web server with a poorly coded application. So you should be marked as troll, but your comments on IIS are just here to stir up MS fanboy. To be fair, it's been a long time since there was any huge number of exploits on IIS.

Re:ob...

[sm62704]

True, but the summary could have mentioned it. As it is, it's a ripe subject for humor. Only some folks here defend their choice of operating systems like others defend their wifes and children. Anyone who would get angry because someone jokes about someone else's product has some serious issues.

"It Isn't Secure" is a tired old joke. But so is Microsoft!

Re:

[MacWiz]

the answer is it runs on Microsoft IIS server and Microsoft SQL Server.

Microsoft's technical team was taken by surprise, giving them fresh hope that they, too, can develop software which runs on Microsoft IIS server and Microsoft SQL Server.

Re:More data needed

[CastrTroy]

You can have SQL injection problems just as easy in stored procedures as you can in plain old code. Look at this example (pardon the probably incorrect syntax):

Create Procedure GetUserTelePhone(@UserName varchar(50))
Begin
      Declare @sql varchar(300)

      Set @sql = 'SELECT TelePhone From Users where UserName=''' + @UserName + ''''

      return exec(@sql)

END

See, there you go, completely open to sql injection, and it's a stored procedure. The problem isn't that people aren't using stored procedures, it's that people are creating queries which result from the concatenation of strings and variables, which invariably leaves them open to attack. A much better way to do things, is to use prepared queries, either in you stored procedures, or just using prepared queries directly in the code.

Bias?

[jmpeax]

SQL injection is a result of poor data validation on the part of the web application - not, as the blurb implies, an indicator of an insecure web server. LAMP installations are also susceptible to SQL injection [mysql.com] (PDF). From TFA:

Unless [...] data is sanitized before it gets saved you can't control what the website will show to the users. This is what SQL injection is all about, exploiting weaknesses in these controls.

As for the fact that Firefox + NoScript prevents the problems, that really isn't a surprise seeing as these specific exploits rely on executing a JScript. Any browser with scripting disabled would be immune.

The tone of the blurb is not only biased but also counter-productive to promoting open source (as this appears to be its intention): by trying to criticise closed technologies not by highlighting their actual deficiencies but instead by spreading FUD, the whole community is done a disservice.

Re:Bias?

[ischorr]

Also, is it 500,000 web *sites* identified so far, or 510,000 web *pages*?

Re:Bias?

[Mia'cova]

The blurb completely misquotes the article. The article clearly states pages as reported by google. Plus, Google is hardly a live metric for the state of the internet. It really gives us a very poor estimate of how much impact this is having.

Also, which browsers are affected? It sounds like most of the exploits being used against the browsers have already been patched. Is there a new one there?

Re:

[Binestar]

I believe it's 520,000 web *links*.

Re:Bias?

[Shados]

I agree, and that was my first reaction: "Wtf does IIS have to do with SQL injection". If nothing else, a LAMP stack would be more susceptible, not because of the servers, but because PHP didn't have mainstream prepared statements as part of a default standard install in its earlier versions, and now that it DOES have it, a lot of script kiddies or peanut gallery programmers aren't using them, as opposed to Java/.NET/Whatever which, while still having some issues with the same group of newbie developers, are prepared-statement centric in their development paradigms and documentation, thus reducing the amount of possible SQL injection significantly, unless the apps are made in legacy environments too.

Its such a rediculous flamebait, I don't know what to say.

Re:

[MrMr]

I don't know what to say.
That's pretty obvious.

How is the alledged fact that a LAMP stack would have been more vulnerable to this IIS directed attack relevant to this story? No claims of superiority for any server software in the blurb. Are you just trolling?

Re:Bias?

[Shados]

No, i'm not trolling. My point is that the story itself is trolling. This isn't an IIS directed attack, it is a "bad programming" directed attack. The -same- attack, exactly, would work -regardless- of the server. You don't even need to CHECK which server is running on the machine for this attack to work, since the server is IRRELEVENT, and I was trying to demonstrate that. Nothing more.

It is NOT an IIS directed attack. At best, its a loose corelation statistic, and one thats pretty useless without comparing it to other references, such as other web servers.

Re:Bias?

[Stellian]

In fact, the attack enumerates all ASP variables and tries to force a SQL payload in them, that in turn if executed adds the link to the malicious script to every textfield in the database. A very simple vulnerability scanner, if you like, targeting only ASP applications - thus the ISS spin.
Since we don't see the LAMP version spreading I think we can safely conclude that no web application written in PHP with a MySQL back-end is currently vulnerable to any type of SQL injection.

Re:

[willyhill]

This is not an IIS attack, it is an application attack. No more IIS specific than this [slashdot.org] one is Apache's fault, correct?

I love the difference in tone between the two submissions, and especially the "haha this is all a big joke, relax" tone of the comments on the other one.

It's unfortunate that Slashdot is becoming one big FUD-spewing machine.

Re:Bias?

[Col. Klink (retired)]

> "Wtf does IIS have to do with SQL injection". RTFA:

the attackers looked for ASP or ASPX pages containing any type of querystring

This specific attack, of which google has found over half a million affected pages, is targeted at IIS.

Re:Bias?

[Shados]

Doesn't change that IIS doesn't have anything to do with it. If you take aside that both ASP and ASP.NET (more ASP though) aren't IIS specific by a long shot, the attack is targeting specific technologies, then targetting specific software development flaws within the boundaries of those technologies. If I'm running PERL/PHP on my server, it won't see it. If I'm running an ASP page on Apache, it will, and even if my server hasn't been patched for the last 5 years, I'm no more or less vulnerable to that attack.

If the attackers looked for servers that were advertising themselves as IIS, and/or attacked IIS vulnerabilities or bad administration practices, you'd have a point. But the fact that the servers were running IIS was little beyond a strong corelation.

Re:Bias?

[Facetious]

The admins on the ground seem to disagree [iis.net] with you. From that page, "Our initial investigations are pointing at an attack through IIS using ASP in an overload."

Re:

[shutdown -p now]

The admins on the ground are so clueless it hurts to even read the posts. They actually think they can close the hole by searching for strings such as "EXEC", "SELECT" or "NVARCHAR" in all query parameters and rejecting the request if anything similar is found. The words "escaping" and "parametrized queries" are not found once in the whole thread.

If you actually bother to read the thread, anyway, it's clear that the problem is indeed with applications that use queries like "SELECT * FROM Users WHERE Name

Looking at the IIS forum...

[jd]

...the first person to google for attacked pages only turned up ASP pages as cracked. Later on, they say that the javascript attempts to use an ActiveX control. If I am exceedingly generous, I'll allow for the possibility that the story was written by someone who saw just these two comments and assumed that since both of these are generally run on Microsft OS', that this was an IIS problem. (Actually, more than a few people using Microsoft OS' run other web servers. There's quite a selection to choose from. Also, both ASP and ActiveX are usable under Linux, well, ish.)

However, it is now abundantly clear that the attack is NOT ASP-specific, and just because one of the vectors it tries is based on ActiveX does NOT mean it doesn't try other methods. It only means that the people who spotted it early spotted it trying that method. Although it's unlikely to have an attack library for multiple OS', it would be surprising if it didn't have some alternative action for when ActiveX isn't available.

I'm concerned about the number of Government sites that have been shown to be vulnerable, especially (as has been commented by others on Slashdot) a Canadian site dealing with national security. This attack is unlikely to cause any particular lasting harm, but stop and think. These are the sorts of sites that actually need to be secure. Even if not directly connected to internal secure networks (and I'd be willing to bet that far more are than are supposed to be), they are high-profile and for that reason alone are likely to be much more at-risk than other sites.

Most smaller websites are just point-of-presence and information sites. It's an irritant if they vanish for a while, but it's unlikely to hurt anything. Nobody is going to die if a blog site isn't available for an hour or so, unless they're a serious addict. No small vendor is going to lose business if their PDF datasheets aren't reachable for a little while. Adult sites risk making a one or two percent loss of webcam income out of their steady stream of millions. I seriously doubt anyone from the United Methodist church will suddenly become Mormon or Catholic because their primary website was hit.

Not really

[Scareduck]

PHP has pretty much fixed SQL injection hacks, at least for MySQL, something TFA you quote mentions on page 74. Given that this is the majority combination on web-facing machines, shouldn't that blunt the "LAMP installations are also susceptible to SQL injection" if only by quantity? I mean, I agree with your counter-FUD reasoning, but it seems to me that this blunts your whole sentence, MySQL+PHP being two pillars (and the last half) of LAMP.

Re:

[SatanicPuppy]

That's still pretty new; I've been using php for a while, and it's only been recently that I stopped feeling the need to use my home-rolled anti-injection methods over the new code methods.

There are still plenty of examples of bad php out there; I'd hardly call it fixed when the problem has never really been a problem of the language, but instead a problem of lazy programmers.

Re:

[Sancho]

Pear with prepared statements has been around for a while. What method are you guys talking about that prevents SQL injection without that?

Re:

[jmpeax]

The features they discuss were only introduced in the most recent version of PHP, and many, many servers are still running older releases.

Furthermore, note that these safeguards are only a basic defence and programmer awareness is still required to ensure SQL injection can't happen:

But, magic quotes is a generic solution that doesn't include all of the characters that require escaping, and the feature isn't always enabled (for reasons outlined in the first chapter). Ultimately, it's up to you to implement safeguards to protect against SQL injection.

Re:Not really

[weicco]

As so has ASP.NET. I write (almost) all my database queries parametrized like this

SqlConnection conn = ...
SqlCommand cmd = ...
cmd.CommandText = "SELECT * FROM Foo WHERE Bar = @bar";
cmd.Parameters.AddWithValue("bar", barValue);

This way I'm pretty safe from SQL injection attacks. Add all the HTML encoding/decoding stuff to that and you can rest your nights peacefully.

Then enter the PHB. Now a days we stuff all the parameters straight to the DB procedure where they aren't sanitized at all. We build SQL query inside the stored proc by concatenating strings and call sp_execute to execute them. So all my earlier input validation and parameterized queries went down the drain. PHB's reasoning? - We trust our users.

Re:

[geekoid]

Build an exploit for it and use it in front of your PHBs boss.

If you are under SarBox, remind them that this is an security audit issue.

This all can be done in a professional manner and not a 'get my stupid boss' manner.

IF you deal with any personal information, in your report you will make before the meeting, show the PR and legal nightmare that happens when data gets out.

Your boss should not be telling you how to program.

Re:

[jellomizer]

'); drop table users; --Yea this is a microsoft problem. That wouldn't be the cause of poor website development.

Re:

[Splab]

That will only work on languages supporting multiple statements. PHP/MySQL which is the most commonly used will just throw an error at you.

Re:

[Splab]

Well lamp isn't as vulnerable as MS SQL is - not because of better security mind you, but due to lack of support for multi queries in PHP.

When injecting in PHP/MySQL environment you are limited limited to what you can do inside the query provided by the server (or of course if some retard has put the whole query as an get/put you got free pickings.)

Re:Bias?

[Anonymous Coward]

Agreed. I *hate* Microsoft and am as rabid a Free Software advocate as you will find, but code injection attacks are neither the fault of nor prevented by the OS or web server.

If users of open source software want to protect our largely well-deserved right to be smug, we have to be no less vigilant against these attacks than the proprietary chumps. This particular attack may only have hit MS servers, but this category of attack in general is frighteningly equal-opportunity.

We can't take our superiority for granted; we have to earn it every day.

Re:Bias?

[toby360]

I have to agree that this is highly Biased.
This has nothing to do with IIS, SQL or ASP, coding against SQL injection is the responsibility of web designer. Also it should be noted that ASP was originally released way back when with NT4.0 in 1996(v1) , 2.0 in 1997 and 3.0 in 2000 http://en.wikipedia.org/wiki/Active_Server_Pages [wikipedia.org].

With the newer ASP.NET MS was kind enough to provide several layers of protection against attacks such as SQL injection with both server side and client side validation applied to controls when built in the designer (by default).

FUD is as FUD does

[Foofoobar]

FUD proliferation. One must spread FUD before Microsoft spreads FUD. Just the other day, Bill Gates himself stated that you cannot make money with GPL'd products (while Redhat and SUSE and IBM and MYSQL and others continually make millions). So while we do ourselves a disservice, the only way to fight FUD is with FUD.

Re:

[RiotingPacifist]

This is a terrible title, IANAWebDeveloper, hell i dont even know how to code, but as soon as i read the summary it was clear that this had nothing to do with MS.

And ofcourse your safe using FF + NoScript, but then again your safe from anything, if people keep posting about how safe FF + noscript are, i might start talking about how secure lynx is, it would be much more useful to talk about browsers without NoScript.
Do all articles about adverts contain a disclaimer saying that people using adblock are unaf

Re:

[samantha]

I though tha javascript was rather limited in what it could do on a client. But I guess all it needs for some types of SQL injection is the ability to rewrite URLs and html data pages which it pretty much has to have. Or is it more specific than that?

NoScript is a pain.

Re:

[thePowerOfGrayskull]

Umm, right then. I sure am glad. Rofful.

Re:

[ray-auch]

I'm sure we'll soon have an article about all the Linux admins running around in circles at one of the many forums.

Not right now - I think they're taking a month or so off after the last few months running around in circles, see eg. http://computerworld.co.nz/news.nsf/scrt/E902A2095FEC1A23CC2573D60072888C [computerworld.co.nz]

Re:

[Macthorpe]

From an ex-user of Panda Antivirus, take what they say with a pinch of salt.

The Trojan is hosted in China

[Malevolent Tester]

Anyone surprised?

Re:

[Concerned Onlooker]

A little. I would have thought it would have been Greece.

Re:

[SatanicPuppy]

I'm sure you mean Persia.

Re:

[abigor]

And I'm sure you meant Turkey.

Re:The Trojan is hosted in China

[Kong the Medium]

I'm sure you mean Persia.

And I'm sure you meant Turkey.(http://en.wikipedia.org/wiki/Troy [wikipedia.org]).

Re:

[Concerned Onlooker]

Yes, but that wouldn't have made for such a good joke. Apparently this one didn't either.

LOL

[ThePhilips]

Lolicious.

I once spend an hour trying to explain IIS/MS SQL Server admin what PHP/MySQL addslashes()/mysql_escape_string() do - all to no avail. He was absolutely sure it is sufficient to like in VB surround any string with single quotes and it all will be fine.

Now seeing that it's real fun for guys, I can only laugh.

Re:

[sakdoctor]

To which he replied: "Don't use mysql_escape_string(), it's a deprecated function. Use mysql_real_escape_string() instead."

Re:

[Shados]

I'd personally laugh at you. Escaping sql strings, what the hell? the 1980/90s called and they want their obsolete methodologies back.

In any semi-advanced programming language or framework (including PHP, even more so since PHP5 as it doesn't require any extension or whatever), you just use prepared statements. Maybe that MS SQL Server admin was a bozo, but in VB, you'll almost always be using prepared statements (even in VB5-6, pre-.NET), or at worse, stored procedures, which act as prepared statements.

SQL

So this isn't an IIS attack at all.

[Chas]

This is a SQL injection attack. IIS just happens to be the front-end of a poorly written web app.

Thus, if I'm running a web app that doesn't rely on IIS for anything more than presentation, and am not using SQL in my authentication (say something like Terminal Services or GraphOn), I should be fine.

Correct?

Re:

[Shados]

Yup. Heck, even if you are using SQL on every last thing... if you're using prepared statements (or stored procedures), which MUST be done for performance reasons and code maintainability ANYWAY (sql strings concat is such a rediculous anti-pattern...), you're immune.

SQL Injection is by far the stupidest security vulnerability there is... Worse than buffer overflows, cross site scripting, etc... Because you have to go -out of your way- to make them possible. You have to make your code slower, take more time

Re:

[kisrael]

I agree there's no excuse for it, but in your second paragraph I don't agree with your logic 'til the final parenthetical remark.

In development, it often IS simpler to start with a single hardcoded SQL query (probably cut and paste from your DB tool, and then if your language supports + or . for string concat, it's easier to just do a "+variablename+" where the hardcoded value was -- plus, it keeps the flow of the SQL 'sentence' in correct order, rather than that kind of weird "sprintf()"ness you get when y

Re:

[Shados]

I don't know, personally. You need all those concat symbols, the parameters aren't obvious...

"select * from blah where stuff = " + var1 + " and lol = '" + var2 + "';";

It gets messy when you have strings, dates in special formats, xml literals, multiline queries... look at this around var2, the single quote followed by a double quote... messy messy. And depending on the language, you have to escape the quotes, etc. Crazy. How can you guys even read that? Nevermind debug it when it gets complicated.

Then when

Re:So this isn't an IIS attack at all.

[SatanicPuppy]

There are several smart things that need to be done to protect yourself.

Restrict the account that is used to access the database to the absolute minimum permissions it needs to run; using one set of credentials for insert/update/delete and another for selects is enough to foil a lot of exploits (I actually never allow deletes, just out of paranoia...I just update the record with an "inactive" flag, and purge them later with a local account).

For gods sake, don't allow a single account to access multiple databases, and even within the database make sure it only has access to the tables you're going to be using. I've seen more than a few MySQL injections that just dump the user table to the screen because some joker didn't think he needed to restrict access for "SELECT" statements.

Escape ALL data that comes from userland. This is your first line of defense, and it's where most people screw up. If you let an escape character past without it being escaped, your only protection is the privileges associated with the user account.

Abstract your data methods. If you just throw out random SQL queries all through your code, you're going to make a mistake somewhere. Make a single method that does your selects. Make a single method that does your inserts, etc. If it's only in ONE PLACE you can go over the code in extreme detail. If the queries are scattered through the code, you can't.

This is all just best practice stuff. The most important thing is to PAY ATTENTION and remember that one unsecured account can screw your entire server.

This site makes me sick

[RzUpAnmsCwrds]

This site makes me sick sometimes. If this were a problem with PHP (which, mind you, it IS), we wouldn't be calling it a "vulnerability".

ASP.net has lots of built-in features to prevent SQL injection attacks (like bind parameters) and the ASP.net DB documentation specifically warns about this type of attack.

Anyone still getting hit with this in 2008 needs to be whacked on the head.

Re:This site makes me sick

[MrMunkey]

Anyone still getting hit with this in 2008 needs to be whacked on the head.

This is true of any language, not just ASP. You can easily prevent SQL injection with Perl, Python, PHP, etc.

Re:

[RzUpAnmsCwrds]

Fair enough - my comment wasn't intended as a criticism of PHP or any other web framework. I just wanted to point out that SQL injection attacks are a stupid novice mistake, one that's far too common in "professionally-done" code.

Note, though, that PHP has a number of issues that make SQL injection more likely:

• "mysql_escape_string" vs "mysql_real_escape_string"
• Documentation that encourages building SQL queries by concatenation
• "Magic quotes" which may or may not actually work, and shouldn't be used anyway
• No

Re:

[stubear]

Why would astronauts be writing web applications? Don't they have more important experiments to be conducting to waste time playing on the internet?

IIS bashing

[gzipped_tar]

I've read a similar article on theregister.com: Web infection attacks more than 100,000 pages [theregister.co.uk]. There are also some interesting discussions over there.

This is a SQL injection, which is not specific to IIS. Any server-side program that fails to validate the input is subjected to this kind of exploit.

Re:

[bob.appleyard]

I think the point is that this particular attack only targeted IIS, and appears to be a bit of a biggie. So it's news. There is still a slight bias of course, and there will be plenty of bashing here and elsewhere, but it's noteworthy nonetheless.

what does the trojan do?

[circletimessquare]

ok, story 1 is a sql injection

there seems to be a story 2 here: what the trojan will do in a few weeks to all of the IE users who visit these half a million sites

and, reading some of the links and finding that these trojan hosting domains are registered in china, there also seems to be a story 3: chinese hackers are pissed off

i got hacked shortly after the hainan island incident [wikipedia.org] in 2001. that is when the us spy satellite was bumped a chinese fighter, and was forced to land on hainan island (china). there was much chinese nationalist anger then, and it was taken out by hacking western sites with "f**k usa!" and the chinese flag replacing the main page

obviously, this hack is contemporaneous with the whole tibet riots/ olympic torch protests. that's the meat of this story, and that avenue seems unexplored as of yet. similar to the russian ddos of estonia due to the deprecation of a war statue in 2007 [slashdot.org]: the lesson is that, much like al qaeda and terrorism, cyber warfare is not so much a tool of any state government, but chest-thumping activity for ultranationalists and religious bigots and other organizations of cultural or national or religious chauvinism. the theme of the 21st century seems to be shaping up as partisan tribalism and extreme ideology reaching beyond the notions of sovereignty, statehood to go to war with each other in a novel ways

Impressive fighter plane they have there

[hellfire]

I got hacked shortly after the hainan island incident in 2001. that is when the us spy satellite was bumped a chinese fighter, and was forced to land on hainan island (china).

Is that the fighter plane with warp drive and photon torpedos?

Sorry to pick on ya dude... it was a US spy plane, not a spy satellite :)

doh!

[circletimessquare]

actually, you should be impressed with us spy satellite technology: it can swoop down into the atmosphere for closer looks ;-)

Re:

[bjourne]

obviously, this hack is contemporaneous with the whole tibet riots/ olympic torch protests. that's the meat of this story, and that avenue seems unexplored as of yet. similar to the russian ddos of estonia due to the deprecation of a war statue in 2007 [slashdot.org]:

Please don't spread this unsubstantiated rumour. The only one who ever was found guilty of the dos attacks was an Estonian Russian script kiddie. The other allegations about Russia launching a cyber attack on Estonia were just that, allegations with no evidence what so ever.

Re:what does the trojan do?

[Deanalator]

Please do not perpetuate hysteria.

The "Russian DDoS attacks of Estonia" were done by a few Estonian kids mad about some statues being moved around.

http://www.theregister.co.uk/2008/01/24/estonian_ddos_fine/ [theregister.co.uk]

There was no cyberwar, the Russian government had nothing to do with it, and every media source that mentioned it really needs to update their articles because the misinformation is causing far more harm than good.

500,000? Where'd that number come from?

[Robotron2084]

Before you post such a headline, perhaps it would be a good idea to check your facts. I RTFA'ed and checked those links and there is no mention of how many servers were attacked. There were 510,000 pages mentioned, but pages do not equal servers. This a sensationalistic headline based on a sensationalistic interpretation of a Google web search.

Re:

[Unnngh!]

Yep...too bad there's not a firehose or some other way to vote to pull existing posts. This is wrong through and through and is just confusing and misleading.

Any meaning to the site names?

[Guppy]

Hmmm.... nihaorr1.com? "Ni Hao" is a greating, like "Hello" in Chinese. Anyone figure out any meaning behind the other names?

(Other meanings are possible as well, due to the large number of homophones in the language, but this is by far the most obvious meaning.)

Re:

[Intron]

Don't know about meaning, but its easy enough to track where its coming from:

host aspder.com
aspder.com has address 60.172.219.4
jwhois 60.172.219.4

person: Jinneng Wang
address: 17/F, Postal Building No.120 Changjiang
address: Middle Road, Hefei, Anhui, China
country: CN
phone: [phone]
fax-no: [phone]
e-mail: [e-mail]
nic-hdl: JW89-AP

SQL injection is not platform dependent

[twistah]

OK, so SQL Server prior to 2005 wasn't secured well by default, and xp_cmdshell() is like inviting a system-level compromise. But, as others have pointed out, ASP.NET/IIS isn't the only platform affected. In fact, this platform makes it easy to secure your scripts against most attacks, ans SQL Server 2k5 and IIS 6 and ASP.Net have added protections as well. On top of that, this platform has never been vulnerable to attacks due to superglobals, of file open functions which allow you to import remote files, e

It's even on the UN's website

[probityrules]

A Google search for "nihaorr1.com" brings up events.un.org as an affected site.

" As per usual?"

[operagost]

Could someone please tell me what "as per usual" means? Does it mean, "as usual," or "per Usual"? Who is this "Usual" guy?

Interesting to note Windows admin responses

[caseih]

The iis.net forum is full of very interesting posts by windows admins. One guy was hacked no less than 3 times! Each time he just restored his database and thought all was well, and wondered how those dang hackers kept getting in. He even changed his passwords!

This is definitely not how most unix admins would react. If a machine is compromised (via whatever source) then a simple data restore is never good enough, unix admins know. The original vector must be identified and stopped. It's quite the cont

True story...

[gaspyy]

Just a few months ago we had to build a small custom CMS for a client, that had to be PHP/MySQL. The specs were very specific so it had to be custom-built. Since it was a relatively small work and we were involved in some bigger projects, we hired a contractor. Good references, a few years of experience, knew javascript, so we handled the project to him.

To his credit, the site actually worked and seemed fine, until you had a peek at the PHP code, which was truly horrific. I could overlook the nonsensical us

Re:

[geekoid]

Then how am I supposed to get revenge after I leave?

New AVG 8 free edition, the linkchecker catches it

[Fallen Andy]

... so update from 7.5 if you're using the free version. 8.0 has been available here [grisoft.com] since yesterday.

Interestingly (and I've been looking at this attack all day) it seems to overwrite itself in the middle.

Andy

Re:epic lol

[James Kilton]

Wow. The responses on the forum http://forums.iis.net/t/1148917.aspx?PageIndex=1 [iis.net] are sad indeed. Windows Security patches DON'T protect against shittily built websites. My favorite:

I also have been hit by this attack on Saturday 4/12/08. It compromised our database and overwritten that script into all of your products. Luckily a database restore fixed the problem. Two days later the same thing happened, I have changed all the database and login passwords and did another db restore. Now today 4/18/08 we got hit again by the same thing but this time as the pages are loaded ActivX is activated and wants to run but of course I did not allow it. Anybody has successfully solved this situation?

It truely sickens me how many web developers STILL don't know about SQL Injection.

Re:epic lol

[caluml]

Why do you think he's a developer? He sounds more like a sysadmin to me.
Sure, he should know about SQL injection stuff - but even if he did, would he be able to fix it?

Re:

[SatanicPuppy]

That one made me laugh. Wasn't that Einstein's definition of insanity? Doing the same thing over and over and expecting different results?

Anyone can make a mistake; forget to taint a variable or something, but when you've obviously got an exploitable bug, you need to fix it, not just constantly rebuild the hacked database, probably losing data every time.

Re:

[Goaway]

Doing the same thing over and over and expecting different results?

Like flipping a coin?

Re:

[peragrin]

More like flipping a coin and expecting it to land on it's edge.

Re:

[Goaway]

That's not "doing the same thing over and over and expecting different results".

Re:

[SatanicPuppy]

Like expecting the coin to stay up in the air.

Re:

[jellomizer]

Well Computer Science Programs rairly if ever cover SQL. Or place it in the same class as web development. So you have kids just out of college with 0 SQL experience and get into business which is heavy SQL based. As well many of them are not secuirty minded. They think what does it take to get it to work and not as much as what does it take to break it. Then there is an issue of funding, pressure to get it done fast can leave such issues wide open.

Re:

[Shados]

How can you blame them however? Look at what THIS site (as in Slashdot) is doing. The headline implies that its an IIS hack. If you read the posts attached to this -very- article, a significant amount of people are replying acting like it IS a server issue, related to MS or some such.

When such misconceptions are so pervasive (even in -articles- on a geek web site like here!), obviously newbies are going to be confused all over the place.

Its a bit similar on how there's still so many SQL Server DBAs who thin

I weep for the future...

[Qzukk]

So much "superstition" in such a small thread... (is there a better word for doing something that you're sure will make things better but doesn't actually do anything at all?)

Blocking urls containing ;--? (what about ;%20-- or ;+-- or ;%20%20%20%20%20%20--?)
Redirecting the user to google if they use the word "cast" or "set"? (but not "CaSt"?)
Why not wave dead chickens or throw salt at the server, it'll do just as good.

Re:

[QuoteMstr]

I feel the same way. We ran rant all we want, but in the end, programming is going to get done by the cheapest, least-skilled people available. So we need to make the path of least resistance the correct path.

One quick and dirty idea I had for PHP was the following: Imagine a new string-like datatype, the query string. Syntactically, it works like a double-quoted string, but it's delimited by, let's say, [ and ]. Database query functions would only accept this new query-string type.

Concatenating a query str

Re:

[D Ninja]

Parent -1 Flamebait. (Actually...it's more Article -1 Flamebait.)

Anyway, as it has already been noted, this problem has nothing specifically to do with the IIS servers.

Two other notes:
FOSS is good, I agree. But FOSS, by default, is not always better than closed source solutions. Making a blanket statement like that is being just as close minded as the opposite camp.

Using M$ to represent Microsoft is soooooooo 1990s.

Re:

[Shados]

You don't even need to sanitize database input. Just use freagin prepared statements. There's no cleanup or validation necessary (for this particular vulnerability I mean, that is, sql injection).

Re:Seems to be effecting older versions of IIS...

[geminidomino]

http://xkcd.com/327/ [xkcd.com]

Re:

[sm62704]

Solution: Upgrade to Windows Vista!

link link link link [uncyclopedia.org]

Re:

[Shados]

First, as someone already stated, the vulnerabilty is in poor software development practice, and is pervasive in all environments, be in MS, Linux, Apache, IIS, PHP, ASP.NET, JAVA, whatever.

Second, IIS, since version 6, is amazingly secure, comparable with the likes of Apache. Its also the more straightforward platform to use as an ASP.NET server (obviously, unless you're into Mono), or to use along with a lot of fairly interesting technologies, such as TFS, Reporting Services, Sharepoints, etc.

On top of th

Re:

[sm62704]

"Its in the corner of North America, and mostly empty, except, of course, for all the fail." ~ Oscar Wilde on Where Canada is, and what its filled with. [uncyclopedia.org]

Canadian map of the world, eh? [wikia.com]

If I linked to the Uncyclopedia entry on the UK I'd be modded down. If I linked to the uncyclopedia entry on the US I'd be shot. If I linked to the uncyclopedia entry on Australia I'd be drunk.

The dangers of Apache and PHP

[willyhill]

Yeah sure [slashdot.org].

Add a healthy dose of misrepresentation, twisting of facts and oh-so-funny exaggeration (the IIS admins are running around in circles, LOLZORZ) and people like you can feel better about yourselves, at least for a few hours.

In the meantime, it's been 5+ years and no one has found an exploitable vulnerability in IIS.

I'm sure FOSS is better off this morning, thanks to kdawson, Slashdot and this type of misguided "advocacy". Might as well have twitter control the content of the front page.