NOTE: Information is based on a sample captured on 2013-06-26
UPDATE: 2013-07-05. This kit appears to be 'Private Exploit Kit'. Thanks to @kafeine for help identifying it and clarifying a few things.
"Born to crawl will never fly"
The following URL pattern has been seen:
The landing page is being transferred 'chuncked' using GZIP as a content encoding method. Chunked Transfer Encoding is supported by HTTP 1.1 standard. Its main feature is to use 'Transfer Encoding' HTTP header instead 'Content Length' one to allow dynamically-generated content to be transferred before knowing the total size of that content. The landing page is being generated 'on-the-fly' based on browser's UA - defines what exploits to include. For example, CVE-2013-1347 will be included only if IE8 is detected, the same goes for IE6,7 and CVE-2006-0003. 'Chunked' transfer also allows to 'hide' the content of the landing page.
The HTML code is unreadable for a human eye.
part of 'chunked' HTML code
HTML page is simply being transferred as a GZIP archive that is automatically processed/extracted by the browser. If the page is reassembled from a PCAP file any archiving tool that supports GZIP can be used to unpack it. Once extracted, it appears to be fairly obfuscated. The following algorithm makes it more readable.
It uses 'indexing' technique where a string of characters is constructed based on a 'character index value' in a predefined string. Character index value is calculated using an algorithm and another predefined string of characters. RedKit EK uses the same technique. The only difference is the algorithm to calculate the 'character index value'.
"Where no one has ever been before... NOT!"
'document.write' is tossed the deobfuscated code that will launch PluginDetect script to check for versions of Java and Adobe Reader installed.
There is no code branch when Adobe Reader is detected(work in progress?), but there are three branches for when Java is detected.
- first branch is for Java 6 version 1.6.27 and lower
- second branch is for Java 6 version between 1.6.28 and 1.6.41
- third branch is for Java 7 version 1.7.17 and lower
Taken code branch will create a new <applet> element and append it to the main 'document'.
<applet> sample for a Java 6 branch
There is some simple obfuscation applied on the strings holding the URL location for the JAR file and the parameter passed to JVM. There isn't any fancy algorithm used to deobfuscate them - they are simply 'reversed' and '#' character is removed.
Since JNLP file for Java 7 branch is enclosed into <applet>, it's encoded with Base64. After using Kahu Security's Converter tool, decoded JNLP file reveals the JAR file and additional parameter details.
Sense of humor or pure overlook by authors, but applet's name might make you smile.
"Jam in a JAR"
NOTE: The malicious JAR file details outlined below are for Java 6 '1.6.27 and lower'.
The JAR file contains only 1 class file that is armed with an exploit code for CVE-2011-3544 - 'Oracle Java Applet Rhino Script Engine RCE'. Rhino is a JavaScript implementation that has a way of interacting with Java code when executed within an applet. Doing some crafty manipulations with 'this' object, 'toString' method and Java error handling it's possible to disable Java Security Manager. Michael 'mihi' Schierl explains this vulnerability in great detail in one of his posts.
Decompiled Java code is not obfuscated - at most the values of the string variables are reversed and in some cases padded with a simple pattern.
Reflection methods are used for the exploit part.
'str7' in the snippet above hold the JavaScript that sets the Security Manager to 'null' - disabling it.
assembled JavaScript
JavaScript calls 'start()' method that will identify user's Temp folder location, generate a random filename for the initial payload, download and execute it.
'C:\Users\user\AppData\Local\Temp\3fef61ce8112d381.exe'
filename and location example
"Summary"
In overall, this exploit kit is relatively simple. Judging by the incomplete parts, some naming through the landing page, JNLP and Java code the authors are still working on it. Major points to note:
- uses relatively unique URL pattern
- landing page is transferred 'chuncked'
- landing page is dynamically generated depending on browser's UA
- uses 2 layers of obfuscation to hide the content of the landing page
- utilizes 'PluginDetect' script to identify versions of 'Adobe Reader' and 'Java'
- currently has no Adobe Reader infection vector, but has an empty code branch for it
- armed with 3 malicious JAR files for different Java versions
- employs JNLP technology for Java 7 exploit
- armed with an exploit for CVE-2011-3544 for Java 6 1.6.27 and lower
- uses user's 'Temp' folder to store the Initial Payload
- Initial Payload filename is randomly generated
Recommended read:
http://en.wikipedia.org/wiki/Chunked_transfer_encoding
http://schierlm.users.sourceforge.net/CVE-2011-3544.html
http://malware.dontneedcoffee.com/2013/07/pep-new-bep.html
No comments:
Post a Comment