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.
Add this simple rule:
Yaz.
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.
It was even simpler than that (according to TFA):
./er suggested), but also not really spectacular creative.
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
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.
My blog
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.
Helps to understand the database, doesn't it? The "sysobject calls" are just reads to the underlying tables that store the database schema. The injection attack uses sysobjects to determine what tables exist. They did use sysobjects which is specific to MS SQL Server and Sybase, but they could have just as easily used INFORMATION_SCHEMA which are a series of ANSI compliant views that contain the same information and work on virtually all databases.
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.
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.
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.
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.
Yes, sounds like someone didn't Sanitize their input.
If only they had little Bobby Tables doing the testing.
ah ok let me just look this up on the vulnerability chart here ok, your server is Linux... very good, very good your databases are all only accessible to localhost, ok looks like you are EXACTLY as vulnerable to SQL injection as everyone else. Running Linux and preventing remote users on your database does NOT protect you. If you have a script on your server that doesn't sanitize even one input, you are just asking for trouble. you WILL get hacked sooner or later.
Username taken, please choose another one.