Last Updated: 2007-08-02 22:26:39 UTC
by Bojan Zdrnja (Version: 2)
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.
var l = arguments.callee.toString().replace(/\W/g,"").toUpperCa
var failme = 00001;
alert(l.length.toString() + ' Func: ' +l );}
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:
- Safari: 93
- Firefox 2: 94
- Internet Explorer 6 and 7: 98
Daniel’s observations were:
- For some unknown reason Safari ignores “g” from the replace call. Why would they do that is not clear but it looks like a bug to me (“g” is definitely a word character).
- All browsers but Internet Explorer strip leading zeros on integers so they treat variable “failme” as 1 when counting the number of characters; Internet Explorer actually counts 5 characters there.
Couple of readers pointed that Secunia’s article about the vulnerability recommends setting the appropriate kill bit, but it doesn’t list any CLSIDs.
So, here’s the list of CLSIDs that this particular exploit uses, taken directly from the deobfuscated code:
- QuickTime: 02BF25D5-8C17-4B23-BC80-D3488ABDDC6B
- WinZIP: A09AE68F-B14D-43ED-B713-BA413F034904
- SuperBuddy: 189504B8-50D1-4AA8-B4D6-95C8F58A6414
- NCT AudioFile2: 77829F14-D911-40FF-A2F0-D11DB8D6D0BC
I’ve included only CLSIDs for third party application – in order to mitigate vulnerabilities in Internet Explorer make sure that you’re running the latest version with all patches installed (this is much easier to patch than all the third party applications).
New Comments closed for all Diaries older than two(2) weeks
Please send your comments to our Contact Form