Raising the bar: dynamic JavaScript obfuscation

Published: 2007-08-02
Last Updated: 2007-08-02 22:26:39 UTC
by Bojan Zdrnja (Version: 2)
0 comment(s)

Couple of days ago one of our readers, Daniel Kluge, pointed us to a web page with some heavily obfuscated JavaScript code. The operation was typical and consisted of a compromised site that had an obfuscated iframe which pointed to the final web site serving various exploits.

The obfuscation of the iframe was relatively simple but the second stage was more heavily obfuscated with some things we’ve never seen before.

After downloading the JavaScript file it was obvious that all function and variable names are complete random. Further to that, the deobfuscation function used the well known arguments.callee.toString() trick in order to prevent modification of the code (so you just can’t replace the final document.write() call to something else as this will break the deobfuscation function body – attempts such as this one typically throw the function into an endless loop).

The screenshot below shows how the function looked when I first retrieved it.

Obfuscated JavaScript function

Now, what makes this new is that the hosting web site generates this code dynamically! Every time you request this web page it will use completely random names for all variables and functions. As the deobfuscation function uses itself to deobfuscate the input, changing variable and function names even causes the payload information to change. Below you can see the beginning of the JavaScript file for two other subsequent retrievals:

(2nd try)

Obfuscated JavaScript function (2nd try)

(3rd try)

Obfuscated JavaScript function (3rd try)

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.

Browser differences

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:

var o3b522f35=arguments.callee.toString().replace(/\W/g,"").toUpperCase();

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.

After some investigation, Daniel found out that there are other inconsistencies between Internet Explorer and Mozilla when using the arguments.callee.toString() function. You can also test your browser with this bit of JavaScript code:

<script type="text/javascript">
function func(){
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.

This was the main reason why the deobfuscation function failed in Rhino which uses Mozilla’s JavaScript engine (so it stripped leading zeros from variables). Browsers are certainly strange beasts …



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).



0 comment(s)

Targeted at Executives - More Better Business Bureau phish malware

Published: 2007-08-02
Last Updated: 2007-08-02 18:16:47 UTC
by Patrick Nolan (Version: 1)
0 comment(s)

We have information that executive staff at 3 corporations are still being targeted with emails with mailicious attachments that AV vendors are finding hard to identify. The best and ongoing analysis of this highly successful attack is the BBB Phishing Trojan analysis by Joe Stewart of SecureWorks.

The information tends to show the recent attacks started to be detected by AV vendors on 07/31. One of our reports indicates that after the initial malware detection, new and undetected attachment variants were emailed. Malware samples submitted show coverage for at least one sample is still spotty.

One submission email had the following information;

 "This is an automated email that confirms the registration of your complaint case number : CX784486090 filed by your company on 7/29/2007 concerning Online Identity Theft.
   While The Better Bussiness Bureau Online does not resolve individual consumer problems, your complaint helps us investigate fraud, and can lead to law enforcement action.

   ATTACHED you will find a copy of your complaint .Please print and keep this copy for your personal records.
   We use secure socket layer (SSL) encryption to protect the transmission of the information you submit to us when you use our secure online forms.
The information you provided to us is stored securely.

   The form you used to register this complaint is designed to improve public access to the Better Business Bureau of Consumer Protection Consumer Response Center, and is voluntary. Through this form, consumers may electronically register a complaint with the BBB.Under the Paperwork Reduction Act, as amended, an agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number. That number is 382-898.

   Our staff will keep you updated regarding the status of our investigation.

© 2003 Council of Better Business Bureaus, Inc. All Rights Reserved."

One report indicated that downloaded files included winupdate.exe, yhelp.exe
and other temp files McAfee flagged as PWS-FireMing.dll, McAfee's PWS-FireMing.dll write-up has no information.

File names are not reliable in many situations, but Sunbelt had a file named yhelp.dll in a description of recent malware, they listed some downloaded files;

File Traces
%WINDOWS%\ yhelp.dll

There was no other useful information on their site.

One sample's analysis at Virustotal;
File Complaint_158684523.doc received on 08.02.2007 18:22:54 (CET)
Result: 10/32 (31.25%)

Antivirus Version Last Update Result
AhnLab-V3 2007.8.3.0 2007.08.02 -
AntiVir 2007.08.02 TR/Dldr.Agent.caa.2 Authentium 4.93.8
2007.08.02 W32/Dropper.GGD Avast 4.7.1029.0 2007.08.02 - AVG
2007.08.02 - BitDefender 7.2 2007.08.02
CAT-QuickHeal 9.00 2007.08.01 -
ClamAV 0.91 2007.08.02 -
DrWeb 4.33 2007.08.02 -
eSafe 2007.07.31 -
eTrust-Vet 31.1.5026 2007.08.02 -
Ewido 4.0 2007.08.02 -
FileAdvisor 1 2007.08.02 -
Fortinet 2007.08.02 -
F-Prot 2007.08.02 W32/SecRisk-ProcessPatcher-Sml-based!Maximus
F-Secure 6.70.13030.0 2007.08.02 Trojan-Downloader.Win32.Agent.caa
Ikarus T3.1.1.8 2007.08.02 Trojan-Downloader.Win32.Agent.caa Kaspersky 2007.08.02 Trojan-Downloader.Win32.Agent.caa McAfee 5088
2007.08.01 - Microsoft 1.2704 2007.08.02 -
NOD32v2 2433 2007.08.02 -
Norman 5.80.02 2007.08.02 -
Panda 2007.08.02 Suspicious file
Prevx1 V2 2007.08.02 -
Rising 2007.08.02 -
Sophos 4.19.0 2007.08.01 -
Sunbelt 2.2.907.0 2007.08.02 -
Symantec 10 2007.08.02 Trojan.Dropper
TheHacker 2007.08.01 -
VBA32 2007.08.01 -
VirusBuster 4.3.26:9 2007.08.02 -
Webwasher-Gateway 6.0.1 2007.08.02 Trojan.Dldr.Agent.caa.2 Additional
information File size: 34863 bytes
MD5: 134e3045664357da281806fc053076ba
SHA1: 25cfc729de06c88cfcba9a8dfa63b84d6d0c92f1

0 comment(s)

New Tool - BotHunter

Published: 2007-08-02
Last Updated: 2007-08-02 16:52:16 UTC
by Marcus Sachs (Version: 1)
0 comment(s)

Readers, SRI International and Georgia Tech have been working on a pretty cool new tool that will quickly locate bot traffic inside a network.  A government/military version of this software has been in use successfully for about a month, and a public version was made available this week.  BotHunter introduces a new kind of passive network perimeter monitoring scheme, designed to recognize the intrusion and coordination dialog that occurs during a successful malware infection.  It employs a novel dialog-based correlation engine (patent pending), which recognizes the  communication patterns of malware-infected computers within your network perimeter.  BotHunter is available for download at http://www.cyber-ta.org/BotHunter/ and runs under Linux Fedora, SuSE, and Debian distributions.

There is also a highly interactive honeynet using BotHunter run by SRI you should look at.  The URL is http://www.cyber-ta.org/releases/malware-analysis/public/.  They are detecting dozens of new infections each day and this site is very helpful in understanding the behavior of the received malware.  Also, it generates a nice list of potentially evil IP addresses and DNS queries.

For both the BotHunter software and the honeynet SRI would appreciate any feedback on ways to improve them.  Contact details are in the download package and on the website.  This is a publicly funded research project, so there is no charge for the software or the use of the honeynet output, however there is a license agreement you have to agree to.

Marcus H. Sachs
Director, SANS Internet Storm Center

0 comment(s)


Diary Archives