Dissecting The CVE-2013-2460 Java Exploit

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.

 

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:

 

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>:

 

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.

 

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.

 

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:

 

 

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:

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 followingtwo 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 performingfile 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.

 

 

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: