[Technical Tear Down] Fiesta Exploit Kit – Java Exploit (CVE-2012-0507)

Today, we’re going to look at another exploit that is delivered by the Fiesta Exploit Kit. As usual, the purpose of this post is to provide a technical understanding on how the exploit work. This time it is a JAVA exploit.

This is the link to the fiesta_ek_java_2012_0507 (The .JAR file contained 4 .class files and a .txt file containing the parameters that was passed to the JAVA applet by the launching Javascript). Do note that these are MALICIOUS files, so please run them in a “safe” environment.

[Part 1: Overview]

This exploit uses the CVE-2012-0507 vulnerability. It is a type confusion vulnerability affecting the AtomicReferenceArray class. More information about this vulnerability can be found at these 2 articles ( and ). This exploit will result in a JAVA sandbox escape and allow the attacker to perform privileged actions.

Exploiting type confusion vulnerabilities are very interesting and very different from exploiting overflow/code execution vulnerabilities. In a sense, it is much easier to perform. To fully understand how it works, we must first discuss about the JAVA sandbox.

[Part 2: Java Applets and Sandboxing]

For the full explanation, refer to

In summary, there are 2 types of JAVA applets, Sandbox applets and Privileged applets. As the name suggests, sandbox applets run in a sandbox and have limited access to certain operations. Privileged applets do not have such restrictions but they have to be signed by a recognized CA (Certificate Authority) and the user must give permission to the applet to perform higher privileged operations. Most applets we see are sandbox applets.

The picture below shows some of the restricted operations of sandbox applets.


Take special notes of point #1 (cannot access local filesystem and execute files), #2(cannot connect to third party servers), #4(cannot change security level) and #5 (cannot create classloaders).

[Part 3: The Malicious Applet]

Below is the de-obfuscated Javascript code that is responsible for loading the applet.


The Javascript first checks that the Java version is Java 6u30 or lower. If it is lower than that, it will fetch the applet from the malicious url and start running the code in the “tampi” class. 2 paramters “peso” and “lapp” are also passed along to the applet.

In the following source codes, I have de-obfuscated some of the strings and variable names so as to make your reading easier. Let’s look at the “init” method of the “tampi” class. The “init” method is first called when a Java applet is loaded.


The 2 params that was passed in will be stored into the javaparam_lapp and javaparam_peso variables. Take note of the javaparam_peso which contains a URL link to the malicious server.  I will come back to it later.

Although a sandbox applet cannot create a ClassLoader, it is still able to get a handle to the Applet’s ClassLoader seen on line 17. The “lapp” parameter is the serialized form of an Object[] array. It is decoded by the “foro” method then deserialized by the ObjectInputStream and cast back to its Object[] form on line 19 and 20. The diagram below shows the reconstructed Object[].


The Object[] array contains 2 Objects.

  • preyx[] array containing 1 element (null at this point)
  • AtomicReferenceArray (I shall refer to it as ARA) containing 1 element
    • This is actually the same preyx[] array above, only casted as a ARA object

Line 22 to 24 is a Java Reflection call to set the first element of the ARA object to the classloader that was referenced earlier (Line 25 comment line is the non-reflection way to call the same method).  This means a reference to the Applet’s ClassLoader has been assigned into the preyx[] array. This violates JAVA’s type safety and hence a Type Confusion vulnerability.

Line 27 then calls the “juri” method on the first element of the preyx[] array which contains the ClassLoader now. Let’s look at the “preyx” class and its parent class, “odesh



The preyx class is actually a subclass of the ClassLoader class (See Update #1 for more details).

The “juri” method reads in the “teemb.class” class file and creates a Class object from it with the “defineClass” method on line 16. Take special notice of the last parameter of the method call. This is the “privilege” level to be assigned to this class. An instance of this class is then created on line 17. Let’s look at the “tampi.rous()” method.


The commented block is the non-reflection way to call the same methods. This is a typical JAVA privilege escalation method. It creates a ProtectionDomain which has access to “AllPermissions”. By AllPermissions, I mean ALL permissions. This means the “teemb” class would have access to all operations including file I/O onto the local filesystem, network connections to third party servers and so on. The applet can now perform whatever a normal executable jar file can perform when it is run from the local filesystem.

Let’s look at the “teemb” class now.


The 3 methods “lewd”, “orly” and “callWriteMethod” are helper methods.

  • lewd – some form of decoding function based on xor
  • orly – reads everything from the inputstream into the input byte array and returns the total number of bytes read
  • callWriteMethod – calls the write method of the specified class

The constructor of the “teemb” class calls the “doPrivileged” method which then calls the “run” method below.


Line 53 assigns the malicious URLs in “javaparam_peso” into the arrayOfString variable. For each url in there, the for loop on line 59 is executed. In summary, the for loop perform these operations.

  • Creates the temp file path to store the malicious file
  • Opens a URL stream to the malicious url
  • Read the first 256 bytes from the stream (this is the xor key)
  • If key is read successfully, read in the rest of the stream
  • Decode the rest of the stream with the xor key and store it into the temp file path
  • Use the Runtime class to execute the downloaded file in the temp file path

In gist, this is a Download and Execute code. At this point, the attacker would be able to download any malicious file from the Internet and execute it on the victim’s machine. This defeats all the restriction that was placed on sandbox applets, effectively bypassing the sandbox.

[Update #1]

The purpose of this update is to better explain the role of the vulnerability in this exploit. The original article did not really explain this part clearly.

Earlier in the article, I mentioned that preyx is a subclass of ClassLoader. This means under normal circumstances, the applet would not be able to create a preyx instance (e.g. thru a “new preyx()” call) because sandbox applets are not allowed to create ClassLoaders. CVE-2012-0507 allowed the applet to “smuggle” a reference to a preyx object into the applet’s execution environment without actually creating one.

However, the next question is why is the preyx object important? The answer is privilege escalation. In order to execute malicious operations, a higher privilege level is needed other than the sandbox privilege level. The defineClass method allows the attacker to create a class with a specified “privilege” level (thru the last param of the function call). However, the defineClass is a protected method which means only subclasses of ClassLoader would be able to call it and that is where the preyx class comes in.

To understand this easier, put yourself in the shoes of the exploit writer. The thinking would go something like this.

  • Goal is to run malicious code
  • Need a way to load a class with elevated privilege levels (defineClass method)
  • To call the defineClass method, need a subclass of ClassLoader (preyx class)
  • Normal applet would not allow the creation of a preyx instance, need a way to get a preyx object into the applet environment (CVE-2012-0507 vulnerability)

[End Update #1]

I hope you have gained a better understanding of this exploit. Until next time!!

Glenn (@_graypanda)