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."

23 of 76 comments (clear)

  1. A case of "duh" by Annymouse+Cowherd · · Score: 2, Interesting

    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.

    1. Re:A case of "duh" by kesuki · · Score: 3, Interesting

      "Is it just me or is this way of getting around it mind-blowingly obvious."

      even more mind blowingly obvious, is noscript. it's pretty hard for java/javascript based malware to infect you when the browser won't automatically launch javascript or java.

  2. DRM and copy protection schemes by spion666 · · 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)

    1. Re:DRM and copy protection schemes by panaceaa · · Score: 4, Interesting

      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.

  3. first post? by hesaigo999ca · · Score: 2, Funny

    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!

  4. Baby & Bathwater? by XanC · · Score: 4, 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

  5. document.referrer by Anders · · Score: 4, Interesting

    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?

    1. Re:document.referrer by ypctx · · Score: 2, Informative

      Many sites won't work without it, mainly to prevent "hotlinking".

    2. Re:document.referrer by geminidomino · · Score: 3, Interesting

      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?

      Silly websites that check it as some sort of "security." Easily foiled by sending the site's own URL as the referer though.

    3. Re:document.referrer by Anders · · 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 gives you arbitrary Referer headers on a per-site basis.

    4. Re:document.referrer by ArcticFlood · · 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.

      --
      This is here so you don't ignore the last two lines of my posts.
    5. Re:document.referrer by ArcticFlood · · 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.

      --
      This is here so you don't ignore the last two lines of my posts.
    6. Re:document.referrer by Nos. · · Score: 2, Interesting

      I check the referrer header for images on some sites, not for security, but for reducing bandwidth thieves doing hotlinking. On more than one occasion folks have linked to images on busy forum sites which costs me bandwidth. Checking that the referrer is either the local site or blank reduces that bandwidth waste to virtually zero. Yes, some will still get through, but the few minutes it takes to add to the virtual host configuration in Apache is well worth it.

  6. DRM Lesson by MyLongNickName · · Score: 2, Insightful

    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
  7. stop by ypctx · · Score: 5, Funny

    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!

  8. Comment removed by account_deleted · · Score: 4, Insightful

    Comment removed based on user account deletion

  9. Re:So how does this solve anything in the real wor by Anders · · Score: 4, Informative

    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.

  10. Re:Threat levels? by martinw89 · · Score: 2, Insightful

    Ouch, I didn't realize how common this was. Feel free to moderate the grandparent post into oblivion.

  11. Its not obfuscation by Anonymous Coward · · 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 &lt;, 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

  12. Re:SANS by sm62704 · · Score: 2, Insightful

    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
  13. Re:So how does this solve anything in the real wor by cparker15 · · Score: 2, Interesting

    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.

  14. Save yourself some headache, just gzip it by patio11 · · Score: 2, 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).

  15. A more detailed analysis by X · · Score: 2, Interesting

    I did a fairly detailed analysis of an instantiation of typical Javascript malware these days.

    --
    sigs are a waste of space