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

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.

The Trojan is hosted in China

[Malevolent Tester]

Anyone surprised?

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.

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

[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 string escaping is inexistant in environments where prepared statements are first class citizens of the language/framework, because they're inferior methods of handling it. (and again: even in PHP its not what you're supposed to do).

Re:epic lol

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

[AlecLyons]

SQL Injection? Yes.

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:So this isn't an IIS attack at all.

[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 you have placeholder ?s in your string and a list of variables at the end.

Mind you, I'm not defending this; it's still a D,U,M thing to do, but also it is a lazier route, it doesn't really "take more time to develop, harder to read and maintain" like you said.

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

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, even if disabled in the config (thanks PHP!) or a host of other things. And if you look at milw0rm.com and other such sites, you will see a majority of SQL injection vulnerabilities come out for open source products with a mySQL back-end these days. So somehow pointing out that this is an IIS problem, and that Firefox will protect you from evil IIS sites, just shows ignorance and bias. I love UNIX, I preffer it over Windows, but I am also grounded in reality. Yes, you will have a lot of compromised IIS servers, because you have a lot of clueless admins who write ASP scripts on their Windows boxes without paying any attention to security. But in those hands, LAMP is just as dangerous, if not even more so.

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

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.

Re:ob...

[mhall119]

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

Re:ob...

[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 the number 3 result for a google search for "php mysql". It gives the following code, with a short mumble in the precursor about addslashes:

$username = $_POST['username'];
$password = $_POST['password'];
$query = "INSERT INTO user (host, user, password, select_priv, insert_priv, update_ priv) VALUES ('localhost', '$username', PASSWORD('$password'), 'Y', 'Y', 'Y')";
mysql_query($query);

If the tutorial writers can't even be bothered to write secure code, how can people who learn from tutorials be expected to? I think the tutorial sites have an obligation to correct or remove any tutorials that have basic coding mistakes like these in them.

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.