In the past few months, we encountered two serious Java vulnerabilities; one is CVE-2012-4681, the other is CVE-2012-5076. Both of them have some common characteristics, the first being that both of them are Java applet programs. The second is that they use a Java reflection mechanism to break Java applet security restrictions and load malicious payload.

Java reflection is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. It’s main functionalities are as follows:

  • Get class
  • Get all members and methods in class include private ones
  • Invoke methods

Java reflection makes it convenient for developers to write Java programs, but also opens up opportunities for malware writers to circumvent the security measures. This is because Java reflection allows access to hidden fields which leave it vulnerable. Java reflection requires a runtime permission which may not be active when running under a security manager. This is an important consideration for code which has to run in a restricted security context, such as in an Applet.

For example, CVE-2012-4681 used reflection to get the private field of “statement.acc “, and then using the “setfield” function to change the value of  the acc file. “Java.beans.statement” is also an Java reflection of sorts which is key code in breaking security restrictions placed on Java.

In November, we detected another Java applet vulnerability, CVE-2012-5062. The root cause is that Class “util. GenericConstructor”  is used to create an object from a restricted class (sun.invoke.anon.AnonymousClassLoader) and get its function “loadclass” which it uses to deliver a malicious payload, via reflection to:

  • Get the method “loadclass” in class (sun.invoke.anon.AnonymousClassLoader) and invoke.
  • Get the method “r” in payload class and invoke.

Following picture show detailed information of the malware:

When analyzing CVE-2012-5062, we face one problem. Comparing to the POC given by metasploit, we cannot find any sensitive strings which target class names such as “sun.invoke.anon.AnonymousClassLoader” or the method name “loadclass” in a malicious applet. After examination, we find the trick is using an unassigned field: string array A in the malicious applet.  It’s worth mentioning that the malicious applet is using a static block to initialize the static field A, which only contains obscure Java byte code.

To read this static block is a time-consuming task and not easy. Luckily, Java reflection can not only be used by to write malware but can be used to ascertain the content of A by:

  1. Using “Class.forName” to load target class
  2. Using “getDeclaredFields” to enumerate all fields.
  3. Using “setAccessible” to expose private fields.

After the above steps, we can get the string array without any code reading.

The string array contains five members.

  • A[0] means method name ‘loadclass’
  • A[1] and A[2] are labels  in html so that function “getParameter” can get the contents of those labels, and use the content to decrypt  the download URL.
  • A[3] is name of the class.
  • A[4] are encrypted byte codes of payload class.

After further reading, we found function “bagdfssda” is the decryption function. We can decode the payload class by using reflection to invoke “bagdfssda”. The following picture is the payload class after decryption.

The main intention of the payload is downloading files. From the analysis we have done, we realize that we must stay alert to Java reflection which is widely used in Java malware. On the other hand, we can use reflection to expose the malicious code  and make our work easier.

Lastly, AVG wants to remind you that if you update your Java to latest version, it can keep you safe from such threat.

 

Frank Zheng and AVG Viruslab Research Group