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.
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)
This is too much, now we all will have to download a pre validator for javascript to view the code (what does this code do, i can't read this, I am an 80 year old grandmother...) before going to the webpage and view it...sucks to go on the web these days!
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
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?
It seems that malware writers still haven't internalized the lesson of DRM â" if my computer can access something in plaintext, I can too.
The malware writers don't need a 100% success rate. They are simply tring to get their software on enough machines to build a nice bot empire.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
stop all that with an 8-line patch to SpiderMonkey
Cool, and now malware engineers will lose their jobs, you insensitive clods! Internet Explorer to the rescue!
Comment removed based on user account deletion
This is not a detection method. It is merely an aid in reverse engineering, once you have found some malware that you want to analyze.
Ouch, I didn't realize how common this was. Feel free to moderate the grandparent post into oblivion.
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
But they update their diary every day, which means for the most part, it's totally boring crap.
Welcome to my slashdot journal (NSFW)
they're a bit old in the tooth now
Piece of cake, easy as pie. The saying is "long in the tooth", comrad.
the Internet just isn't that risky anymore.
You're not paying attenton.
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
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.
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).
Help poke pirates in the eyepatch, arr.
I did a fairly detailed analysis of an instantiation of typical Javascript malware these days.
sigs are a waste of space