Slashdot Log In
500 Thousand MS Web Servers Hacked
Posted by
kdawson
on Fri Apr 25, 2008 11:48 AM
from the scream-and-shout dept.
from the scream-and-shout dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Bias? (Score:5, Informative)
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? (Score:5, Insightful)
Its such a rediculous flamebait, I don't know what to say.
Parent
Re:Bias? (Score:5, Informative)
Parent
Re:Bias? (Score:5, Interesting)
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.
Parent
Re:Bias? (Score:5, Informative)
Parent
Re:Bias? (Score:5, Insightful)
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.
Parent
Re:Bias? (Score:5, Funny)
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.
Parent
Re:Bias? (Score:5, Interesting)
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).
Parent
Re:Bias? (Score:5, Informative)
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?
Parent
Re:Not really (Score:5, Interesting)
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.
Parent
This site makes me sick (Score:5, Insightful)
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 (Score:5, Insightful)
Parent
what does the trojan do? (Score:5, Insightful)
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
Re:what does the trojan do? (Score:5, Insightful)
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.
Parent
500,000? Where'd that number come from? (Score:5, Informative)
Re:epic lol (Score:5, Informative)
Parent
Re:epic lol (Score:5, Insightful)
Sure, he should know about SQL injection stuff - but even if he did, would he be able to fix it?
Parent
Re:ob... (Score:5, Interesting)
If I run Firefox on Linux without NoScript, is there a danger?
Parent
Re:ob... (Score:5, Insightful)
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?
Parent
Re:ob... (Score:5, Insightful)
It is fundamental. It's called secure input handling, or sanitizing input. Just because it's a rule doesn't mean it is followed.
Parent
Re:ob... (Score:5, Funny)
Parent
Re:ob... (Score:5, Informative)
http://xkcd.com/327/ [xkcd.com]
Parent
Re:ob... (Score:5, Funny)
Parent
Re:The Trojan is hosted in China (Score:5, Funny)
And I'm sure you meant Turkey.(http://en.wikipedia.org/wiki/Troy [wikipedia.org]).
Parent
Re:So this isn't an IIS attack at all. (Score:5, Informative)
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.
Parent