Over the past week, an unusually large percentage of malware blocked by ScanSafe Outbreak Intelligence has been coming from a number of primarily UK-based specialty type web sites. That legitimate websites were dispensing malware isn’t so unusual – legitimate sites are frequently compromised and turned into malware vectors. Generally though, when a site is compromised and retrofitted to deliver malware it’s in the form of a static iframe which references a remote web site. In such cases, a Google search on the contents of the iframe are all that’s required to get a read on how many other potential victims there are. For example, in the recent SQL injection attacks, a search on “uc8010.com” (the site referenced in the SQL injection iframe) would result in a list of sites similarly compromised.

But this current attack is substantially different. When ScanSafe STAT investigated, we discovered the following:

1. The reference inserted in the page points to a randomly named (5 char) javascript file. For example: <script language='JavaScript' type='text/javascript' src='kucsq.js'>
2. The reference is pointing to a local .js file – not one located on a remote server.
3. The referenced javascript doesn’t exist until the user accesses the page, and it doesn’t persist on the site. In other words, an admin perusing the site looking for these rogue javascript files would not find any visible signs.
4. These randomly named and dynamically created javascript references and files are also randomly delivered. That random delivery is not based on IP or whether or not it’s delivered the javascript to that user before; it will deliver the script to the same IP multiple times – just randomly.

The javascript file includes multiple exploits – one of which behaves eerily like the latest QuickTime RTSP Vulnerability for which details were just released publicly on January 10th. The sites we’ve been investigating were compromised prior to that. And of course old standby exploits such as the ever present MDAC exploit were also employed. The end result: a visitor to the site with javascript enabled in their browser who was vulnerable to the nearly dozen various exploits would have a backdoor silently installed on their system.

But that’s not the worst part.

The attacks are not compromised sites, but rather what we suspect to be the result of a Loadable Kernel Module (LKM) backdoor, i.e. a rootkit-enabled backdoor planted on the host server. What we don’t know, but hope to discover, is how the backdoor was planted on the host servers. In the process of discovering that, we also hope to discover why these particular hosts? Thus far, tracking the sites invariably leads back to several hosting companies located in the UK. But besides location, nothing else about these servers distinguishes them from tens of thousands of other hosting servers throughout the world. The vast majority of these servers are running various flavors of Apache and various flavors of Linux and Unix are involved. CPanel appears to be common on most, if not all, of the boxes.

We do believe the near constant presence of CPanel is a factor. We aren’t, however, convinced it’s the root of the root compromise. We think it’s more likely that the backdoor is exploiting vulnerabilities in CPanel in order to manipulate the modules used to deploy the attacks.

The reason we think this is really just a matter of numbers (and that whole geo-location question). If the initial means of compromise were due to exploit of an underlying vulnerability, it stands to reason that far greater numbers would be impacted.

But if CPanel wasn’t the entry point, what is?

To help us solve that puzzling question, Dan Goodin at The Register generously wrote about the challenges of this attack, and that article has prompted much useful discussion. It’s also helped foster a great deal of cooperation from some of the impacted hosts and site owners; cooperation that will be key to solving this puzzle. And it’s also led to additional exposure and discussion of the problem here and here. Our hope is that these discussions will lead to finding out exactly what caused the compromise on the host servers and, of course, how to eradicate it.

Yes, we've been working with as many of the site owners and hosts as we can. We've also tried disabling mod_bwlimited (which contains the script reference) and turning enable_dl off. Within a very short period, the sites were happily spewing out malware again and the configuration changes had been mysteriously reversed.

We've also tracked how visitors are getting to the sites. Apparently these mom & pops are doing extremely well in search engine results - the origin of the majority of the referrers. For those not already using the ScanSafe service, we highly recommend sanitizing all of your search results by using the completely free Scandoo (www.scandoo.com) which works with Google, Yahoo and Live (MSN) searches.

Of course, make sure your patches are completely up to date (the free Secunia Software Inspector is a great tool for checking individual PCs). There’s no patch yet for the latest QuickTime exploit. My workaround was just to uninstall it until Apple releases a patch. Your mileage may vary.