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."
SANS (Score:1, Funny)
I'm still not sure what I think of them.
I mean, it's a great idea. But they update their diary every day, which means for the most part, it's totally boring crap. Today's entry is a little different.
I still think of SANS as a bunch of old guys all sort of pontificating about the most mundane things. Wind back 5 years and I think they had a valid part to play, especially with the amount of viruses and worms flying around. These days, not so much. Security is so much higher on everyone's radar that they'
Re: (Score:3, 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.
Re: (Score:2)
A case of "duh" (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.
Re:A case of "duh" (Score:4, 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.
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)
Re:DRM and copy protection schemes (Score:5, 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.
Re: (Score:2)
The point IS to hide what's going on, not to lock things down.
Right, this is not security through obscurity folks.
It is obscurity through obscurity!
Re: (Score:1)
Re: (Score:2)
Plus Firebug 1.2 already does what their patch does. If you want to see what the final execution result is, click the dropdown in the Scripts window to see the text of all eval() calls.
How long until they do setTimeout("final code", 1) instead of eval(), and how long until they do document.write("<div id='foo' onclick='malware.code;'></div>"); document.getElementById('foo').onclick(); etc? As gp said, it's a malware arms race, they're changing their obfuscation techniques to bypass the current
I'm not sure it's more than a speedbump (Score:1, 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.
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
Re: (Score:2)
"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."
noscript is an easy firefox add-on. if you're advising 'normal' people how to use the internet safely, you'd have told them to use noscript and only allow really trusted sites that you can't live without.
personally, I don't trust any site that much. besides, with noscript, slashdot tells you to use the old style instead of the new style layout.
Re: (Score:2)
Here the malware author clearly won
No more than the RIAA has "won" by imposing or using DRM on their music downloads and on iTunes. In that case it only takes one cracked version to leak out before everyone else gets the benefit of the original cracker's behavior ad-infinitum. Likewise, once the detection is worked into a Javascript blocking and filtering tool, such as no-script [mozilla.org], everyone using no-script benefits from the original analysis (it doesn't have to be cracked afresh each time it comes up). So the malware author is really only inco
Re: (Score:1)
SpiderMonkey is the Mozilla's C's JavaScript engine - they got one in Java, called Rhino and one in JavaScript that I don't remember its naming.
SpiderMonkey is used on the Firefox browser, so a millions of people got it handy.
It's fairly easy to make a graphical interface to allow any end user to copy or save the data to a file.
Everywhere you have to update your techniques when new malwares appear.
The better your heuristic, the less you have to update.
Comment removed (Score:5, Insightful)
Re: (Score:3, Insightful)
Re: (Score:2)
Ouch, I didn't realize how common this was. Feel free to moderate the grandparent post into oblivion.
No, don't. Just because 'everyone' does it doesn't make it any less stupid.
Its like the terrorism threat levels - they don't have any correspondance to what is likely to happen to you as an individual. Even if SANS says the "internet threat level is green" you can still get DDOS'd, or get infected by a virus, or browse to the wrong website and get suckered by a cross-site scripting attack, or any number of other things.
The internet is just as dangerous to individuals regardess of what the 'threat level' i
Re: (Score:2)
Re: (Score:2)
Funding (Score:1, Flamebait)
I could sit here all day comming up with ways to put ghosts in the machine !
Re: (Score:1)
Re: (Score:2)
first post? (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!
Re: (Score:2)
No, no... it prints it out to itself and then executes it. You'll see no more than you did before.
Unless you're a hacker and then it will stick it's tongue out at you first.
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: (Score:1)
Re: (Score:2)
Well, if you leave off the base62 encode option, you get a file that's "prepped" for better gzipping. But of course that doesn't require an eval, which was the point of this whole thread, so you're right about that.
I've also noticed, though, that IE will barf on long Javascript files, so doing the base62 compression on the Javascript even with gzip is a workaround for that.
Re: (Score:2)
Exactly how do you "prep" a file for gzipping? Remove all the linebreaks and spaces?
Re: (Score:2)
Yes, and also to shrink variable names, arguments, etc. See Javascript compression guru Dean Edwards's take on the subject [edwards.name].
Re: (Score:2)
Simply minifying your scripts by stripping out comments and unneeded whitespace will do almost as good a job compressing the data with eval. Add in gzipping and the difference is negligible, plus there's no additional delay on the client side when that script is decompressed for each and every page that uses it.
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).
Re: (Score:1)
Re: (Score:1)
if you're using JSON (fairly common now), there's a good chance you're using eval().
Jeez, I hope not. I thought that by now everyone knew that using eval() is setting yourself up for failure.
Re: (Score:3, Interesting)
See http://www.json.org/js.html [json.org]
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(
Re: (Score:2)
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.
Did you even bother to read that page that you directed me to?
To defend against this, a JSON parser should be used. A JSON parser will recognize only JSON text, rejecting all scripts. In browsers that provide native JSON support, JSON parsers are also much faster than eval.
So, you're claiming that a JSON parser, which is faster than eval, checks its input and then calls eval. I think I see a contradiction.
Or are you talking about legacy browsers that don't yet provide JSON support? In that case, I hope that you aren't invoking eval either directly or from some home-grown function library, but are using that json2.js that you point to; yes, it sometimes (not always!) uses eval, but only after checking that the bro
Re: (Score:2)
Was there even a point to your tirade?
My comment was in reply to your sweeping generalization that “everyone” knew using eval() is just setting oneself up for failure. json2.js is proof that, with adequate attention given to security, eval() usage isn't a problem.
To the best of my knowledge, as of this writing, the only browser that supports native JSON is Firefox 3/Mozilla 1.9: http://developer.mozilla.org/en/docs/nsIJSON [mozilla.org] -- this still excludes most people, however.
The rest all require an exter
Re: (Score:2)
My point was that programmers shouldn't use eval() in Javascript, just like programmers shouldn't use goto statements. That doesn't mean that you can't use tools that use those features (I use yacc and lex many times a year), it just means that using them is very hazardous and best avoided. And yes, I realize that this means that there are exceptions to the rule, since it is programmers who write those tools, but those exceptions are very, very, limited. Thinking that you can whip out some code that uses
Re: (Score:1)
Re:So how does this solve anything in the real wor (Score:4, Informative)
document.referrer (Score:4, Interesting)
Re: (Score:2, Informative)
Re: (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: (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.
Re: (Score:1)
If you allow any referrer for an image, you are allowing anybody to embed this image into their page, thus stealing your bandwidth. To prevent that, you only allow your own pages to refer to your own images. Of course this can be spoofed manually by the client, but too complicated for most people.
A funny thing is that the "HTTP_REFERER" header name is wrong
Re: (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.
Re:document.referrer (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?
Silly websites that check it as some sort of "security." Easily foiled by sending the site's own URL as the referer though.
Re: (Score:2)
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.
Of course, that might revive any Javascript malware.
Re: (Score:2)
Even that doesn't work for all sites. Newegg [newegg.com], for example, won't let you finish checking out if you forge the referrer. I had to add an exception to it to RefControl.
P.S. I have RefCon
Re: (Score:2, Interesting)
Re: (Score:2)
Re: (Score:1)
If you don't like giving out Halloween candy, don't answer the door.
Its more like my neighbour handing out the candy I bought. He gets the "credit" while I paid for the goodies.
Re: (Score:2)
Some sites hate it and I get blocked, missing images, etc. :(
Re: (Score:2)
"Why would you want it enabled, anyway?"
To access the thousands of sites which check it to make sure nobody isn't "stealing" their bandwith.
Re: (Score:1)
Because website authors can use the referrer field to improve their services, by figuring out which access patterns are most common, and which links should be made more or less prominent.
By hiding that information, you are depriving them of that possibility, and you are therefore depriving the Internet a certain means of becoming better.
Re: (Score:1)
I thought this was Slashdot, and privacy trumped all?
Any time we give information away it gets used against us. Thanks to one of the previous posters as of today I now use RefControl.
Re: (Score:2)
Never actually used it like that (prefer to store that kind of thing in session variables if I'm forced to) but I could see someone doing so
DRM Lesson (Score:3, 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.
Re: (Score:1)
stop (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!
old school protection (Score:1)
lets hope they don't try stuff like this:
http://en.wikipedia.org/wiki/Rob_Northen_copylock [wikipedia.org]
it was hard. I guess there's no way to use special cpu modes, but you could still knock up a large amount (megs) of seemingly random data which contains code which you decrypt a few bytes at a time, re-encrypting the 'code' you just executed and hide, within thousands of jumps, loops and other messed up logic the actual guts of your code.
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
eval() (Score:2)
evil()
?
It is after all, an inbuilt function of Javascript.
JavaScript? (Score:2)
A more detailed analysis (Score:3, Interesting)
I did a fairly detailed analysis [xman.org] of an instantiation of typical Javascript malware these days.