Mass Hack Infects Tens of Thousands of Sites 259
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.
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: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2, Informative)
sqlmap [freshmeat.net]
I haven't tried it.
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: (Score:2)
Also automated attacks like this usually rely on a specific injection vector (usually a common url on domains where the injection can be carried out). And although no one has explained exactly what software was exploited to do the injection, it might well be windows-only software, but that's just speculation on why it might
Re: (Score:2, Informative)
Re: (Score:2, Interesting)
Cue the chorus; "Windows machines are only attacked because there are so many users..."
Sheesh, forgetting that 70% of servers run Linux...
Re: (Score:3, Insightful)
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: (Score:2)
Huh. This reminds me one project where I stumbled into a huge SQL injection vulnerability. They we're creating SQL commands inside stored procedure by concatenating strings, without any input validation of course, and happily executed those. SQL Server wasn't directly connected to web but there was only a tiny ASP.NET layer which loaded every possible POST variable to the procedure. And again, no validations of any kinds, of couse. I think ASP.NET has somekind of protection against SQL injections but I, for
Re: (Score:2)
Of course if you do you shouldn't be writing network-aware code.
Re: (Score:2)
AFAICT I shouldn't be affected because my server is Linux and none of my users have access from anything but localhost, unless they were using an injection attack through some crappy script I might have had installed.
Re:Okay Hands Up... (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
That was my first question. Since it is a SQL injection, it is mostly platform independent, but for a mass hack there must be some common common webapp that they exploited. I mean, i know SQL injection is fairly trivial, but you still have to intelligently poke around a little bit to find exactly where and how to do it. If they DID managed to not only automate the SQL injection attacks on a massive scale bu
Re: (Score:2)
It's essential to sanitise user input, but how often do web developers assume their own data source could be tainted? Most of the code I've seen has had a strong distrust of the user but had a open floodgate as far as the already stored data was concerned. I can see why a hack like this would be successful.
Re: (Score:3, Interesting)
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.
Re: (Score:3, Interesting)
But things such as Query-By-Example with wild-card (LIKE) potential, a very powerful technique, cannot easily be done using stored procedures. We would have to cripple the power of computers and have programmers wasting time writing trivial queries/reports for users and/or a combinatorial explosion of query forms (I'
Re: (Score:2)
I was just surprised it wasn't yet another exploit in phpbb.
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: (Score:2)
Re: (Score:2)
What do you mean? Are there Web sites that have SQL in their code? Of course.
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
You should still be careful. (Score:2)
Doesn't mean that the 'bot can't be tweaked. I think that someone is using this as proof of concept.
Re: (Score:2)
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.
Re: (Score:2)
Just so it's clear. :-)
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:3, Funny)
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 EXEC
Re:this kinda of crap anin't gonna stop until: (Score:4, Funny)
dumb or troll ? (Score:2, Insightful)
it has, however, something to do with specific precations not being taken: with selinux or apparmor for example this probably wouldn't have happended simply because they handle application privileges in a different (OMHO: better) way - through profiles.
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.
Re: (Score:2)
Re: (Score:2)
So, am I correct in thinking a simple AddSlashes() addition to the server side script will prevent this? Other posts imply (heavily) that it's not as simple as that, but when I read "SQL injection attack" I think "AddSlashes()".
didn't involve exacition of code .. (Score:2)
"Tens of thousands of websites belonging to Fortune 500 corporations, state government agencies and schools have been infected with malicious code that attempts to engage in click fraud and steal online game credentials [theregister.co.uk] from people who visit the destinations"
"The injections included javascript that redirected end users to the rogue site, which then attempted to exploit multiple vulnerabilities to install key-logging software that stole passw
Re: (Score:2, Insightful)
* SQL server: SIGNED
* Web server: SIGNED
Well, in this case you are still vulnerable to an SQL injection attack...
well then it ain't gonna stop (Score:2)
There's not nearly enough digital signing, even from reputable sources, to make "No signatrue? No execute" work. You can't get the things you want by applying this policy, and because people don't apply the policy, nobody bothers to go through the effort of signing. You would n
Re: (Score:2, Funny)
> signatrue? No execute" work. You can't get the things you want by applying this policy,
> and because people don't apply the policy, nobody bothers to go through the effort of
> signing.
I install only signed code and I get everything I want. I use Debian.
Re: (Score:2, Insightful)
If the whitelist specified that MsSQL was not allowed to load and execute code from links in data, perhaps that will do it.
Separation of code and data would fix the situation. I for one would be able to live with the reduced functionality.
Re: (Score:2)
Who is going to sign these apps that are "legit"? Microsoft? The goobermint? Another godsawful clusterfuck a la Verisign?
No thank you. Better that moronic admins get thier charges hacked up than we can't run our *NIX boxen because one of the above collection of scumbags won't sign source-built copies of Apache. (Sometimes the defaults aren't good enough)
Re: (Score:2)
If you build a small unix box where the only areas the user can write to are mounted noexec, and all executable areas are read only it becomes much harder to get malware on the system, even with a clueless user.
The only way you could execute something is by exploiting one of the client apps, and that would still have to further acquire root privileges in order to do any major damage or make itself survive a restart.
For upda
Re: (Score:2)
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].
Re: (Score:3, Informative)
Just FYI, doing my own quick Google search, it appears that the hosts used by the bulk of these attacks is actually c.uc8010.com and n.uc8010.com. Indeed, it looks like all one-letter hostnames are used for this domain. So modification of your HOSTS should be made accordingly to ensure all hosts from this domain are indeed re-routed.
Yaz.
Re: (Score:2)
Another approach is to just block it in your HOSTS file: 127.0.0.1 uc8010.com
Just FYI, doing my own quick Google search, it appears that the hosts used by the bulk of these attacks is actually c.uc8010.com and n.uc8010.com. Indeed, it looks like all one-letter hostnames are used for this domain. So modification of your HOSTS should be made accordingly to ensure all hosts from this domain are indeed re-routed. Yaz.
Yup. You're right. I took a look at the latest HOSTS file I downloaded and it does the right thing:
127.0.0.1 c.uc8010.com #[Javascript.Exploit]
127.0.0.1 n.uc8010.com
Re: (Score:2)
A filtered DNS server goes a long way and often is already blocking the content before you learn about it. A filtered DNS server isn't just for NSFW sites. It's a good idea. Common phishing sites, malware, and porn are filtered cross platform. I use it all the time now.
http://www.scrubit.com/ [scrubit.com]
It is community supported so when a new malware site pops up, anyone can report it so it can be quickly re-routed to the warning page instead of the bad page.
Re: (Score:2)
The biggest thing I noticed is the lack of any need to create an account. If you want to use ScrubIT, it's as simple as simply using their DNS server. In my case, I simply plugged in the DNS numbers in the router and that instantly protects the entire LAN including net appliances and all OS versions.
Just plug in the DNS numbers 67.138.54.100 and 207.225.209.66 into your router and the filter is done.
Re: (Score:2)
Yes, that HOSTS file totally rocks. But be sure to review the readme file. The massive size of the file makes it sometimes necessary to disable the "DNS Client" service on Windows 2000, XP, and newer.
Re: (Score:2)
protect yourself with privoxy ... (Score:2)
Privoxy [privoxy.org] is a much for efficient solution
was Re:Protect yourself with HOSTS
The aim of the hack (Score:2)
Re: (Score:2, Funny)
They had a 2 week holiday.
click fraud and steal online game credentials .. (Score:2)
That is one impressive hack. (Score:2)
The only thing I can figure is that either
You forgot c) (Score:2)
c) This was a pimple-faced little script-monkey who came across a stale old "toolkit" and was just clever enough to automate the deployment of the SQL injection attack.
It's really easy to patch the RDS activeX control, and not so easy to manually correct old custom-written web apps. Just a sad commentary on how shipshod web development standards has been in the past, and the lasting legacy it has created. Sanitising user input is (or
NoScript (Score:3, Interesting)
is Firefox safe .. (Score:2)
It's not clear from the article but the exploit seems to require Microsoft SQL Server, and on the client Internet Explorer and Windows to function. For instance would Firefox on Unbuntu be safe.
"tries to hijack their PCs using multiple exploits, security experts said this weekend"
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.
Re: (Score:2, Insightful)
But I also think slashdotters are amused at the continued running-amok of MS products. When the school bully gets beat up, you tend to not feel as sorry for him as you do for your friend.
Besides, cleaning up the spyware keeps the fly-by-night pc repair geeks in business
Re: (Score:2)
Intervention time! (Score:2)
Yeah. See, that makes us part of the problem. We are facilitating it by cleaning up after it.
Instead, it's time to do a mass computer intervention. The next time your parents/gf/bf/in-laws/friends call you to clean up their computer, tell them they are on their own. Suggest they purchase a Mac next time. Or, tell them you'll help them install Linux or your favorite BSD flavor, o
Re: (Score:2)
This is NOT a mass attack (Score:2, Informative)
Re: (Score:2)
I was able to see the script http://c.uc8010.com/0.js [uc8010.com] referenced in the Google search descriptions. I do a wget and inspect it, it sets a cookie, and includes another script through document.write, which in turn does some funky JS, and includes another script.
The moral of this story: This probably isn't a web site defacement attempt, but probably a browser hijack attempt. I don't follow IE security patches close enough to match anything with a knowledge base article, but some of the JS looked like buffer
Re: (Score:2)
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.
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: (Score:2)
On a Microsoft SQL server, there's a system stored procedure called xp_cmdshell, this allows you to run arbitrary commands under the permissions of the account the database is running under. And because Microsoft requires the user running SQL server to be a local administrator for the service to start, you have gained "root
Re: (Score:2)
I guess for the next generation of pc users, we need to educate them. I always said owning a computer is like ownign a car, you would never use a car without knowing how to drive, although you did buy the car.
Even more important, I think, is to educate the next generation of programmers. Just because you know how to make a car, doesn't mean you know how to make a safe car. Even if you are an expert driver, you really have no way of knowing if taking a specific car over 75 mph will cause a critical joint in the engine to fail. Saying that drivers should never drive any car above 75 mph to avoid that possibility isn't an acceptable solution.
Re: (Score:3, Interesting)
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?
You've hit exactly on the real problem. I'm a sort of hobbyist web developer with no real training. I can hack together websites using ASP.Net and SQL server that work (that is do what they're supposed to do), but I have no idea how write secure websites. I don't even understand the sorts of attacks I should be expecting. Furthermore, the 'my first website' books I learnt from don't really cover this sort of stuff except in passing, and learning about security is frankly boring.
Sadly I don't have a s
Re: (Score:2)
$r = db_query('SELECT * FROM {foo} WHERE a=%d AND b="%s"', $a, $b);
In this example, $a is converted to an integer (because of the %d) even if it came through CGI as a user request. $b is sanitized and will not allow the type of SQL injection that this article talks about (because of the %s). No worries about any security issues as
Re:Not surprised (Score:5, Informative)
Re: (Score:3, 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]
Re: (Score:3, Interesting)
Re: (Score:2)
Just so you know, by front-end, he doesn't mean javascript only (or at least I hope not). Check for SQL injection in whatever language your programming in too. Use prepared statements if you're using Java.
Re: (Score:2, Insightful)
I'll wager that it is the same camp of people who wait until they are absolutely forced to install service packs, because they don't want them to break their applications. Nothing worse than someone putting that bug in a small business "IT person's" ear... next thing you know none of their desktops have XP service pack 2 installed because they "heard it would break stuff"...
Re: (Score:2)
My poor Solaris and Mysql logs get to look like an ebook when they are put into a pdf for examining. I got tired of requesting a security audit, so I can request a patch maintenance window. Went to the CIO and set it straight what can happen and he let me patch. Only 6 months after ! Damn slow moving corporat
Just One Example (Score:5, Funny)
Re: (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: (Score:2)
Re: (Score:2)