The exploit comes in a small class file:
$ file java.class
java.class: compiled Java class data, version 46.0
$ md5sum 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).
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.
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.
Jun 7th 2007
Jun 7th 2007
1 decade ago