My colleague Daniel Novomeský alerted me to a problem he’s observed with the way some web-developers use JavaScript: a few of them have the habit of obfuscating JavaScript code on their web sites, presumably in order to compress it so that it takes less disk-space (“packing”) or using a “protector” in order to make it

My colleague Daniel Novomeský alerted me to a problem he’s observed with the way some web-developers use JavaScript: a few of them have the habit of obfuscating JavaScript code on their web sites, presumably in order to compress it so that it takes less disk-space (“packing”) or using a “protector” in order to make it harder for a competitor to “steal” script code. The problem with this is that the use of this sort of utility to obfuscate code makes it harder for security software to identify known or unknown malware, so JavaScript is commonly obfuscated by malware authors in order to evade or hamper detection.

I spy with my little eye

To the human eye, of course, there’s no dramatic difference between legitimate and malicious scripts if they’re obfuscated. An AV program might easily flag an “innocent” program as malicious because a technology normally associated with malware is being used.

The Greatest Good for the Greatest Number?

When the signature is throttled back so that the presence of the obfuscation software is not flagged as suspicious, it means that the interests of a few developers of poorly-implemented web pages are given priority over the interests of the many people whose systems are threatened by the many sites that serve obfuscator-protected malware. Indeed, malware writers sometimes go out of their way to use “popular” obfuscators in hope they remain undetected, knowing that AV vendors try to avoid detecting legitimate websites, so, increasingly, the vendors are leaning towards a more Utilitarian approach.

The Unwise and Wherefores

Why, you might wonder, would you obfuscate a legitimate script? Well, one cryptor for which we have a specific detection is sometimes used by web developers because they think it gives them good copy protection and imperviousness to reverse engineering. Sadly, this is just giving them a sense of false security. An experienced JavaScript coder is unlikely to have any problem decoding the script to extract the original source code.

In fact, it’s possible for an anti-virus engine to decode a script in real time, in order to assess the malice or innocence of an object more reliably by examing the de-obfuscated script. However, this kind of in-depth analysis takes substantial time and resources, and most users would not regard the processing delay as acceptable.

Some obfuscators can also reduce the size of the JavaScript code, which might be another reason they’re used on legitimate sites. But there is actually a better method of reducing the bandwidth: the webserver can be enabled to use GZIP compression, so that HTTP responses will be compressed, and in fact, the compression ratio is much better this way than is the case with JS packers. However, using a JS packer and server side compression together may be worse from this point of view than using the original script with the server side compression only. As with compression in other contexts, compressing the same object twice or more does not make sense, and may actually result in increasing its size and time taken to load.

Trade(-off) Gap

Given this rich assortment of related problems, it’s hard to see how anyone could continue to recommend the use of protectors, since they don’t necessarily offer much to the developer in the way of protection against patching or reverse engineering to offset their disadvantages.

Pack It In!

As it happens, the IEEE Malware Working Group, of which ESET is a member, has been working for some time with some of the major packer companies on a system for making it possible to blacklist individual (mis)users of the software rather than the software itself. (Vendors with an approach based on whitelisting and/or reputation services may also find approach more useful.)

We hope that this will introduce some significant benefits to companies like Themida, to AV vendors, and (most importantly, some would say!) to the customer, whereas current piecemeal approaches to blacklisting and whitelisting have only limited, short-term effectiveness. Which is why, at present, AV vendors tend to favour a more generic approach that benefits the majority.

David Harley

Daniel Novomeský