random dross : De-obfuscation

De-obfuscation using a standalone Javascript interpreter

dross — Sat, 09 Dec 2006 03:45:00 GMT

Mark Wodrich forwarded me this Websense blog post describing how to use a standalone Javascript interpreter to de-obfuscate some script. Thanks Mark!

eval() and document.write(), meet Execute and ExecuteGlobal

dross — Fri, 17 Nov 2006 00:35:00 GMT

Be on the lookout for these two VBScript statements that can be used to achieve the same effect as eval() and document.write(): Execute and ExecuteGlobal.

Jonathan Ness pointed me to an exploit sample that was using Execute, presumably to trip up any eval() or document.write() dependent detection logic or automatic de-obfuscation. Thanks JNess!

Recursive Obfuscation

dross — Thu, 05 Oct 2006 22:10:00 GMT

Thanks to Jonathan Ness for pointing me to an example of a new obfuscation technique that attempts to thwart the eval() à alert() trick.

Take a look at the following obfuscation script:

1 <script>
2 function N(F,D)
3 {
4    if (!D) D = ' "#%()-./012348:;<=>@ACEGHILMOPRTVWY\\]_abcdefghijlmnopqrstuvwxyz';
5
6    var f;
7    var V='';
8
9    for (var c=0;c<F.length;c+=arguments.callee.toString().length-380)
10    {
11           f = ( (D.indexOf(F.charAt(c))&255)<<18) |
12                     ((D.indexOf(F.charAt(c+1))&255)<<12) |
13           ((D.indexOf(F.charAt(c+2))&255)<<6) |
14                     (D.indexOf(F.charAt(c+3))&255);
15           V += String.fromCharCode((f&16711680)>>16,(f&65280)>>8,f&255);
16    }
17
18    eval(V);
19 }
20 </script>
21 <script>
22 N('[obfuscated goo v1]')
23 </script>

The first thing you'll notice is code length dependent obfuscation – observe the use of arguments.callee.toString(). You can use the trick I described in my previous blog entry to deal with this.

But what you can’t really see from the script above is that when you alert() instead of eval(), the string you get is:

N('[obfuscated goo v2]')

So it would seem that eval() is necessary in order to execute N() again to continue the de-obfuscation. However, when analyzing any exploit you want to stay away from eval() at all costs to avoid inadvertently executing exploit script that hasn’t been analyzed yet.

So to de-obfuscate this, carefully perform the steps below.

Warning: Executing malicious script without properly neutering it is dangerous. Proceed with caution! Be sure to read the safety guidance here.

Copy the malicious script to a standalone HTML document.
Replace all instances of eval() with pval(), making sure that the obfuscated script block itself doesn’t implement pval(). There is one instance of eval() on line 18 of the example above.
Make sure there are no other extraneous document.write() calls, eval() calls, or anything else that appears to run script or inject script into the DOM.
Drop the definition of pval() at the top of the file:

<script>
function pval(e) { alert(e); }
</script>
Run through the HTML and copy the N('[obfuscated goo v2]') from the alert(). Press Ctrl-C to copy the contents of the alert dialog to the clipboard.
Paste N('[obfuscated goo v2]') over N('[obfuscated goo v1]') on line 22 above.
Go back to step 5 and continue as necessary until the ultimate de-obfuscated script is shown in the alert().

So far I’ve only seen recursion one-level deep so I don’t yet have a need for a more sophisticated solution. If things get out of hand and I start to see multi-pass obfuscation I’ll post a more elegant technique.

High-bit ASCII obfuscation

dross — Mon, 02 Oct 2006 06:28:00 GMT

Here’s another new obfuscation technique I’ve seen in use on malicious web sites recently. Check out the following HTML:

<html><meta http-equiv=content-type content='text/html; charset=us-ascii'></head><body>¼óãòéðô¾áìåòô¨¢Ôèéó éó óïíå ïâæõóãáôåä óãòéðô¡¢©»¼¯óãòéðô¾</body></html>

Those funny characters are actually standard ASCII characters with the high-bit of each byte set. If the high-bit ASCII managed to get posted properly to this blog without getting mangled, you should be able to drop the obfuscated HTML into a file on a web server and observe that browsing to the file results in execution of the following script:

<script>alert("This is some obfuscated script!");</script>

Here’s some quick and dirty C# code that will clear the high-bit of each input byte:

       int char1;
       Char c1;
       FileStream fs = new FileStream([file path], FileMode.Open);
       BinaryReader r = new BinaryReader(fs);

       r.BaseStream.Seek(0, SeekOrigin.Begin);

       while (r.BaseStream.Position < r.BaseStream.Length)
       {
           char1 = r.ReadByte();
           char1 = char1 - 0x80;
           c1 = (Char)char1;
           Console.Write(c1);
       }

Drop this code into a console app and you’ll have a nice de-obfuscator.

This interesting behavior of US-ASCII in IE was noted by Kurt Huwig on BugTraq a few months ago.

Code length dependent obfuscation

dross — Fri, 29 Sep 2006 00:57:00 GMT

Wow, it’s been a long time! Hopefully I can find more time to blog over the next couple of months.

In any event, my paper from last year really could use some updates. Among other things there are a whole new slew of “Usual Suspect” vulnerabilities to document. For this post I’ll focus on documenting an interesting new exploit obfuscation technique I’ve run across recently -- code length dependent obfuscation.

Take a look at this obfuscated script from a malicious web site:

<script>
function x(UW,P)
{
   if(!P)
   {
      P='[obfuscated data]';
   }

   var W;
   var VM='';

   for(var G=0;G<UW.length;G+=arguments.callee.toString().replace(/\s/g,'').length-535)
   {
      W=(P.indexOf(UW.charAt(G))&255)<<18|(P.indexOf(UW.charAt(G+1))&255)<<12|(P.indexOf(UW.charAt(G+2))&255)<<(arguments.callee.toString().replace(/\s/g,'').length-533)|P.indexOf(UW.charAt(G+3))&255;VM+=String.fromCharCode((W&16711680)>>16,(W&65280)>>8,W&255);
   }

   eval(VM.substring(0,VM.length-(arguments.callee.toString().replace(/\s/g,'').length-537)));
}

x('[obfuscated data]');

</script>

Note the use of arguments.callee.toString(). This effectively returns the text of the current script block. The script calculates the length of the text and actually uses this length to produce the correct de-obfuscated script to evaluate.

If you’ve read Analyzing Browser Based Vulnerability Exploitation Incidents then you already know how to replace the “eval()” statement in the script above with an alert() to get the de-obfuscated text without executing it. However as you can probably guess, the technique above defeats this trick because alert() is one character longer than eval().

This isn't hard to circumvent once you know what's going on. Simply change “eval” to “pval” and add the following script block before the primary script block on your test page:

<script>
function pval(e) { alert(e); }
</script>

Just make sure that the obfuscated script block itself doesn’t implement “pval” to try to trip you up!

Tip of the day: Try Prompt(0,[string]) in place of alert([string]). This will allow you to easily copy de-obfuscated data to the clipboard.

Also, Rob Hensing let me know that pressing Ctrl-C on an alert() window will copy the contents of the alert box to the clipboard. Thanks Rob!

Analyzing Browser Based Vulnerability Exploitation Incidents

dross — Mon, 13 Jun 2005 21:44:00 GMT

I've written up a paper that describes some useful tools/techniques for deconstructing web based exploits:

Analyzing Browser Based Vulnerability Exploitation Incidents

The paper started as a blog entry and it remains a blog entry at its core. But since really huge blog entries are uncool (so I hear), and for other logistical reasons, the paper itself is hosted elsewhere. Future research from other members of my team will likely be collected in some central spot, stay tuned...