Pages

Thursday, 30 May 2013

New values for AES 'Secret Key' and 'Initialization Vector' variables.

Decoding algorithm

Initial Payload URL decoding algorithm has changed and now is exactly the same RedKit is using. One of the parameters on the landing page holds a string of characters that is being used to look up characters from yet another string to build the URL.

Using the characters in the parameter called 'param', the Initial Payload URL is assembled with the following code:

What's interesting to note, the variables names('c','o','url') used within the method match with the ones used in RedKit. Tsk-tsk, copyright infringement.

The details are based on a sample seen on 2013-05-30. Credits to @Set_Abominae for sharing the sample.

URL pattern

GET requests are going over port 443, but are not using SSL. The pattern is almost the same as in previously seen sample with the exception to the initial payload GET request. It uses '.rar' file extension.

Encoded landing page

Landing page undergone some changes to hide the code that retrieves malicious JAR file and checks the version of Java installed. The 'hidden' code is stored within a <div> tag.

The following code 'unescapes' and decodes the character string.

The 'cipher' used to decode the string

Decoded landing page

Familiar code execution logic is revealed after the landing page is decoded. PluginDetect script is initialized to check for Java version and based on the findings a request to malicious JAR file is formed.

For Java 7 below 1.7.18 update, the malicious JAR will be requested using JNLP to bypass Java Security Warning window. For all other Java versions, the JAR will be requested directly.

Sakura & JNLP

Sakura went a bit further than some other EKs in employing JNLP by embedding it into an <applet> tag. Doing so allows to use Base64 encoding to 'hide' the content of the file.

Decoded JNLP file

More details on JNLP and 'performSSVValidation' flaw can be found here.

Sunday, 12 May 2013

Part 1 covered a sample of Sakura exploit kit landing page. Part 2 covers analysis of malicious JAR file targeted at Java prior to 1.7.11 update. This particular sample shares a great similarity with RedKit code I analyzed previously. Sakura, though, seems to be attempting to avoid detection through the use of Java Reflection for the parts of the code that changes execution permissions. Recommended read on the subject - @SecObscurity's research/testing into AV avoidance.

In general, Sakura code can be broken into the following parts:

Exploit code

Initial payload URL decoder

Initial payload fetcher

AES decryption code

Filename generator

Storing and Execution code

Hard to tell what came out first: Sakura or Redkit, but it looks like one is a copy of the other.

NOTE: Code obfuscation changes variable, function, class
file names as well as code execution flow. Names and code execution flow
analyzed in this sample is different from other instances of Sakura,
though the basics stay the same.

"Fragrant in the morning sun."

Execution starts with an exploit for CVE-2012-1723. Specially crafted method creates a condition called 'type confusion' and combines it with ClassLoader to instantiate a class object with elevated privileges. Article by Michael 'mihi' Schierl explains this vulnerability in great details.

Core code of CVE-2012-1723 in this Sakura sample:

Granting 'AllPermission' using Reflection methods:

Creating a new 'ProtectionDomain' using Reflection methods:

Passing control to 'Chie.class' to do the rest of the dirty work:

Setting 'SecurityManager' to 'null' using Reflection methods:

At this stage the code is running without any restrictions.

"In fields and villages"

Following successful exploitation, string of characters held in one of the parameters on the landing page is converted into Initial Payload URL. The algorithm for conversion is identical to the one used in RedKit strains prior to March 2013. It can be broken down into the following steps:

The order of the characters is reversed (last --> first, 2nd last --> 2nd, etc.)

'Padding pattern' is removed from the string

Every 3rd character is taken and stored in a new string

Implementation of this algorithm in Sakura is slightly different. It also uses different 'padding' pattern.

Reversing the characters order and removing the 'padding' pattern:

Constructing URL by storing every 3rd character in a new String

The decoded string is passed to Initial Payload fetcher.

"Flowers in full bloom."

Fetcher is a quite standard Java code for receiving a data stream over HTTP.

The encrypted payload was delivered as 'application/octet-stream' with filename 'pixz.gif'

Received stream is converted to a 'byte []' and passed to AES decryption module.

"As far as you can see."

AES decryption module is also a quite standard piece of Java code for decrypting a byte array using a cypher generated from predefined 'Secret Key' and 'Initialization Vector' values.

'Secret Key' and 'Initialization Vector' values:

Decrypted byte array is passed to a method that saves it into a file:

Before the array is saved into Java Temp folder, a filename is generated with the following algorithm:

The filename is 6 characters long and made up of random letters from 'a' to 'z'.

"Come now, come now,
Let's look, at last!"

The final touch is the Initial Payload execution.

Summary: In overall it's a straight forward execution logic. In some way Sakura looks like a simplified version of Redkit even though it attempts to use some evasion techniques. The following are the key points of this particular sample of Sakura Exploit kit:

Initial Payload URL is encoded and stored in <applet> tag on the landing page

Uses Java and Adobe infection vectors

Has a specific Java JAR file aimed at Java 1.7.11

Attempts to exploit CVE-2012-1723

Uses Java Reflection methods in attempt to avoid being detected by AV software

Initial Payload is encrypted with AES

Delivers only 1 Initial Payload

Generates a filename consisting of 6 random characters from 'a' to 'z'

The Initial Payload is stored in Java Temp folder

The Initial Payload delivered by this sample was only 10/43 on VT at the time and classified as 'Trojan-Ransom.Win32.Foreign.bdjk'(Kaspersky)

Saturday, 11 May 2013

I fished out this sample of Sakura Exploit Kit in early April 2013. As in every EK, all starts with a landing page. What immediately stands out is a non-standard port used for HTTP. In this particular sample, port 84 was used. HTTP GET requests follow the same pattern as per MalwareSigs post .

The landing page is armed with PluginDetect 0.8.0 script that detects the version of Java RE. The code sitting on top of the script steers the execution flow depending on the version detected. Malicious applet requesting the JAR file is selected based on the following logic:

Java infection vector will not be used if Java 7 version higher than '1.7.11' is present - the script will exit displaying "Page not found" message. If Java 7 version is '1.7.11' then applet stored in 'sher' variable will be executed. For other Java RE versions applet stored in 'bewryh' variable will be used.

The variables are padded with 'ABC' pattern that is removed with JS regex command once applet is called. The GET requests for malicious JAR and PDF files are sent to 'motherother.php'. Java version number in the 'User Agent' string is used by the server to determine what JAR file to serve(for Java 1.7.11 or lower). For any other 'User Agent' strings a malicious PDF file is served.

Saturday, 4 May 2013

A flaw exist in Java 'performSSVValidation' method that if combined with JNLP will allow to launch an unsigned Java applet bypassing Security Warning pop-up window. There is undocumented parameter the flawed method accepts and if set to 'true' will instruct Java not to perform applet's signature check.

Sample of specially crafted JNLP file:

<resources> tag contains the name of the JAR file to launch followed by 'applet-desc' pointing at the class file to start the execution with. Setting parameter '__applet_ssv_validated' to 'true' allows for Security Warning window bypass.

The exploit kit has undergone some changes in March 2013. One of them is the algorithm for decoding initial payload URL. There is no longer a 'padding pattern' or a character order change. The parameter value that holds the encoded URL is now much shorter.

In the sample above the value of parameter 'name' represents the new format for the encoded URL. The characters in the string serve as indexes for other string 'buried' in RedKit Java code to look up the characters from yet another 'buried' string. See the code below to make more sense from the previous sentence.

The 'index' and 'lookup' strings seem to stay the same across RedKit samples seen since March 2013. The parameter value holding the encoded URL starts with "u33&299".