A closer look at encrypted Javascripts

Some of our team members came across an infected website redirecting to an exploit site at fuadrenal.com. As usual, the exploit site returned an obfuscated Javascript.

However, beneath the first layer of obfuscation, there was an implementation of RSA PKCS#1 (Public key cryptography) and a variant of a stream cipher, the alleged RC4.

I’m no crypto expert, but after comparing this RC4-like function with other RC4-based algorithms, it looks like this could be a CipherSaber implementation. Below is a pretty-printed part of the function (comment were added by me):

As already mentioned, the CipherSaber algorithm is based on the stream cipher algorithm RC4. RC4 encrypts its content by xor’ing using a keystream which is derived by a secret key. In CipherSaber, this key is created by appending an initialization vector (IV) to the actual key (as show in the image above).

Now, when the first stage of this script is executed, a 53 bytes secret key is randomly generated and stored in an internal variable called ‘oil’.

Next, the secret key is encrypted using RSA and a public key that is hard coded in the script. The output is converted to a hex-string and used as a parameter for the URL leading to the next stage. The next stages are loaded by calling the appendChild()-function for the document object, and thus preserving the current state of RC4.

On the server side, the hex-string will be decrypted and therefor have access to the randomly generated secret key of CipherSaber. The server then returns a CipherSaber-encrypted script, using the hex-string itself as the IV.

Since the client is preserving the RC4-state, it is able to decrypt the second stage Javascript. This script checks for potentially vulnerable ActiveX-components/plugins in the  client browser. Specifically, it checks the versions for Flash, PDF and MDAC (in my case, using an MSIE user-agent).

The results of the version check is reported back to the server by RSA-encrypting it, and using the resulting hex-string as a part of the next-stage URL. Again, the next stage is loaded by calling the appendChild()-function.

Not surprisingly, the server returns an encrypted chunk of code that needs to be decrypted using CipherSaber. This code contains  suitable exploit code based on the version information gathered from the previous stage.  Finally, if the exploit is successful, an URL parameter is generated by RSA-encrypting a few exploit-parameters, which leads to the malware payload itself.

For a graphical overview of the stages involved, click on the image below:

Obfuscated Javascripts are obviously getting more advanced. In this case, it is very difficult to do an “offline” decryption of the code (e.g. by analyzing pcaps), as the keys are randomly generated and the encryption pretty strong. In addition, the exploit site only accepts a single attempt per ip address (I guess there’s an expiration, though), which doesn’t help the case.

However, these scripts has to be readable to browsers – which means anyone can read them, one way or another :)