Last month, we saw a new Java vulnerability (CVE-2012-1723) being used by malware. This new Java vulnerability is a type-confusion, same as the notorious CVE-2012-0507 AtomicReferenceArray vulnerability. The vulnerability was resolved on June 12th by Oracle and a discussion on the vulnerability was made public on June 13th (though some security updates had appeared in a Java related OpenSource project in early April). Even so, it took some time for the malware writers to adopt this new vulnerability for their arsenal after the update was released. Indeed, we saw first samples in early July:
Figure 1 Timeline for CVE-2012-1723
After the appearance of the first malware exploiting this vulnerability, the amount of malware abusing CVE-2012-1723 began increasing. The chart below shows how this new vulnerability began overtaking the exploiting of CVE-2012-0507 in late July.
Figure 2 Two most recent Java vulnerabilities detection trend
Here is an analysis on a malware sample (SHA1: 64d25e09d99fa7ba219fa99d1ffefac6c0310349) that exploits this vulnerability. This malware is detected as Exploit:Java/CVE-2012-1723.A in our engine.
The issue is in the optimization performed when a field inside the class is accessed. The following code shows a typical part that appears in malware code that exploits this vulnerability. A static field with a ClassLoader or Object type and bunch of instance-fields with custom data type is a strong indication of exploitation. A bunch of instance-fields are a buffer area where a type-confused object is retrieved.
Figure 3 Part of malware code
The following is the code part that tries to exploit this vulnerability. This routine will be called multiple times to ensure that the information is cached in memory. It passes a parameter of null to make the call return quickly for this multiple calls. After that, it passes the ClassLoader subclass instance as the parameter. This is type-confused to a custom data type the attacker has constructed:
Figure 4 Part of malware code
So as we said, this core exploit method is called multiple times to make sure the information is cached in memory. That is one of the essential parts in exploitation. The interesting thing is that the numbers of these calls differ between different groups of malware: Some are using a very high number when some are using somewhat lower numbers. We even saw a few different types of exploitation methods used in early July. The different details of exploitation methods might indicate that multiple parties were pursuing this vulnerability for malware use, and the malware was developed independently in the first place. Indeed, we observed a lot of copycats later when the information was spread through the malware writers.
There is one more interesting thing with this vulnerability: this is not a vulnerability caused by any Java classes in JRE, as with previous cases of Java vulnerabilities used by malware. This is a problem inside the Java Virtual Machine implementation called HotSpot.
Java-based malware could use a Java-reflection feature to obfuscate vulnerable class and methods loading code when the vulnerability is inside specific class and methods — for example, CVE-2012-0507 was related to AtomicReferenceArray class. The loading of AtomicReferenceArray class itself can be obfuscated and you can’t easily tell whether it is loading the specific class at all just by looking into the Java code. This makes the whole malware analysis process more time-consuming.
For this vulnerability, attackers can’t obfuscate the core exploit part easily. As we explained with Figure 3, the attackers need to create a class with specific features like static field member with ClassLoader type or Object type. And bunch of instance fields follows. It has specific code pieces to run which looks like the code shown in Figure 4. Java doesn’t provide ways to obfuscate this class structure itself, so the code pattern stands out. You can easily identify the pattern just by statically investigating the code.
Easy identification of exploit code might be an advantage for malware analysts, and it makes the vulnerability a little bit less attractive to malware writers. Still, malware abusing this vulnerability is gaining some traction, and the detection count is going over that of malware abusing the previous major Java vulnerability (CVE-2012-0507).
Just like malware abusing other type-confusion vulnerabilities with Java, these malware also show a high success rate with exploitation when Java Runtime Environment is not updated to the latest secure version. You should follow the instructions from the blog we published a few days ago to prevent being vulnerable to this type of exploit. Make sure you don’t fall victim to these malware.
Jeong Wook (Matt) Oh
MMPC
Leave a reply
