Slashdot Mirror
Mass Hack Infects Tens of Thousands of Sites
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.
...those of you who thought "Awesome!"
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...
Seven Days with Ubuntu Unity
Woah, I was almost worried for a second before I read it was Microsoft specific!
My darling Apache and PostgreSQL may you never let evildoers overflow your fair buffers.
*wipes brow*
this kind of crap ain't gonna stop until we have a fundamental change in our approach to security: and that is we use a WHITELIST to authorize execution of the programs we trust and exclude EVERYTHING else.
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.
Add this simple rule:
Yaz.
Wouldn't NoScript protect the Firefox users out there?
Speedy thing goes in; speedy thing comes out.
Reading the referenced article it seems to almost applaud the success of the attack. This isn't a "good" attack its a very bad attack in that it has been successful and could potentially inflict damage on thousands or even millions of users. Its like claiming that something was a very "good" fraud because it robbed thousands of old folks of their life savings.
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.
An Eye for an Eye will make the whole world blind - Gandhi
AV firms came back to work yesterday ;)
They had a 2 week holiday.
liqbase
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
Description and explanation is here.
I will gnaw my leg of if this dribble gets modded up.
Bot Assisted Blogging
Uh - this attack didn't involve the execution of any "code" - at least nothing that selinux/etc would recognize as such. SQL Server was hit exclusively not because of any particular vulnerability - but because the attack used syntax specific to that server only.
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...
SQL injection attacks are universal across database platforms. No matter what front-end and back-end you use for a database store, if you're building SQL command strings in memory with unscrubbed external inputs, you're liable for an attack. This attack relied on SQL Server's sysobjects table, but that wasn't the vulnerability, that was just the target.
If you search for "uc8010.com" in Google then click on the omit link at the bottom it shows about 94,000 "PAGES". Not Servers! One server had most of the pages infected. BTW, this is NOT a compromised 'SERVER'. The SQL database got injected with content but the actual server isn't compromised. This isn't news.
Thats funny, I recently complained to a US based, MidPhase about some Chinese scam site, uer168(dot)com. I noticed some similarity in the domain with the uc8010(dot)com domain from the article. The whois data is also much alike, at least the registrar is Xin Net Technology Corp. for both.
So far Midphase has refused to take the scam site off line, even though it's seems these Chinese crackers are affiliated.
The server-side exploit is not binary code. It is a SQL injection attack. The only thing that ties it to MS SQL Server is the fact that they decided to use the sysobjects table to locate other tables. They could have just as easily used the ANSI-compliant INFORMATION_SCHEMA.TABLES view, which is available in most databases including MS SQL, MySQL, Postgres, Oracle, DB2, etc.. From there they could have used ANSI standard SQL to push their updates into the database containing their malicious javascript.
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.
Thank you for printing this statement. It is amazing how most "technical" people don't understand what a SQL injection attack is and that it is platform independent. These attacks have to be stopped in your front-end development and not in the database engine. If you are writing code that is this unsecure (especially in 2007) then you shouldn't be coding at all. Also the MDAC was patched more than a year ago. Why weren't the patches applied?
Not at all impossible to prevent!
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.
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.
A house divided against itself cannot stand.
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
Here are more details on how such an attack can take place, and the devastation it can cause.
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"...
Only this isn't a Windows virus, it's an SQL injection attack. Most likely the vulnerability isn't even in Microsoft code, but in some popular business web application that uses MS SQL for the backend. Tweaking that to exploit a PHP application that uses MySQL for the backend wouldn't be any more difficult.
http://www.mhall119.com
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 solution, and I don't think there is one. Thinking along a public health analogy, advocating 'safe web programming' is difficult because its far less fun, and advocating abstainance for those who aren't qualified isn't going to work because, well you know what kids are like. Enforcing a ban is culturally unacceptable and impossible in any case.
Maybe this?
sqlmap
I haven't tried it.
-- Wodin
I've used un-scrubbed corporate app inputs to my advantage. At GE, we had two databases that didn't talk to each other. At all. We had to manually enter the data from one into the other line by line (why they paid engineers to do such mindless work is beyond me, maybe it's because we were on salary). Eventually, I figured out that the second database didn't get rid of things like HTML tags from the company front end app. So instead of entering the data line by line in the second database (which nobody ever used, except to print one form), I just wrote a script that output the appropriate HMTL table from the first database, and just pasted that into the "Comments" section of the second database. The result was a form that looked exactly like one that was entered line by line, but it took about two hours less to do it. It printed out fine, so none of the PHBs cared / knew the difference. Also, my method allowed people to do useful stuff like link to equipment data sheets and embed Goatse pictures before they resigned.