Sep 06, 2011

JavaScript Obfuscations Contest: Test Your Skills

by Ricky Lawshae

UPDATE:

In this post, I’m going to tell you more about how we obfuscate JavaScript, which lets you test the ability of your network defenses to detect those attacks. And to make it more exciting, I’m going to make this a contest and give you a chance to win an iPad simply for demonstrating your own de-obfuscation chops.

More and more often, attackers are using techniques like the ones described here to confuse analysts, slip past defenses, and otherwise avoid detection. Especially with regard to Web browsers, where the attack surface is broadening by the day, it’s vital that you test your defenses against these types of tactics to ensure that you won’t fall victim.

In part 1, we discussed a few of the new JavaScript obfuscation techniques that we have recently implemented in the BreakingPoint CTM, and we touched on the futility of signature-based detection of malicious JavaScript code. I also promised that those techniques were only the beginning of how evil we — and real-world attackers — can be. So now I’m here to deliver on that promise. In addition to code obfuscation, we have added a couple of different JavaScript encoding options. One of them is Huffman encoding, which we can save for another day. The other is XOR encoding, which is the subject of this post.

XOR Xplained

One method that is often used for dealing with the problem of obfuscated JavaScript code is to run it through a JavaScript virtual machine and analyze its behavior there. But what if the script is encoded and will only properly decode once it is loaded in the correct target environment? Our XOR encoder attempts to do just that.

“Exclusive OR,” otherwise known as XOR, is a mathematical operation that essentially amounts to two things being mutually exclusive of each other (see the XOR Wikipedia page for a more detailed explanation). For encoding purposes, it can be put simply as:

plain_text XOR passphrase = encoded_text, and
encoded_text XOR passphrase = plain_text.

In other words, you can encode your text by XORing it with a passphrase, and you can decode it by XORing the encoded version with that same passphrase.

When you turn on our new XOR encoding option, it takes the JavaScript code in a particular attack, passes it through our obfuscator, and XOR encodes the obfuscated JavaScript using a random string of characters as the passphrase.

This immediately raises a question: how do we supply the correct passphrase to the victim’s browser so it can decode and run our script, while still obscuring the passphrase from anyone trying to analyze it? The answer is that we perform user-agent detection and return a different random string of characters for each possible browser type. Only the detection of the correct user-agent will return the random string of characters that properly decodes the script. And, of course, we pass the encoded version of the JavaScript back through the obfuscator once more.

Your Challenge: De-Obfuscate This!

What we end up with is a block of code like the one that follows. Since the block of code is so long, we’ve put it in a separate .txt file for you. If you want to take up the challenge of de-obfuscating it, just access the file so you can copy-and-paste the whole thing.

So that’s your challenge: take the code, analyze it, and de-obfuscate it, if you can. By the way, the code is for an actual known and documented vulnerability. If you can figure out which vulnerability it is, just email its CVE number to blog@breakingpoint.com. Everyone who responds correctly by September 14 at 5 p.m. CT will be entered in the drawing for the iPad.

Also, feel free to share your best de-obfuscation techniques and tips in the comments section below. Good luck!

Related Posts:

Tags: