High Performance Network Security, Enterprise and Data-Center Firewall

High Performance Network Security, Enterprise and Data-Center Firewall

Malicious Javascript Obfuscation: Divide et impera!

by RSS David Maciejak  |  March 04, 2009  |  Category: Security Research

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? ;)

by RSS David Maciejak  |  March 04, 2009  |  Category: Security Research
comments powered by Disqus

FortiGuard Labs on the Web

search results hidden links