About Me

Bay Area, CA, United States
I'm a computer security professional, most interested in cybercrime and computer forensics. I'm also on Twitter @bond_alexander All opinions are my own unless explicitly stated.

Friday, April 8, 2011

Reversing malicious Javascript, part 2

This is part 2 in my adventures reverse-engineering a malicious Javascript I found on my computer. Last time I unraveled some annoying string manipulation that eventually ran return eval(String.fromCharCode()) on a long series of Unicode-encoded characters.

I finally unencoded that long string of Unicode and, as expected, it was more Javascript. I was surprised at how much there was ... several hundred lines of code. This is unusually large for malicious Javascript. Bigger doesn't mean more sophisticated, however!

There are two Javascript functions that are relevant here. The first is called 'zazo', which tries to exploit a vulnerability in the Java Development Kit to load a malicious Java applet that the attacker controls. The payload is gone by now, so I can't tell what it would have done. This is a known vulnerability, CVE-2010-0886, and is described in detail here.

The second function is the reason this malicious script is so long. It includes a version of PluginDetect, a script by Eric Gerds that is designed to determine what version of many common browser plugins are being used. In this case, the malware author has it probe for Java and Adobe Reader versions, although the script only uses the Adobe Reader version. Although this plugin detector is being used maliciously, it's not inherently malicious and there's no reason to think Eric has any connection to the malware author.

After determining what version of Adobe Reader is being used, the script makes a simple calculation: if Reader is older than 8.0, it serves up one malicious pdf. If Reader is between 8 and 9.3.1, it serves up an alternate malicious PDF. If you don't have Reader or if your copy of Reader is up to date, you're safe from this script. Reader version 9.3.1 was released specifically to patch the vulnerability described in CVE-2010-0188, which affected Reader versions 8 to 9.3, so we can be fairly sure that's what this PDF was exploiting.

Interestingly, in part 1 we discovered that this bit of malware knew that it was 2011 and it would need to be modified to function in a different year. Despite that, the three bugs it attempts to exploit are old. The Java bug had a patch available a year ago. With the Reader exploits, one was patched last November and the other only affected versions older than 2006! These are not anywhere close to 0-day attacks. This is exactly why it's so important to keep your software up to date.

Also, Java is very frequently exploited. If you don't absolutely need it, get rid of it. Then hackers will have one less way to attack you and you'll have one less program to keep updated.

No comments:

Post a Comment