Dissecting the CVE-2013-2460 Java Exploit

Introduction

In this vulnerability, code is able to get the references of some restricted classes which are cleverly used for privilege escalation and bypassing the JVM sandbox. The vulnerable “invoke” method of the “sun.tracing.ProviderSkeleton” class is used to issue calls to the Class.forName() method for loading internal restricted classes and methods.

Vulnerability Exploitation Procedure

To define tracepoints in any Java application, one must extend the Provider interface in their program. Creating a Provider instance is done with the help of the factory class ProviderFactory. ProviderSkeleton gives all the implementation needed by a framework provider by implementing two important interfaces, namely “com.sun.tracing.Provider” and “java.lang.reflect.InvocationHandler”. As mentioned earlier, it also has the implementation of our target “invoke” method. Invoke is the default invocation handler associated with Provider class and is created when we call the “Java.reflect.Proxy.GetInvocationHandler()” method with a Provider class object as parameter.

So, the code for this would be:

<Invoke object> = class.forname(java.lang.reflect.Proxy).getmethod(getInvocationHandler), new Class[] { Class.forName(java.lang.Object) }).invoke(Class.forName(java.lang.reflect.Proxy)), new Object[] { <Provider object> });

Class.forName():

Class.forName is the dynamic Class Loader in Java. It initializes a class by calling it’s static methods and constructors, if the class was not previously not being loaded.

The following restricted classes are loaded in the exploit using the <invoke object>:

•      “sun.org.mozilla.javascript.internal.Context”
•      “sun.org.mozilla.javascript.internal.DefiningClassLoader”
•      “sun.org.mozilla.javascript.internal.GeneratedClassLoader”

MethodHandles.Lookup()

There is a call to the “MethodHandles.Lookup()” method which does the AccessController checks only while creating the class instance and not each time the call is made. A lookup object has the capability to access any method handle that the caller has access to.

Context stores some information about the program like the call stack. To associate the newly created context with the current thread, an object of the “enter()” method of the “sun.org.mozilla.javascript.internal.Context” class is created using the lookup object we created. Similarly, method objects for “defineClass()” and “createClassLoader()” from the other two classes are also created. All these three objects are eventually used to disable the SecurityManager enforced by the browser for running Java code.

Privilege Escalation!

Typically, a web applet runs with the SecurityManager provided by the browser. This way, user code does not have the privileges to disable it. In our case, we are able to invoke restricted browser libraries and generate a new ClassLoader. So, this ClassLoader is of the same context as that of the SecurityManger. Finally, defineClass loads the binary object of another class using the privileged ClassLoader and sets the SecurityManager to null after it has successfully performed the bytecode verification.

We will get into this more when we go through each step in detail.

Test Case: Flashpack EK

The malicious jar files we found in multiple exploit kits (EKs) use different types of obfuscation to make them undetectable. In this blog, I will be explain the analysis of a jar file we found in the Flashpack EK, which was using the same exploit. The file can also be downloaded here.

The jar file runs as an applet in the browser and is triggered from the EK’s landing page after it has checked the Java version installed. The jar contains following classes:

Java Code Deobfuscation Routine:

Code generates strings from garbage text by calling “crock.zam()”. The following three methods perform all of the deobfuscation routine:

The entry point class “a1.class” needs the following three parameters: “urla”, “t” and “tt”. The code proceeds with creating an object of “crock.class” and calling “badafzew()” method. 

In “crock.badafzew()” creation of following three objects takes place:

1. The contents of “pashka.class” is fetched as a stream and stored in a byte array object of size 8KB, but it is utilized later in the program for disabling the SecurityManager. 
2. In the next step, “b3333.cadvsfew()” is called in which the Provider object is created using the ProviderFactory mechanism.
3. A call to GetInvocationHandler() returns an object of the vulnerable “invoke()” method.

The execution is then transferred to “nano.allokas()”, passing all three objects created as parameters.  In the “allokas()” method, an object of “cve.class” in created, which gives us the following two important static method objects:

The invoke() method object is used for the first time to generate class objects of two restricted classes as follows:

Using these class objects, two method objects are created for enter() and createClassLoader()methods.

 

The last step is to perform an invoke action on the “sun.org.mozilla.javascript.internal.DefiningClassLoader” methodhandle and pass a byte object of “pashka.class” as a parameter. This results in successful disabling of the SecurityManager.

 

Now that the SecurityManager is disabled, the applet is free to perform privileged actions like saving files on the user machine, downloading data and performing file execution. All this workflow is performed in “nasa.class”, which I am not discussing in this blog as it is easily understandable as shown below.

 

JavaScript Deobfuscation:

To prepare a POC of the exploit, along with the jar file, the html page calling the applet is also important, because it sends the parameters needed for jar execution. But exploit kit landing pages are found to be highly obfuscated and it’s not at all easy to decode the parameters.

In case of Flashpack, we filtered the following traffic:

After deobfuscating the JS and extracting some useful content, we get:

Yara Signature:

Even though the jar files used by EKs have highly obfuscated code, some of the strings still can’t be obfuscated and we can use such patterns in our static analysis. And if we are lucky, we can develop accurate detection methods. The following signature can be used for exploit identification on a decompiled jar file.

- Sameer Patil