Introduction to hostile Java analysis

Java is a powerful platform-independent programming language that is widely used within web applications and mobile media. Fraudsters have abused Java to obfuscate attacks, hinder research and response, and maximize profits. Security experts must have an understanding of common Java-based attacks and their implications in order to best respond to emerging threats in the wild.

The Java programming language was developed by Sun Microsystems and first released in 1995. Its strength is that it is platform independent. As a result, a Java program can be deployed to many operating systems as a standalone solution. For example, a Java program may be authored and placed within a web medium, then be able to be downloaded and run on Windows, Macintosh and Unix machines.

Source files normally have the extension ‘.java’, while compiled Java files use the extension ‘.jar’. JAR files (Java ARchives) are an aggregation of class files and metadata such as images and text used within a Java application. JAR files can be unpacked using tools like WinZip, as they contain a PK header. Security experts analysing hostile JAR files must first unpack the sample and then look to decompile the class files found within the archive. Figure 1 shows the header and class string references found in a JAR file for a hostile exploitation component used within the Eleonore exploit kit.

Figure 1. Hostile JAR file has PK header and strings of interest.

Notice that the meta-info and manifest data exist within the strings of this file. This is also a visual cue for identifying Java content, as JAR files always include both class files and a manifest with metadata.

Java source code is compiled to create what is known as a class file. Class files contain executable content for Java. Class files may also contain multiple files within them, known as inner classes. Security experts researching hostile Java applets (small web applications) look to capture, decompile and analyse code related to all class files found within a hostile JAR file.

Jnana Javabot is a prime example of the advancing nature of malicious Java usage. The code was first reported publicly by Symantec in October 2010 [1]. Jnana Javabot is a new botnet that uses Java as the command and control (C&C) infrastructure, making it platform independent. It already has modular payloads for Windows and Macintosh and could easily be extended to Droid and other platforms of interest.

Jnana Javabot also leverages tactics seen with other former major threats, which clearly indicates that the developers are current and progressive and/or possibly affiliated in some way with these former threats. Like Zlob, Jnana Javabot contains a fake codec trick to spread via Facebook. It also utilizes a complicated domain generation algorithm similar to that seen in Conficker, and unique P2P features reminiscent of the infamous Storm worm.

While Jnana Javabot sets the stage for botnets of the future – including mobile platforms – current threats related to Java primarily include exploitation of Java itself and hostile Java applets.

The Java Runtime Environment (JRE) is one of the most popular targets for criminals to exploit. It has widespread popularity in the underground, and is considered one of the best new vectors of opportunity on machines that might not otherwise be compromised. Multiple new exploits for Java enable criminals to compromise computers of interest that are not patched.

Enterprise networks regularly use older, unpatched versions of Java because of business requirements to run specific legacy versions for compatibility with proprietary solutions. To make matters worse, many of these legacy-based Java solutions run on critical servers with important assets at risk. Such exploitation leads to a variety of possible payloads for the system that is compromised.

Exploitation of JRE is frequently performed through malicious JAR files containing hostile Java applets designed to exploit a vulnerability on the remote computer.

Java applets are small, web-based applications. Instead of having code that is readily visible, such as in JavaScript-based attacks, the code is compiled within a Java file.

An investigation into hostile Java artefacts commonly begins with the capture of a questionable JAR file. Once the JAR file has been properly analysed additional research and response is initiated to better understand the JRE exploit vector or behaviour/intent of the hostile Java attack.

A wealth of applications are available to work with JAR files. One such tool is the Mobilefish Java class decompiler [2]. This free, web-based tool provides an amazing amount of analysis for a submitted file. Simply browse for the file to analyse, complete a CAPTCHA input entry, and click on ‘decompile’. A wealth of related Java information is also available on the Mobilefish site [3], [4].

Some of the easiest WYSIWYG Windows-based GUI tools include Cavajdemo, DJ Java Decompiler (djdec39) and Java Decompiler (JD-GUI). Unlike command-line tools, these offer solid decompiling capabilities along with an organization of functions and/or colour-coding of decompiled scripts.

Figure 2. Cavaj freeware default view.

Figure 3. DJ Java Decompiler default source code view.

Figure 4. Java Decompiler default view.

Cavajdemo requires a set-up program to run and then for the user to locate the installed application in the Program Files directory to run it, but is worth the price of admission: it’s free. DJ Java Decompiler also requires a set-up and is not freeware, but it does include a nice option to switch between source code and byte code views. Java Decompiler (JD-GUI) is the easiest to use, with drag-and-drop functionality and no set-up required, and it is free. It also contains a ‘Save Sources’ menu option for exporting all decompiled scripts.

After loading a class file of interest into Java Decompiler it is easy for the analyst to identify the primary functions of the script indented by the tool automatically (‘Main()’ and ‘init()’ in this example). The analyst may then review the decompiled source code looking for URLs (not often seen in 2010 and later), CLSID (Windows Class Identifier) values possibly related to exploitation vectors, and similar strings of interest. In this example, the strings shown in Figure 5 are found near the bottom of the code.

Figure 5. Strings of interest in questionable JAR and class file.

The text ‘soundbank’ is linked to URL activity. Within the context of malicious code attacks this is a string of significant interest. The first result in an Internet search for ‘soundbank java exploit’ identifies a JRE vulnerability for CVE-2009-3864. When this is looked up on the Mitre website 5 it is clear that the file under analysis probably exploits a JRE vulnerability impacting JDK/JRE 5.0 before update 22 and JDK/JRE before update 17 when a non-English version is used. This information can be cross-checked with other research and response data to better qualify this possible threat vector. Additionally, the exact versions of the software on the possibly compromised machine may be compared to what is known to be vulnerable for this vector of attack.

If the machine is found to be running the software versions that are known to be vulnerable to this exploit vector, additional work may be performed to further qualify the threat, including anti-virus scanning, behavioural tests, and reverse engineering.

In 2008, a hostile iFRAME at hxxp://www.psu.com/poll.php led to a CGI redirection at hxxp://asvsutra.info/ in.cgi?7. This then led to hxxp://liveinternets.com/all/update.php containing two layers of obfuscation leading to nine exploit pages, eight of which were functional at the time of the incident. One of the exploit vectors was an Exploit.Byteverify (MS03-011) attempt via java.php. An analysis of hostile artefacts found on a compromised machine included several class files of interest:

Anti-virus scans of these files led to detection names for ClassLoader (ByteVerify). An analysis of the decompiled code also reveals the same functionality (Figure 6).

Figure 6. Analysis of hostile class files.

A search for the MD5 values of each class file also resulted in a VX Heavens match for a ClassLoader trojan (ByteVerify exploitation), confirming this component of the incident involving Java. This information arms security personnel with at least one component of exposure during the attack. Security teams are then able to identify the method of exploitation to patch and/or harden against it in addition to following up on exploit mitigation and finding other machines that may be vulnerable to the same attack.

Early Java-based threats were simple tricks to move hostile URLs out of JavaScript and HTML-type environments into compiled Java files. Java-based attacks have greatly matured since the early days of exploitation, now frequently including many layers of redirection and obfuscation and the use of many artefacts to hinder research and response. Criminals are also leveraging Java to manage their own platform-independent attacks as well as exploit vulnerable versions of JRE.

Java-based threats have never been more real and likely than they are today, making it essential for all incident response teams to have a good understanding of this threat vector and knowledge of how to perform initial analysis of such attacks. More importantly, all security staff should be prioritizing Java-based security measures, given the widespread exploit vectors available for various versions of JRE and the popularity of this vector amongst criminals exploiting the drive-by vector.