A BlackHole Exploit Toolkit sample that exploits the Oracle Java SE CVE-2012-1723 Remote Code Execution Vulnerability was released in the beginning of July 2012.
The vulnerability exists due to “type confusion” between a static variable and an instance variable. A static variable is common in a class, whereas an instance variable is only valid in an instantiated class. In the sample, the class defines many variables:
class C2
{
static ClassLoader static_field;
C3 f0;
C3 f1;
C3 f2;
… continues to f99
C3 f99;
In order to access the static variable static_field, we use C2.static_field. In order to access the instance variable f0, we use this.f0. You can use this.static_field in Java source code but once it is compiled, this.static_field is compiled to C2.static_field in the byte code. This is because static variables are completely different from instance variables. The javac.exe compiler is not confused by field types.
However, as Michael ‘mihi’ Schierl mentions, if a Java byte-code assembler is used or if a class file is patched by hand, it is possible for “type confusion” between variable types to occur. The sample contains the following code:
classloader2 = C2.static_field;
this.static_field = classloader3;
Due to this illegal code, a vulnerable Java VM would not be able to determine between the static variable and the instance variable, leading to referencing a wrong variable (one of f0 through f99 in the sample), which has not been verified as safe. Consequently, the malicious C3 class will be executed without any of the limitations imposed by the Java VM sandbox.
Many security vendors added detections for this sample. And as a matter of course, the malware authors started to obfuscate the malicious Java programs in an attempt to escape the detections.
A year ago, such obfuscations were mainly achieved by an author’s source code, whereby redundant code was inserted and class names were changed randomly. Furthermore, sometimes certain obfuscation tools, both commercial and free, were also applied by the malware authors. Nowadays, obfuscation is primarily achieved by such obfuscation tools. A recent JAR file (MD5: 2b65631bc1239838e7db52f1e623cc27) detected as Trojan.Maljava, contains four class files, fawa.class, fawb.class, fawc.class, and fawd.class under a package named fawa, and all of them are obfuscated by a commercial obfuscator.
Each class contains ambiguous names of fields and methods. The fawa.class file contains fields fawa and fawb, and methods fawa (fawa, String), fawc (fawa, String), fawa (fawa) and fawb (fawa, String). The fawb.class file contains fields fawa and z, and methods fawc(), fawa(), fawa (String), fawb(), and fawd(). The fawc.class file contains many fields whose names start with “faw” and methods fawa() and so forth. The fawd.class file also contains similar names for fields and methods. The only distinguishable name is fawd.init(), which is necessary because it extends the Applet class.
Since the package name, class names, field names, and method names share the same meaningless names, it is not easy to understand the program at a glance.
If the Web page containing the JAR file is viewed on a Java-enabled Internet browser, the fawd class is executed first. The fawd class then executes the fawc class. If the Oracle Java Runtime Environment is not patched, the fawc class successfully exploits the Oracle Java SE CVE-2012-1723 Remote Code Execution Vulnerability and executes the unverified fawa class, which can escape the sandbox of the Java VM. Next, the fawa class executes the fawb class. The fawb class contains a long encrypted string variable, which has, in fact, been encrypted by the commercial obfuscator. The string is decrypted when the fawb class is initialized.
The long string in the fawb class starts with “33r00yv66vgAAADIAwgcAAgEACGEvaGl” and it is stored in the static field z[0]. The string is passed to its BASE-64 decoder as z[0].substring(5), thus cutting off the first five characters of “33r00.” The decoded string starts with 0xCA, 0xFE, 0xBA, and 0xBE, which is the code for the start of the hidden.class file under the package “a”.
The hidden.class file calls setSecurityManager(null) in order to nullify the current security manager, which is possible because it has escaped from the sandbox. The hidden.class file then extracts another class, V.class, from the encrypted string.
When the fawd class is first called, it obtains a parameter “sw” from the HTML file. The parameter string is passed through the fawa class, the fawb class, and the hidden class to the V class. The V class splits the parameter “sw” by using colons (:). It then decrypts each URL from the split strings, and saves them to the following location:
%Temp%\fest[NUMBER]r_ot.exe
Note: Where [NUMBER] starts at 0 and is incremented by 1 for each download.
The retrieved files are then executed. We are not aware of the HTML file that determines the downloaded URL and cannot tell what would be downloaded. However, it we can be fairly certain that whatever is downloaded onto the compromised computer is likely to be malicious.
Although the relationship of the classes is complex, it is the fawc class that contains the smoking gun for the Oracle Java SE CVE-2012-1723 Remote Code Execution Vulnerability:
System.out.print(fawc.fawh);
this.fawh = classloader1;
Here a static variable fawc.fawh is accessed as an instance variable, this.fawh. The author has changed classloader2 = C2.static_field to System.out.print(fawc.fawh). The basic idea remains the same.
We detect similar samples as Trojan.Maljava!gen23. Oracle has fixed this issue in the most recent Java update. Users are advised to update the Oracle Java Runtime Environment to the latest version in order to prevent the successful exploitation of this vulnerability.