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.
TFA guesses the exploit is a simple SQL injection where the injected code consists of calls to MS SQL Server's sysobject calls. I imagine this would give the attacker some file system access, allowing for injection of script tags pointing to the attacking javascript, and so on. This is a clever attack, once again allowed only by MS insistence in allowing things like an SQL Server to execute stuff not related to its task. Note that, while this is convenient and useful, it should never be allowed by default.
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
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.
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.
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.
Almost every shared hosting and VPS out there does that... just not with MS SQL quite so often
This is my sig. There are many like it, but this one is mine.
http://www.mhall119.com
Maybe this?
sqlmap
I haven't tried it.
-- Wodin
It's really easy. For example:
$stmt = $dbh->prepare("INSERT INTO theTable (value1, value2) VALUES (:value1,
$stmt->bindParam(':value1', $value1);
$stmt->bindParam(':value2', $value2);
$stmt->execute();