Exploring The Java Vulnerability (CVE-2013-2465) Used In The Fiesta EK

While going through our daily analysis this month, we came across several Fiesta Exploit Kit attacks. Although this EK first emerged in August 2013, the authors have constantly updated their exploitation code to evade detection. It mostly targets known vulnerabilities in Java and Microsoft Silverlight for exploitation. We identified a .jar file attached to a FiestaEK landing page and on performing some manual code analysis, found it to be exploiting the CVE-2013-2465Java vulnerability.

There isn’t much detail available regarding how the exploit actually occurs, so we really wanted to walk through each step of the attack and explain each step in detail. The code as you will see is constructed in a way to avoid static detection using string searches or Yara scans.

 

MD5 hash: ed2e61b302c6ed7ccb3699cc33d23f71

VirusTotal report: 16/54

 

The malicious jar file can also be downloaded from here (hxxp://www.malware-traffic-analysis.net/2014/06/07/2014-06-07-Fiesta-EK-malware.zip). It contains the following six classes. 

 

 

 

 

 

The malware author tries to complicate the program by constructing strings using String.replace(). For eg: 

 

 

 

 

 

Here, lies() replaces the substring “un6u4vy46” with “e” in all places present in the 1^st parameter to form “createWritableRaster”. Even the random class and method names and the scattered code makes analyzing the code a challenge.

 

The execution of the .jar file is triggered from a compromised website. The execution starts through the entry point “sash0k.start()” method with a long string parameter which it gets from the host site itself. URL domains are extracted from this string and stored in an array. Malware will connect to these domains and download actual malware executables after the machine has been successfully compromised. Let’s look at each step in detail.

Initially, the code creates two BufferedImage objects in two different ways. Let’s have a look on both.

 

Reflection(Java.lang.reflect) is used to invoke the setPixel() method present in the java.awt.image.CreateWritableRaster class using an object of BufferedImage subclass of the java.awt.image package. An integer type object is then passed to set the Raster values. The returned object is typecast to BufferedImage type and is stored as localBufferedImage1.

The second object is created by passing an object of the ComponentColorModel class to its parameterized constructor.

 

An important thing to note is that this ComponentColorModel object is created by passing an object of ICC_ Colorspace constructed from an ICC_Profile instance.

The SampleModel used in this case is the MultiPixelPackedSampleModel which has an interesting feature of writing the DataBuffer in the image. To be clear, these two objects are different from each other. Many image related classes are used in this code, but the only goal is to capture the flag!

The actual exploitation occurs when the AffineTransformOp.filter() method is called with the two BufferedImage objects as parameters. It is supposed to perform a linear mapping from 2D coordinates in the source Raster to 2D coordinates in the destination Raster.

 

 

But before initiating the transformation, the ColorSpace compatibility is checked through the isCompatibleRaster() method of class “java.awt.image.ColorModel”. This method becomes vulnerable because code bypasses this compatibility check to always return “True” by overriding it in a base class, which is Class “tiel3k” in our case. The destination raster memory array is then overflown resulting in heap corruption.

 

This vulnerability is thus named as the “Incorrect image channel verification” vulnerability.

Because the .jar runs as applet in user’s browser, the code must use SecurityManager and get required permissions to perform privileged actions like creating and executing files in memory in our case.  As we can guess, the destination of the overflow is in the heap region of localBufferedImage2 and the above access permissions are given only to this object. Fields of volatile data types are created to allocate memory and write data in it. If we go more deeper in the code, we see that 8192 bytes (8Kb) memory was reserved for localBufferedImage2 object (assuming a 4 byte Integer).

 

Now since the code has bypassed the Java sandbox protections of a browser, it’s ready to perform some privileged actions like file download and execution on the user machine. The code ultimately connects to various URL domains, downloads .exe files, stores them in the <temp> folder and executes them.

 

Since there has been no Java vulnerabilities reported as of yet in 2014, malware authors are using old exploits and rewriting the code with additional obfuscations. Zscaler provides JavaTestwhich is a free tool for checking the current java version. The best way to stay safe is to regularly update to the current version of Java or to remove it altogether if it isn’t necessary to the machine in question.