Diving into recent 0day Javascript obfuscations

Introduction

One of the most common ways for an attacker to infect system over the Internet is using Javascript. Typical Web exploitation frameworks like Blackhole utilize polimorphic Javascript as a personalized payloads for every victim. By employing various obfuscations they are able to evade static signatures and reduce anti-virus detection rates.

In this post we will analyze one of such Javascript obfuscators called Dadong's JSXX that was used to obfuscate the payload of a recent Java 0day (CVE-2012-4681) exploit that was found in the wild and has since been patched by Oracle and it is recommended that you apply the security patch to ensure maximum protection.
DefenseCode BlackTitan Internet Security customers are protected from described exploit with BlackTitan malware signatures BTSIG9612, BTSIG9613 and BTSIG9615.

Analysis of Dadong JSXX obfuscated payload

Let's first take a look at the fully obfuscated JavaScript code that is generated by the attacker. The following code is generated by the attacker for each visit of the web page serving the exploit which is then responsible for exploiting Java vulnerability and installing malicious software:

First thing we can notice is that this code was not designed to be easy to understand and analyze. In fact it is designed to thwart static analysis and automated deobfuscation tools so that it can stay undetected longer.

While looking at the obfuscated code several things become obvious:

• Code alignment and flow structure is not preserved
• Original variable and function names are replaced by random strings
• Various additional obfuscations introduced to additionally deter analysis

To get a better understanding of the code we will tackle all of the mentioned observations in a attempt to fully understand it.

Recovering code alignment and flow structure

Most development editors and environments have basic code prettify functionality that will allow you to format code into a more readable structure. Malzilla is described as a "malware hunting tool" and has ability to format obfuscated javascript code into a much nicer layout. Some manual formatting or regex replacements may be necessary to do some final touches on the formatted code until we are fully satisfied with the results. After we are satisfied with the code layout we can proceed to the next step.

Recovering function and variable names

While analyzing the code we uncover semantics of functions and variables and should rename them as we advance trough the code. Every new renamed variable/function will speed up further analysis and reduce the time to cover all the code. Names should be concise and have clear meaning associated with them so all subsequent encounters of that variable/function are quickly recognized and can be skipped.

Following is an example of code before and after renaming process.

Obfuscated code:

Renamed code:

Common JavaScript obfuscations

After code has been properly formatted we can see additional obfuscations introduced to the code. Let's now examine common JavaScript obfuscations on this sample.

Hiding use of eval()

One of the most commonly used JavaScript obfuscations is using eval() function to run code stored as a string in a variable. This obfuscator is no different and uses several different eval() obfuscations.

To hide uses of eval() the code will assign function to various randomly named variables in an attempt to disguise eval usage. The following code snippet shows several steps used to hide eval() from static analysis.

This technique of hiding functions is not reserved just for eval() but it is typically used to obfuscate usage of all functions that could be used to statically identify malicious code.

Slightly more advanced example of assigning eval to a variable is use using string transformations to build eval string. One such example is inserting junk characters in between eval letters and then removing them dynamically with regular expressions. With this simple rule it is possible to generate polymorphic eval assignments.

Previous expression will remove all characters from the string except those listed in the regular expression, which is equivalent to the following:

eval2=eval('eval');

Opaque predicates

Opaque predicate is defined as an expression for which outcome is predetermined to be always true or false. Most simple example of this is expression if( true ). Malware authors use opaque predicates to thwart static analysis tools by constructing expressions that are not so simple to determine without evaluating them inside the targeted environment. Dadong JSXX uses mathematical functions to build opaque predicates which are then used as arguments in loops. Let's examine one of the expressions used as opaque predicate:

We can divide the expression into groups and evaluate each of the logical expressions:

Inserting the results into original expression we have:

~(0 | ( 1 | 0 & 0)) = ~( 0 | 1 ) = ~1 = 0

So the previous complicated expression will always evaluate to 0 and can effectively be rewritten as:

fExpression_eq0 = 0;

Chaining multiple opaque predicates in different variables makes it harder to statically determine what actually is an opaque predicate and what is a non-reducible expression.

Self-referencing decryption

One very interesting method against code formatting is using self referencing decryption. Let's examine the following code snippet:

Rewritten for easier understanding:

aCodeAsString, originally named sBtEp6, is referencing itself inside the string that is evaluated so any modification or formatting of the aCodeAsString will result in unsuccessful decryption of the final payload effectively preventing any modifications to the code.

Encrypted code

All the previous obfuscations serve to make the static decryption of the final malicious payload hard. Variable vlWWlBt3 from the original obfuscated snippet contains hex encoded encrypted JavaScript code. As the decryption algorithm has to be contained in the script previous obfuscations make sure that detection and analysis of the algorithms are complicated. Encryption algorithms is XOR based where the decryption key is generated from the self-referencing string so it implement simple type of tamper-proof protection. Decrypted code is then simply evaluated by eval() and executed inside the browser.

Final functionality contains the malicious payload that will launch the Java exploit and install malware on the compromised system.

Summary

JavaScript language with it's loose syntax offers variety of ways for the attackers to generate polymorphic wrappers for the malicious payload which effectively hinders traditional anti-malware signatures. By understanding techniques employed by the malware authors we can provide the best protection to our customers with BlackTitan Internet Security.