As most of the IT press already reported, hundreds of thousands web pages, across dozen of thousands websites, have recently been hacked in what appears to be one of the largest on-going attack lately. But as with any major IT security incident, reports were initially quite conflicting about what went on exactly and who's to blame. Armed with a bit more information, we now can take a closer look at the events and we attempt a round-up of what is known so far, including the latest developments from Microsoft (who was originally blamed for an unknown vulnerability). 

This type of attack is two-stages : hackers first try to compromise a high number of high-profile, trusted, websites in order to booby-trap their pages. Then, when those sites serve the booby-trapped pages, users not only see the regular content, but they also (and silently) get served a malware of some sort through their browser, in order to compromise their system. Thus hackers are not after the webservers per se : they really want to own their visitors PCs in order to make them part of some botnet, and use them to send spam, host fake banking sites and conduct other illegal activities.

All the infected websites in this attack were running Microsoft IIS as their websever and MS SQL Server as their database. This caused quite a confusion when the attack was first publicized, prompting questions about a potential unknown vulnerability in either IIS or SQL Server. Microsoft, while initially admitting to be investigating an IIS flaw, came out later on with a clear statement denying the presence of any unknown vulnerability at work here within both IIS ou SQL Server, and blaming instead a regular SQL Injection attack. This has been confirmed since then by most experts, including antivirus vendor F-Secure, saying that "what makes this attack possible is poorly written ASP and ASPX (.net) code".

A dev mistake

The initial attack to compromise the websites was successful because of bad programming practices, and errors within the scripts or content management systems used to update the websites. As such, this is not one specific vulnerability, but instead many bad programmer habits found in many unrelated scripts. It all boils down to one thing, though : improper user input validation.
In this attack, just like any other SQL Injection attack, hackers started out by submitting an input to a script found on the victim website (such an input is usually coming from a webform, but here it was most likely sent directly to the script through an URL). The offending input, let's say it's a text to search the database, is made of a legitimate part plus an extra, illegitimate, portion containing instructions for the database to execute. If the website does not validate properly this input, the database will execute the request : it will look for and send back the search results, but also execute the others, illegitimate, instructions.

In this specific attack, the illegitimate instructions told MS SQL Server to look for all its text field and append a specific line of HTML to them. "The injected content consisted of an html iframe tag with a src of malicious server based in China. When an arbitrary user would view that content, he would be automatically redirected to that malicious webserver, which in turn attempted to exploit the user's browser with multiple vulnerabilities", explains Dominique Loiselet, Regional Manager for Websense. According to Websense, the eight vulnerabilities attempted here are already patched, so a fully up-to-date browser should be safe in the particular attack.

Google used to track victims

The attack seems to be on the downfall now, but many websites are still infected. "The number of infected sites has started to decrease. We attribute this to widespread awareness of the attack. Yet the precise magnitude of this attack is difficult to quantify due to the constant relocation of the hub sites that are serving the malicious exploits", says Loiselet. AV vendor Panda Antivirus estimated the number of infected webpages to 282,000, while F-Secure goes for a good 500,000.

The hackers behind this attacks seem to have used Google to identify their victims. According to Italian expert Giorgio Maone they relied on an automatic tool submitting the search pattern inurl:".asp" inurl:"a=" to Google. This leads to pages and scripts coded in ASP that accept an argument. At the time of writing, the same pattern in Google gives over seven millions hits. While all are not exploitable or even just related, it shows how this kind of attack will not be in shortage of potential victims anytime soon.

How to get protected ?

Protection against this kind of attack involves different techniques depending on whether one is a user or a website administrator.

For users :

• An up-to-date system (OS and browser). Security patches need to be applied as soon as they become available.
• A specific anti-malware protection. Of course, the antivirus comes to mind first. But there also are good sandboxing softwares to help isolate the browser from the rest of the system, or HIPS that will block unwanted installations or unknown executables showing a dubious behavior. Firefox users also have the option to install the free NoScript add-on. NoScript will only allow Javascript to run from authorized websites. And even if such an authorized website gets compromised, NoScript does not merely trust the main site URL, but it checks the originating server for the Javascript, and thus will also protect the user in such an event.

For website administrators :

• Safer scripts : it's time to audit (or have audited) the source code of that website designed by the intern last summer.
• Application filtering : Be it Mod Security for Apache, a commercial third-party software (like Secerno.SQL or Sentrigo) or an appliance (Imperva for databases and many other web firewalls), a layer of web and SQL filtering will go a long way against automated and simple attacks like this one.
• URL rewriting : It's not just cosmetic or to please the Google bot. From a security point of view, URL rewriting helps hiding your site's mechanic to the outside world. The URL /a/1234 is far less likely to be targeted by an automatic tool than index.asp?a=1234.
  Of course, this is no security per se, as the website will still be exploitable if it does not properly filter users inputs. But it will help reduce the exposition to automated scanning tools using Google to track their victims.