The Latest in IT Security

There is a new Java vulnerability now publicly disclosed, CVE-2012-5076. Recently, we have seen more and more Java malware and malware distributors using new vulnerabilities quicker than ever before. Here’s a brief analysis of this newly disclosed Java vulnerability and related malware.

Just like the recent CVE-2012-4681, this vulnerability is about a package access issue. But  this time, it’s not caused by vulnerable code that exposes restricted packages. The malware we’ve seen (detected as Exploit:Java/CVE-2012-5076.B) abuses a package access problem in the JRE configuration. This package access is important because, if some trusted code is exposed to the user, it can be abused to break the Java security model. Those packages usually contain critical operations that should not be performed from untrusted code like unsigned Java applets. These operations are usually about arbitrary class loading and method invoking inside the trusted code area.

Some packages (including com.sun.org.glassfish.gmbal) that should not have been accessible to untrusted Java applets are exposed to them. Unsigned Java applets run inside a sandbox environment which strictly restricts the applet’s access to system resources like file and process operations. However, when some dangerous packages are exposed to untrusted code, the malicious code can access packages that can be abused to create the user’s own class on the fly with escalated privileges.
 
From the com.sun.org.glassfish.gmbal package, the malware used util. GenericConstructor class and ManagedObjectManagerFactory class to attack the Java security model. Class util. GenericConstructor is used to create an object from a restricted class (sun.invoke.anon.AnonymousClassLoader) and ManagedObjectManagerFactory’s getMethod method is used to retrieve the method object of “loadClass” from sun.invoke.anon.AnonymousClassLoader class. sun.invoke.anon.AnonymousClassLoader is a good target for attack in this case as it has the ability to load a class on the fly from a provided byte stream. But, the class sun.invoke.anon.AnonymousClassLoader itself is not vulnerable; the class is just chosen as it provides useful features for attackers.
 
Using the loadClass method from sun.invoke.anon.AnonymousClassLoader, they load a malicious payload class on the fly. The sample we analyzed (sha1: 76bac76730283b298fe67c5e301cf3f32d968e0a) had a payload that looks like Figure 1. As this malicious payload class is loaded from trusted code, it has the same privileges as trusted code.
 

Figure 1 Malicious payload class
 
The one part that is very common in Java malware is the part where it disables Java security manager. Figure 2 shows the code that performs this operation from the payload class. After disabling security manager, the malicious code can create files and processes on the user’s system.

Figure 2 Disable Java security manager
 
Figure 3 shows overall flow of the malware exploiting this vulnerability.

Figure 3 The overall flow

1. Malicious applet uses GenericConstruct class to load restricted class (AnonymousClassLoader).
2. Malicious applet uses ManagedObjectManagerFactory class to retrieve Method instance of loadClass method from AnonymousClassLoader.
3. Pass byte representation of malicious class to loadClass to load it using ClassLoader from trusted code.
4. loadClass method loads malicious class on the fly with escalated privilege.

One notable thing with this vulnerability is that only the Java 7 distribution is vulnerable according to Oracle’s security update page. Also, from our testing, the malware fails to abuse any Java 6 installations whether they are up to date or not. So, that might be one reason why most of the malware samples that actually exploit CVE-2012-5076 are bundled with other Java exploits, for example, CVE-2012-1723. As CVE-2012-1723 can be used on both unpatched Java 6 and 7, and CVE-2012-5076 only works on unpatched Java 7, they combine both exploits to increase their coverage.
From what we have seen in the last few months, we expect to see more and more exploits abusing this vulnerability. So, users should be prepared for this threat. Some good news is that Oracle had already issued the patch way before the first reported sighting of this malware. You can visit the  Java update site to update and protect yourself from this new threat.
 
Jeong Wook (Matt) Oh
MMPC