Slashdot Mirror
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."
Does it run on linux.
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.
Amnesty International
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.
Dog is my co-pilot.
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.
http://xkcd.com/327/
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?
Get your own free personal location tracker
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.
And I'm sure you meant Turkey.(http://en.wikipedia.org/wiki/Troy).
... whenever a text is transmitted, variation occurs. This is because human beings are careless, fallible, and occasiona
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 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: 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
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
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.
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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.)
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.