The obfuscation of the iframe was relatively simple but the second stage was more heavily obfuscated with some things we’ve never seen before.
The screenshot below shows how the function looked when I first retrieved it.
The reason for doing this is obvious, such heavy obfuscation makes signature based detection much more difficult, if not impossible and it wasn’t surprising to see that 0 anti-virus programs detected this when tested on VirusTotal.
After deobfuscating the payload I found out that it contains the typical set of exploits: the ADODB vulnerability exploit (MS06-014), the QuickTime and WinZIP exploits, AOL SB.SuperBuddy.1, WebViewFolderIcon and the VML Element Integer Overflow . Finally, one new addition is the exploit for the NCTAudioFile2 ActiveX vulnerability (http://secunia.com/secunia_research/2007-2/advisory). While this is an old vulnerability dating from January 2007, a fully working exploit was publicly released in April and what’s worse is that the affected ActiveX control is delivered with dozens(!!!) of popular audio/video applications. This is shifting the patching process from the base OS to client applications which is usually much more difficult for users, especially if those applications don’t support automatic updates so it’s left up to the user to first find out that he has a vulnerable application and then manually patch it.
Now back to the infamous arguments.callee.toString() function. For those of you who regularly read our diaries, you probably remember that I analyzed a similar obfuscation method back July 2006 (http://isc.sans.org/diary.html?storyid=1519). The obfuscation function back there just used the length parameter to see if anything has been changed (obviously, changing the document.write() call to alert() or something similar will change the function body length as well). I found out that Internet Explorer and Mozilla treat white space differently and this caused the exploit to fail in Mozilla.
Daniel had problems deobfuscating this function initially and the reason why that happened wasn’t clear immediately because the deobfuscation function in this case does this:
this call converts the function body to upper case and then strips all white space (\W matches all non-word characters) so the fact that Internet Explorer and Mozilla don’t calculate white space the same can’t matter here.
However, Daniel used Rhino while debugging it while I was playing with Windows debugging capabilities so we knew it had to be something related to the browser wars again.
This is a simple test – it calls the same function as the deobfuscation code and just declares one variable called failme with the value of 00001. If you want to test this, go to http://handlers.sans.org/bzdrnja/test.html.
Different browsers and different results:
Daniel’s observations were:
Aug 2nd 2007
9 years ago