In one of my previous posts I described how the CVE-2012-1889 vulnerability (CVE2012-1889: MSXML use-after-free vulnerability) works, but the Java exploitation process is too easy for the bad guys not to revisit it. The attacker does not have to think about problems with ASLR/DEP, SafeSEH and other security mechanisms included in the latest versions of Microsoft Windows. All the tricks for bypassing security mechanisms make the exploitation process more unstable and are not universal across platforms.
[heap-spray results from JS/Exploit.CVE-2012-1889]
Previous, the Java vulnerability most commonly used for mass exploitation in popular exploit kits was CVE-2012-0507 (Blackhole, CVE-2012-0507 and Carberp). This vulnerability uses a logical bug in AtomicReferenceArray by using the Unsafe class to store a reference in an array directly, which may violate type safety if not used properly.
CVE-2012-1723 is an interesting vulnerability, based on a bug in the Java HotSpot VM with the bytecode verifier where an invalid optimization of GETFIELD/PUTFIELD/GETSTATIC/PUTSTATIC instructions leads to insufficient type checking. The vulnerability allows malware a way to evade the JRE (Java Runtime Environment) sandbox, so that it can load additional java classes in order to perform malicious actions. CVE-2012-1723 is a cross-platform vulnerability and can be used to attack all platforms with an actual JVM (Java Virtual Machine) version. In the cases of both CVE-2012-0507 and CVE-2012-1723 the vulnerabilities were made public by Michael ‘mihi’ Schierl. These vulnerabilities are of a similar nature, using bugs in the logic of JVM components in order to work. Today, CVE-2012-1723 multiplatform exploitation code was made public by publishing it in the Metasploit Framework repository (java_verifier_field_access.rb). ESET products already detect the CVE-2012-1723 vulnerability as JS/Exploit.CVE-2012-1723.
The exploit for CVE-2012-1723 (New Java Exploit to Debut in BlackHole Exploit Kits) is already included in the latest update of the BlackHole exploit kit. It has already ceased to be a zero-day vulnerability, but in practice Java exploits constitute a large percentage of successful attacks even after a patch has been released. BlackHole is now the most common exploit kit, and a license for one year with support costs $1,500 on the cyber crime marketplace.
The exploitation code packs the following object structure into a JAR (Java archive file):
So as to provide execution of a malicious payload, an additional 100 static fields in class C2 were crafted and assigned a NULL value. At the next stage of exploitation another 100 instances of class C3 non-static confuse methods are generated. This operation looks like this in java bytecode:
At the next step of exploitation the confuse method is called many times and results in the execution of malicious code. This code executes by loader class and provides additional classes loading in an escalated privilege context and performing operations that enable evasion of the sandbox mechanism.
When the Java code is decompiled these operations look like this:
At the final stage of exploitation a new application domain is built which executes outside the sandbox and runs a malicious java applet without security checks.
The Java platform is particularly interesting to attackers at this moment because vulnerabilities are continually being found, and exploitation looks easier than exploitation of native, platform-specific applications where operating system security mechanisms may get in their way. A working exploit for a known Java vulnerability may take a few days to develop, whereas it may take a few weeks to develop exploitation code for a native application.
Aleksandr Matrosov, Security Intelligence Team Lead
