Peter G. reported a malicious Java class that he downloaded yesterday. Now, this certainly looks interesting since this is an exploit for Java VM (not to be confused with JavaScript). This means that, in order to run the exploit, a vulnerable Java VM has to be installed on the machine.

The exploit comes in a small class file:

$ file java.class
java.class: compiled Java class data, version 46.0
$ md5sum java.class
0b67d360d5b1839820c0a39810b40498 java.class

As you probably know, Java class files contain bytecode, which is a machine language for the Java virtual machine. Luckily, bytecode has *a lot* of extra information which makes decompilation much easier (and viable, when comparing to x86 machine code, for example).

After analyzing the exploit, I found out that it’s using an old vulnerability (CVE-2007-0243) that has been patched since January. Mark also wrote about this vulnerability here. According to the CVE article, Sun JRE 5.0 Update 9 or earlier, SDK and JRE 1.4.2_12 or earlier and SDK and JRE 1.3.1_18 or earlier are all vulnerable. The vulnerability allows an applet to gain privileges through a GIF image.

This is exactly what our exploit does – it creates a malicious image that is then displayed on the victims machine. This causes a memory corruption which leads to code execution.

The sample is completely based on the publicly available PoC code that was posted to various security related mailing lists. The shellcode was, of course, changed – the current shellcode included a downloader which, of course, dropped the second stage (a password stealer).

AV detection

Now we come to an interesting point – the AV detection. I first submitted the Java class through to VirusTotal – the results were shocking – only 1 (!!!) AV program detected the Java class as malicious:


The second stage binary was no picnic either – only a handful of AV programs detected it correctly:

As this is a more or less standard password stealer I expect AV vendors to add detection shortly.

Conclusion

At this point in time I would say that I’m more worried about inability to detect the Java class properly. If you remember, back in March I wrote a diary about RTF documents carrying embedded executables (this attack scheme is still used in BBB/IRS phishing e-mails we wrote about several times). It is clear that AV programs are struggling with all these new formats – another sign that you should always rely on multiple layers of security.
Java upgrades could also be made easier: multiple available versions often confuse users (which version should I download) and the fact that old versions are left on the machine after the upgrade certainly do not help in resolving the problem.

Bojan

UPDATE

How many people are vulnerable to this Java exploit? Johannes did some statistics on ISC visitors that run Java. Of course, in order to collect these statistics you need JavaScript enabled in your browsers as well (so those of you who do not have JavaScript enabled are not counted, even if you have Java). It turned out that 86% of our visitors have Java installed.

Regarding patching, it’s generally OK but I would expect better results from security experts – about 12% are running vulnerable versions of Java VM. As we’ve confirmed that exploits such as the one described in this diary are in the wild, take a minute or two and confirm that you’re running the latest version.

Regarding the AV vendors - it looks like they're starting to pick this up (so they do read our diaries, do they? :). The test I did couple of minutes ago showed that the exploit is now detected correctly by 5 vendors on VirustTotal. Far away from perfect but improving.