A Java exploit
Published: 2007-06-07,
Last Updated: 2007-06-07 22:50:48 UTC
by Bojan Zdrnja (Version: 2)
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:
VT results (Java class)
The second stage binary was no picnic either - only a handful of AV
programs detected it correctly:
VT results (2nd stage binary)
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.
