Slashdot Mirror
Thwarting New JavaScript Malware Obfuscation
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."
Is it just me or is this way of getting around it mind-blowingly obvious.
The techniques the malware writers are using are quite interesting though, i've never heard of arguments.callee.
I turn off referrer headers for privacy (set network.http.sendRefererHeader to 0 in about:config in Firefox). Now it seems that it can also save me from malware :-).
Why would you want it enabled, anyway?
I'm glad you highlighted that line of the summary. The point of the obfuscation was to slow down analysis of the code and require special tools (SpiderMonkey) that average web users don't have. Here the malware author clearly won. The article author spent hours figuring out a new obfuscation technique and writing an article about it. If there are malware detectors, they have to be updated to detect the new obfuscations.
This is not the traditional DRM argument. No one's trying to decode a video or music file they have legal rights to access. This is a malware arms race: The point IS to hide what's going on, not to lock things down. What's more interesting here, and not even discussed, is the parallel between Javascript malware development and computer viruses. The technique the author uncovered is an adaptation of polymorphic virus concepts into web malware. And while the technique is something many developers could come up with, I haven't heard being used in practice yet, so it's likely a noteworthy step in the arms race.
my blog
See http://www.json.org/js.html
If you're using JSON, you're using eval(). Sure, there are some workarounds that avoid calling the eval() function directly, but in the end, they all eval-uate remote code.
JSON parsers use eval() after checking the JSON string to make sure it's actually a JSON string.
cat http://www.json.org/json2.js | grep eval(
Have you driven a fnord... lately?
You must wait a little bit before using this resource; please try again later.
> I'm glad you highlighted that line of the summary. The point of the obfuscation was to slow down analysis of the code and require special tools (SpiderMonkey) that average web users don't have. Here the malware author clearly won. The article author spent hours figuring out a new obfuscation technique and writing an article about it.
Actually, it looks like they spent more time writing about it than solving it. That 8-line patch isn't exactly complex, and it appears that it'll kill most techniques they can use. Their only hope now is to rely on various variables that won't be present in the interpreter, but there's a limit to how complex those can be.
Also there's the fact that the guy's script was buggy thanks to case sensitivity (he named a file .HTM instead of .htm). But you have a point about them only needing to slow folks down, even though I don't think they're getting slowed down very much compared to all the work going into those obfuscation techniques.
I did a fairly detailed analysis of an instantiation of typical Javascript malware these days.
sigs are a waste of space