Thursday, 30 May 2013

Sakura: AES and Initial Payload URL decoding algorithm changes - May 2013

The information is based on a sample seen on 2013-05-30.

Cipher

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.



Related read:
http://malwageddon.blogspot.com/2013/05/sakura-landing-page-changes-may-2013.html
http://malwageddon.blogspot.com/2013/04/redkit-initial-payload-url-decoding.html

Sakura: Landing page changes - May 2013

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.

PDF no more

There is no PDF infection vector in this sample.

Sunday, 12 May 2013

Sakura: "Cherry blossoms, cherry blossoms" --- Part 2

"Across the spring sky"

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 - '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

Sakura: "Cherry blossoms, cherry blossoms" --- Part 1

The Spring has come

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.


Java bytecode files the exploit execution starts with are different. Malicious JAR file targeted at Java prior to '1.7.11' starts with execution of 'Test.class'. JAR targeted at Java 1.7.11 executed with 'Test.ser'. '.ser' file extension refers to Java Serialization Files. Serialization files represent the state of objects sufficient to reconstruct the objects. Refer to Java Object Serialization Specification for more information.

Before PDF file is requested, number of checks is performed:
  •  browser's plugins array is checked for 'Adobe Acrobat' or 'Adobe PDF' plugin.

  • if plugins are not found, the script will attempt to create a new instance of 'ActiveXObject' called 'AcroPDF.PDF' or 'PDF.PdfCtrl'.

'ActiveXObject' is used to create instances of OLE Automation objects in Internet Explorer. Will not work with any other Internet browsers.
  • if any of the above is successful, the script will create a request for a PDF file. Otherwise, it will not be served.
'document.createElement("embed")' is used for creating a request through 'Firefox' browser


'document.createElement('iframe')' is used for any other types of Internet browsers


"Is it a mist, or clouds?"

 Quick summary for the above:
  • PluginDetect script is used to detect version of Java only
  • Single URL to dish out malicious JAR and PDF files
  • Includes exploit targeted at specific version of Java - 1.7.11
  • Uses Java Object Serialization for Java 1.7.11 infection vector
  • No Adobe Acrobat version check
  • Malicious PDF will be served if either Adobe browser plugin or ActiveXObject is detected
  • Request for PDF file is formed based on Internet browser type

Part 2 covers analysis of malicious JAR file aimed at Java prior to 1.7.11 update.

Saturday, 4 May 2013

Java Security Warning Bypass using JNLP

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.

This flaw is fixed with Java 1.7.21 update.

External sources:
http://immunityproducts.blogspot.com/2013/04/yet-another-java-security-warning-bypass.html
http://security-obscurity.blogspot.no/2013/04/the-latest-java-exploit-with-security.html

Friday, 3 May 2013

RedKit: AES encryption keys change - April 2013

After the update to include the exploit for CVE-2013-2423 the values of AES 'Secret Key' and 'Initialization Vector' variables have also been changed.


RedKit: Initial payload URL decoding algorithm change - March 2013

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".

Update May 2013:

Another 'index' string seen:


'lookup' string stays the same though.