Automated JavaScript Deobfuscation - PacSec 2007

Spiffy:
Automated
JavaScript Deobfuscation
Stephan Chenette Alex Rice
Principle Security Researcher Sr. Security Researcher

Malcode analysis
 Current malcode research is focused on binary analysis.

 Multiple tools to assist researchers in analysis.
 IDA
 OllyDbg

 Fact: More delivery of malware is moving to the web.

 A new set of skills and tools are required.

What you know…
What you need to know…
 Malicious binary analysis
 Languages: Assembly, C, C++, vb, delphi, etc.
 Concepts: PE file format, win32 function usage, unpacking, anti-
disassembling tricks, etc.
 Tools: IDA, OllyDbg, PEiD, Imprec

 Malicious web content analysis
 Languages: (D)HTML, VBScript, JavaScript, Perl/Python/Ruby
 Concepts: HTTP Protocol, XMLHTTPRequest, Document Object
Model (DOM), Browser Security Models, JSON,
 Tools: ???

Those Who Forget History Are
Doomed to Repeat It
 Malcode authors will protect malicious web content the
same way they protected malicious binaries.

 Signature evasion
 Anti-analysis techniques
 Pain in the #*&#$! for all researchers!!

Unpacking and anti-debugging
 Packing/Protecting/Anti-reversing
 Compression, Encryption, CRC protection
 Anti-debugging
 Virtualization detection
 Anti-emulation
 XOR stubs

Obfuscation Evolution
 String splitting:
 “AD” + “ODB.S” + “treAM”
 String encoding/escaping:
 “%41u0044” + “Ox44%42u002ES” + “t%72eAM”
 Closing html tags (e.g. </TEXTAREA>)
 Code length dependant obfuscation:
 arguments.callee.toString()
 Server-side [poly|meta]-morphic obfuscation

Our Approach
 Emulation: a browser without a browser…
 HTML Parser
 DOM Implementation
 Scripting Engine(s)/Interpreter(s)
 Allow the page to decode itself
 Don’t render content, just log everything!

HTML Parser
 The first step in emulating a browser: HTML.

 Retrieve all the content needed by the page:
external SCRIPTs, IFRAMEs, etc.

 Side effect – basic HTML obfuscation is defeated:
 <iframe src=“http
://%77%77%77%2E%74….

A Little DOM, Please
 Modern browsers are dynamic, so our emulator
must also be.

 Implement Document Object Model

 Attempting to detect all instances of an element by
simply parsing static HTML is not enough….
 createElement(‘IFRAME’);

Coming At You Like A Spider Monkey
 Integrate scripting engine(s) with our DOM to
execute scripts as they are discovered

 Scripts are [mostly] safe for execution

 Firefox’s SpiderMonkey JavaScript Engine
(MPL/GPL/LGPL)

The Missing Pieces
 Implement all of the objects/functions that the
browser provides:
Native JavaScript Browser Supplied
eval() alert()
String.fromCharCode() document.write()
escape() location.href
Math.random() window.status

 Few internal tweaks to mimic JScript (IE)
 e.g., arguments.callee.toString()

Automated JavaScript Deobfuscation - PacSec 2007

Automated Usage
 Integrated with our miners
 Lots and lots of tuning … (Dec ’06)

 100,000,000+ URLs analyzed every 24 hrs

 Even after the initial decoding, string matching is still
futile: “AD” + “ODB.S” + “treAM”

New Technique, New Signatures
 Detect specific DOM element + attribute combinations
1. New <OBJECT> created
2. <OBJECT>.classid = “BD96C556-65A3….”
3. <OBJECT>.CreateObject(“adodb.stream”)

 Can still match “old fashion” signatures *inside*
document.write() and eval() calls

24 Hours – 111M URLs
124,232 Infected (0.11%)

Limitations – JavaScript Only?
 Other Languages?
 Same concepts apply!
 VBScript
 vbscript.dll under WinE!
 Currently working on experimental version
 ActionScript
 Partially implemented when Adobe open sourced
the engine; now part of Mozilla’s Tamarin Project

Limitations – variable is not defined!
 Attackers can potentially use intentional errors to
prevent code execution
 Identical input/output is very important
 Easy: document.width
 Hard: window.open()
 Really hard: XMLHTTPRequest
 Centralized verbose error logging!

Limitations – Denial of Service
 JS_SetBranchCallback
 Look familiar?

 Separate thread monitoring execution time

Limitations – User Interaction
 Malicious code could potentially rely upon a user’s
action before execution begins
 We implemented some basic event handling:
 body – onload
 window – focus
 document – onmouse___
 Not foolproof!

CaffeineMonkey
 Ben Feinstein & Daniel Peck @ SecureWorks
 Released Open Source
 Excellent tool for manual reverse engineering of
obfuscation; needs HTML/DOM!
 Promising research that attempts to identify malicious
activity based on behavior, not static signatures.
 http://secureworks.com/research/tools/caffeinemonkey.html

Other Resources
 Tutorials from ISC, excellent starting point
 http://handlers.sans.org/dwesemann/decode/

 Jose Nazario’s CanSecWest presentation
 http://www.cansecwest.com/slides07/csw07-nazario.pdf

 Websense Blogs
 http://www.websense.com/securitylabs/blog/blog.php?BlogID=86

The End
Stephan Chenette Alex Rice
Principle Security Researcher Sr .Security Researcher
schenette || websense com arice || websense com

Automated JavaScript Deobfuscation - PacSec 2007

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Automated JavaScript Deobfuscation - PacSec 2007 (20)

More from Stephan Chenette (11)

Automated JavaScript Deobfuscation - PacSec 2007