Over the past few weeks we have been tracking another widespread compromise of legitimate web sites.
Huge numbers of sites have been injected with a malicious JavaScript that attempts to load content from an exploit site when innocent users browse the affected pages.
Compromised pages are blocked by Sophos products as Mal/ObfJS-AB. The scale of the attack is evident when looking through our threat prevalence data – Mal/ObfJS-AB has risen to the top of the web threats, accounting for almost 25% of all reported threats.
Grabbing a batch of the sites hit this week, it is obvious that the compromise has affected a good number of hosting providers
Without access to logs from the sites/servers that have been hit, I cannot state exactly how the sites were hit. Checking some of the recently hit sites suggests the problem is not limited to a specific platform: the host servers are running a mixture of Apache (74%), IIS (13%), something else (7%). (In the remaining 21% of the checked servers, there was no response received.)
The purpose of the compromise is to redirect to an exploit site. A malicious script there (blocked as Mal/ExpJS-N) fingerprints the user’s browser and browser plug-ins (PDF/Java) and then attempts to load relevant exploits in order to infect the user with malware. At the time of writing, the payload being delivered is a Zeus (aka Zbot) variant (blocked as Mal/EncPk-AAG).
The various steps involved in this attack are summarised in the diagram below:
As regular readers will recognise, the attack consists of the usual sequence of steps we typically see for malware delivered via the web.
Note that victims browsing compromised sites will be unaware of all these steps – all the malicious content will be silently loaded by their browser in the background whilst they peruse the original web page.
Perhaps the most interesting thing about this attack is the exploit site JavaScript (the content we block as Mal/ExpJS-N. We have been seeing the same exploit script at the end of spam links and JS/Sinowal-V redirects in recent weeks. The script is heavily obfuscated and uses polymorphic and anti-emulation techniques to attempt to evade detection.
Sounds nasty. I wonder if it affected any specific kind of websites e.g. blogs such as WordPress or something.
Many of these mass-injections do target vulnerabilities in applications running on the web server (blog, CMS, guestbook, gallery etc). That is why it is so important that site admins routinely patch and update such software to latest versions, and (perhaps more importantly) remove applications that they are not using (but which may be installed by default by their hosting provider).
If we use alternative PDF apps such as PDF Xchange, would we still be affected by the exploit?
Switching your applications to avoid those commonly targeted may well prevent a specific exploit working on your system, but it is not really the solution. Far better is to ensure the applications you do use are fully patched and updated. (And in this example, Java and HCP exploits are also used.)
All applications are liable to bugs (and potentially exploitation therefore) and need to be kept updated. It is far easier to manage this without a plethora of different office/PDF/browser applications to have to manage.
Expect us