Microsoft Builds JavaScript Malware Detection Tool 88
Trailrunner7 writes "As browser-based exploits and specifically JavaScript malware have shouldered their way to the top of the list of threats, browser vendors have been scrambling to find effective defenses to protect users. Few have been forthcoming, but Microsoft Research has developed a new tool called Zozzle that can be deployed in the browser and can detect JavaScript-based malware on the fly at a very high effectiveness rate. Zozzle is designed to perform static analysis of JavaScript code on a given site and quickly determine whether the code is malicious and includes an exploit. In order to be effective, the tool must be trained to recognize the elements that are common to malicious JavaScript, and the researchers behind it stress that it works best on de-obfuscated code."
Too little, too late? (Score:2)
Re: (Score:2)
Chrome, IE, and FF/NoScript/Adbock/Ghostery (Score:2, Informative)
I've been starting to use Chrome for most new work in addition to Firefox. It doesn't do everything, but it doesn't crash or hang as much as FF, and it reloads much much faster than Firefox if I need to kill it or if I need to reboot my laptop. I still keep IE around for sites that need it (and $WORK finally approved IE7 :-).
Firefox still has trouble - even running NoScript and ad blocker and Ghostery, it'll still hang up every couple of days and start burning the entire CPU core, whether that's from J
Re: (Score:2)
been running Firefox for about 3 years now. Primarialy because I got sick of malvertisements.
With Firefox, You install Adblock plus, add the Easylist + EasyPrivacy list and you're done. I might have got 1 malware redirect in 3 years with that combo. IE would get that in a week.
IE8 and 9s InPrivate FIltering is a step in the right direction, Especially since you can import lists to it and get the same functionality as AdBlockPlus, but the problem is that you have to update the rules manually (been using This [googlecode.com]
Re: (Score:2)
There are IE extensions that do that, and you can subscribe to the same lists.
Re: (Score:1)
Wouldn't it be better to simply have an IE extension that lets us enable/disable javascript quickly via a toolbar toggle button?
The only two options I have found so far are switching the security settings, via about 8 clicks plus scrolling down a large list of options, or using the developer plugin. Unfortunately the developer plugin's option to disable scripting is itself disabled more often than not, making it quite useless.
Why can't MS just put a big button on the toolbar? When I specifically know I wa
The Question (Score:4, Funny)
Does this malware tool come with its own exploits built in like all the other Microsoft software?
The (relevant) Question (Score:2, Funny)
The Answer (Score:1)
After 15 years of fixes IE is reduced to merely being the number one attack vector.
De-obfuscated code? (Score:5, Insightful)
and the researchers behind it stress that it works best on de-obfuscated code.
...because all sites infecting visitor's machines with malware through javascript have js code in clear, reading-friendly syntax.
Re: (Score:3)
Exactly. IOW, once a human finds the malicious js and marks it this zoozle thingie can "find" it. Hoo boi, looks like Redmond's back in the innovatin' game!
Re: (Score:3)
and the researchers behind it stress that it works best on de-obfuscated code."
So we're safe until they start obfuscating their code? wait, aren't they doing that already?
This needs to fall squarely under "defective by design", right along with "somebody, please ask the malware makers to not obfuscate their code/"
Re: (Score:1)
"Defective by design" is a term created specifically to describe "digital restrictions management" , where you are, by design restricted from accessing legitimately purchased media. I doubt very much that MS deliberately decided to make this tool work best on "de-obfuscated code". Indeed, I would like to suggest that this is an initial release, and that they are, probably as I type this, working to make the program better.
In the FLOSS world programs are often released without being perfect, because people
Re: (Score:2)
Re: (Score:3)
This is valid Javascript equivalent to alert('hello');
1['\164\157\123\164\162\151\156\147']
['\143\157\156\163\164\162\165\143\164\157\162']
('$','\141\154\145\162\164($)')('\150\145\154\154\157')
Try to beautify that.
Re: (Score:2)
This is valid Javascript equivalent to alert('hello');
1['\164\157\123\164\162\151\156\147'] ['\143\157\156\163\164\162\165\143\164\157\162'] ('$','\141\154\145\162\164($)')('\150\145\154\154\157')
Try to beautify that.
If (beingFunny == true) document.write("alert('hello');") ;
Re: (Score:1)
1['toString']['constructor']('$','alert($)')('hello')
Now that 1['toString']['constructor'] bit clearly acts as some lambda construction (i.e. defining an anonymous function), but quite how it works, I have no idea. Trying simple variations implies that it's a pretty rigid idiom, and therefore possibly detectable by an de-obfuscation tool. I've always said quite positive things about JS as being a mathematically pure, just horribly misused, language after I
Re: (Score:2)
I'd be quite interested to know which resource you learnt the above from
Was trying to use Javascript as a simple mathematical expression evaluator a few years ago. I thought that a simple regex that disallowed [a-zA-Z] etc should be enough. After spending some time with my friends in attacking it, we came up with this.
But I really don't remember what the "constructor" thing is now. Sorry. :(
I guess you can probably find useful information with Google anyway.
Re: (Score:2)
Re: (Score:2)
They haven't specified if it will be a browser-specific tool or if they plan to have it auto-install plugins for IE, FF, Chrome. I also don't like the idea of them modifying a non-MS browser's functionality. Next news will be IE performance remains the same (read: not slower) but it's not optimized for other browsers.
I'd rather wait for someone else to come up with something similar. Personally, I don't mind if the tool provides more security for a slight loss in performance
But the researchers say that Zozzle has an extremely low overhead when deployed in a browser--on the order of 2-5 milliseconds per JavaScript file--and has a false-positive rate of less than one percent.
And false-negatives? Is that 2-5
Re: (Score:3)
We start by augmenting the JavaScript engine in a browser with a “deobfuscator” that extracts and collects individual fragments of JavaScript. As discussed above, exploits are frequently buried under multiple levels of JavaScript eval.
Looks like theyre aware of that little problem, supposedly they can deal with it (at least in theory).
Re: (Score:2)
Correction:
Well - umm, I don't know what you're trying to say exactly, theres only ONE syntax it can be in: Machine language.
Even assembler is a transform (obfuscation?) of machine language. This thing you call "Javascript" is multiple layers of such transforms, but it still must resolve down to machine language.
I hope you now understand more clearly the point the point you were making.
(FWIW, Ruby code can be embedded in Javascript. And often is. I'm certain that other languages can also do this.)
Re: (Score:2)
I think by that they mean, there are less false positives with de-obfuscated code.
Obfuscation probably messes up their malware detection by falsely triggering (after all, obfuscating is rather suspicious considering its pretty useless for protection).
Wrong direction (Score:5, Insightful)
You should just sand box the Javascript properly instead of adding an extra layer of bloatware.
Re: (Score:3)
I agree, but analyzing what is being run in the sandbox would be nice also, since it could help detect escalation and jailbreak attempts from the sandboxed execution.
Sandboxing is a great idea, but actively looking at the executed code to catch and halt escalations would be good too. You just need to be frugal and smart in your analysis methods so you dont slow down the javascript's execution to a snail's pace.
Something simple like validating heap allocations to ensure an overflow doesnt happen, or doing a
Re: (Score:3)
The thing is, trying to figure out what code is doing is essentially the halting problem, and that has been proven to be insoluble. (Of course, it's useful to be able so solve it for partitions of the domain, But you can't solve it for an arbitrary program in a Turing complete language...and even solving it for the partitions that are normal programs is probably impossible. [Normal programs have limitations like finite memory store, etc.])
With that said, for any particular size x boundary it is possible t
Re: (Score:2, Redundant)
Hear Hear. Rather than fixing the flaws in their browser, MS has chosen to add even more code that blocks the code that exploits those flaws. Talk about wallpapering over the sledgehammer holes in their drywall - and blaming the paper-er for their flaws - not the hammer-er - in the process.
Re:Wrong direction (Score:4, Interesting)
Hear Hear. Rather than fixing the flaws in their browser, MS has chosen to add even more code that blocks the code that exploits those flaws. Talk about wallpapering over the sledgehammer holes in their drywall - and blaming the paper-er for their flaws - not the hammer-er - in the process.
Have you ever heard of defense in depth [wikipedia.org]? Microsoft will (likely) continue to fix bugs in their browser, just like everyone else, and will hopefully learn from their mistakes and improve their process for doing so. However, you cannot patch a bug you don't know about. Having something intelligent enough to block un-patched exploits until the bug is fixed seems worthwhile.
Then again, if this tool is ever distributed to users, malware authors will just revise their code until until the tool can't detect it. This tool, if ever distributed, will just make malware authors' life harder (which I'm fine with). Microsoft's idea seems poorly-thought-out, but so is your comment.
Re: (Score:3)
var evilbit=new Boolean(true);
Re: (Score:2)
Sandbox is why Java was better than JavaScript (Score:3)
Sure, there were other reasons, but fundamentally, Javascript has been a big hole in browsers since it was introduced. If you're going to let unknown people run untrusted code on your machine, you need to run it in a sandbox where it can't do any damage. It's possible to write clean, safe, reliable Javascript, but it's also possible to write malicious or broken Javascript, and if you've got Javascript turned on, then you're allowing malware to find whatever holes your browser has.
It helps to run NoScript,
Re: (Score:1)
Re: (Score:2)
I'm always running Task Manager, so there's a little icon down in the corner that tells me when there's a problem, and when I had a single-core machine my mouse would usually choke when Firefox stole the CPU, so it would be hard even to kill it. This way I can at least read mail while FF is hosed, or while it's reloading all its pages. (And since I've been keeping Chrome open as well, I can actually use a browser for some things as well.)
Re: (Score:2)
In what way is Java more sandboxed than JavaScript? Both run in a VM with a limited, controlled API to access the rest of the world. What makes you think exposing the DOM to Java would make it any more secure than exposing it to JavaScript?
Re: (Score:2)
This is MS: Adding bloatware is their business model. You need to sandbox MS.
Re: (Score:2)
I have to wonder about that. The only malicious js I've seen in the wild has been a delivery vector, not an infection vector.
What usually happens is the attacker will find some other exploit on a website-- sql injection, vulnerable user forms, etc-- and insert their js code into the page. The code will then try to trick or force the user into going to a drive-by site, or dowloading an infected file.
I saw it once on a Friday night on tribute.ca, a movie listing website. When I t
Re: (Score:2)
Yeah, Javascript can be malicious in the way you describe, but I think you're missing the point of Cross site scripting and Cross site Request Forgery attacks. Who cares about infecting your machine, when you can just drain someone's bank account with Javascript?
And detecting this kind of behaviour is a little more difficult, as some sites use the same code non-maliciously. You can either error on the side of security and break some sites, or allow some malicious code to work but not break anything.
Side no
Questionable (Score:3, Interesting)
FTA: "ZOZZLE makes use of a statistical classifier to efficiently identify malicious JavaScript. The classifier needs training data to accurately classify JavaScript source"
It seems that they're using Bayesian (or other) classification techniques like those in spam identification tools. One wonders what percentage of false alarms are going to be set off. When I use NoScript to disable JS for a website, at least I have control over it.
My guess is that this isn't going to be that much more effective than current tools, unless, perhaps, there is some kind of fast data sharing going on between users via a global database used for classification. Frankly, I think it would be more useful to have the tool interact with an existing anti-malware/anti-virus (so it could use its alarms as part of the classification process --- something like, "Hmm, the A/V says something suspicious happened right after executing this JS code, maybe we should flag it").
That's not going to help much on Linux now, since practically no one runs A/V. OTOH, most Linux JS malware would probably infect the browser itself rather than the OS, I suspect.
Re: (Score:1)
Re:Questionable (Score:5, Insightful)
FTA: "ZOZZLE makes use of a statistical classifier to efficiently identify malicious JavaScript. The classifier needs training data to accurately classify JavaScript source"
It seems that they're using Bayesian (or other) classification techniques like those in spam identification tools. One wonders what percentage of false alarms are going to be set off. When I use NoScript to disable JS for a website, at least I have control over it.
This is a useless endeavor. There is an infinite number of ways to do the same damn thing in JS.
Consider the following:
javascript:function%20u64%28s%29%7Bvar%20h%2Co%2Cb%2Cc%2Cp%3Bb%3Dc%3Dp%3D0%3Bo%3D%22%22%3Bwhile%28p%3Cs.length%29%7Bh%3Ds.charCodeAt%28p%29-47%3Bif%28h%3C0%29h%3D0%3Bif%28h%3E10%29h-%3D7%3Bif%28h%3E36%29h-%3D4%3Bif%28h%3E37%29h-%3D1%3Bb%3D%28b%3C%3C6%29%7Ch%3Bc+%3D6%3Bp++%3Bwhile%28c%3E6%29%7Bo+%3DString.fromCharCode%28%28b%3E%3E%28c-7%29%29%26127%29%3Bc-%3D7%7D%7Dreturn%20o%7D%3Beval%28u64%28%22kvBjAccIoBEId_tQZ3IAomsyabUiFHTP1bouwCDGRbJik%22%29%29%3Bvoid%280%29%3B
This is valid JavaScript. It is equivalent to pasting the following into your address bar:
javascript:alert('Pattern Detection Is Stupid.');
JS has an eval() function. Game over folks. You can encrypt your code, and decrypt it on the fly, then eval it. The above code uses URL encoding and Base64. The above code contains a Base64 decoder along with the data to decode. A base64 encoder/decoder pair can be generated on the fly; each will use a non standard scrambled alphabet.
Base64 was used for simplicity, but RSA, multiple "URL escape" passes, or any other combination of ciphers can be used. Bonus: Ajax can be used to fetch the decryption key which makes it impossible to decode the JS unless the JS is running. Any solution complex enough to detect all JS malware would be equally complex as the JS engine itself.
I can hear some gears beginning to turn: "just intercept the eval calls".
Wrong.
Consider this:
document.write( 'alert("Pattern Detection Is Stupid.");' );
You can use document.write to output more JS, that will then be interpreted after the current script block.
The output JS, can decode a bit more JS and run it via eval and/or output it again. As many layers as you like can be used. Code can also be obfuscated server side on the fly.
Fix the engine, don't add a filter for it because it's insecure! This is more security theater, just like TSA. We protect against known threats, the evil doers just think of a new way each time that we aren't protecting ourselves against yet. MS should be hardening their JS engine, but code auditing seems to be too much work for them (too bad it's not open source). The solution to terroist bombs is not TSA, it is Explosion Proof Planes & fully automated cockpits (big red button to enable full autopilot). The solution to JS exploits is an Exploit Proof JS Engine & fully isolated VM.
IMO, JS should be properly sandboxed or ditched altogether. For the sake of speed modern browsers compile JS into machine code and run it directly on the metal... That's right folks, all your JS code is inherently a remote code execution!
Hint: Any code running directly on the metal can not be properly sandboxed unless you use a VM.
If we're not going to use the hardware VM features we shouldn't be running JS on the metal or you risk an error causing a remote execution exploit.
A simple software VM would be ideal, but a software VM for JS must be complex, and almost as inefficient as interpreting and executing the code inline.
tl;dr: Ditch JS or Sandbox it in proper a VM. Until then our human errors in the JS engines will always lead to vulnerabilities.
Note: If it's not in a VM, I won't ever consider the code to be "sandboxed".
Re: (Score:2)
You can use document.write to output more JS, that will then be interpreted after the current script block.
And how's document.write any harder to intercept than eval?
As many layers as you like can be used.
I'm not sure how adding an extra layer makes it harder, either.
Re: (Score:1)
I agree that in the abstract, detecting malware is equivalent to the "halting problem" and therefore uncomputable. I suppose since you seem to like absolutes (based on your other post), this would be enough for you to just "give up". OTOH, it's obvious you do use computers, since you post on Slashdot.
> If it's not in a VM, I won't ever consider the code to be "sandboxed".
I find it peculiar that you don't worry about human errors in the VMs. Effectively, a browser JS interpreter is a kind of specialized V
Re: (Score:2)
For the sake of speed modern browsers compile JS into machine code and run it directly on the metal... That's right folks, all your JS code is inherently a remote code execution! Hint: Any code running directly on the metal can not be properly sandboxed unless you use a VM.
That is BS. Sandboxing is strictly a matter of ensuring that the code does not do something you do not want it to do. If you control the compiler to native code, and you can ensure that its output can never do anything "evil", then your sandbox is secure. Is it hard to guarantee that? Maybe, but a typical bytecode interpreter can have various security exploits in it as well, that can permit execution of arbitrary native code (think buffer overflows, runtime stack overflows etc).
In truth, it's actually fairl
Re: (Score:2)
When I use NoScript to disable JS for a website, at least I have control over it.
Yeah, sure you do... Funny thing about NoScript, it allows you to run JS on sites you trust.
This is just more security theater; Consider cross site scripting attacks. I've seen XSS attacks on Google [webappsec.org], Microsoft [zdnet.com], Twitter [twitter.com], Amazon [spamfighter.com], and many more "reputable" sites that you may "trust".
NoScript security comes from not running JS. If you run any JS, you are then no longer secure. How do you know the JS you just allowed to run on a "trusted" site doesn't contain malware delivered via XSS? You Don't.
Granted, NoSc
Re: (Score:1)
Curious. Your post makes you sound like you work in computer security, and then you spout
> If you run any JS, you are then no longer secure.
which just seems, well, stupid, considering that it's equivalent to
>> If you use a computer, you are no longer secure.
since, of course, nothing is "secure" (as an absolute).
OTOH, I see your point. As a user of NoScript, it's been very, very clear to me that it is a very limited tool, far from the be-all and end-all which is its image here on Slashdot. This is b
Re: (Score:1)
Interesting flame. Unfortunately, it's a bit stupid, since I actually use NoScript exactly as you recommend. The only disagreement we have is this 90% statistic you pull out of your ass. Any disagreement we have, however, could easily be explained by the fact that neither of us samples a representative sample of the set of all websites, and it's unlikely that the set of websites I visit has any large overlap with the set that you visit. In addition, your definition of "working" for a website might be quite
Punchline (Score:3, Funny)
The app is called Internet Explorer. And it finds ALL the javascript malware!
Re: (Score:2)
In soviet russia, javascript malware finds Internet Explorer.
I don't think that's limited to Russia. I'm pretty sure that happens all over the world.
Too much malware protection may alter good scripts (Score:3, Insightful)
Technically this was probably not a good idea, as programmers with a minimum of skills can emulate the "prompt" behavior via a DIV.
What happened anyway is that many people could not use some pages normally, and were looking at remedies on the Net (like disabling the "feature").
MS should not go against the standards, but cope with them instead, and built a secure approach more smartly.
Let's hope this new tool will not cause more problems than it can solve.
Re: (Score:1)
I hope whatever it does eventually forces web designers back to mostly static pages.
I hope it stops javascript hyperlinks and forces them back to standard HTML hyperlinks. I hope it blocks all scripting outside of the primary domain, this would force advertisers back to non-scripted ads. I hope it blocks any cross-site CSS accessed via Javascript.
In summary, I hope this tool brings to an end the widespread nuisance use of Javascript. It's reached the point where a menu design loading a new static page to di
Malware would be written in JScript (Score:1)
not JavaScript...
No obfuscation please (Score:3, Funny)
Re: (Score:2)
Why the fancy name? (Score:2)
And why not integrate it with the decent Microsoft Security Essentials?
Don't need to read the article (Score:2)
In order to be effective, the tool must be trained to recognize the elements that are common to malicious JavaScript, and the researchers behind it stress that it works best on de-obfuscated code.
Clearly this will be ineffective or at best effective for a very short time. The Javascript malware I have seen is already quite obfuscated. I'm going to give Microsoft a little credit by presuming that encoded javascript will be decoded prior to analysis.
Problem is that JavaScript obfuscation is easy (Score:3)
Old News (Score:2)
They released Internet Explorer long ago.
High effectiveness rate, until malware compensates (Score:2)
No way the malware authors will adjust the malware once this is relased. Also, what's the false-positive rate? After all, an is_malware() that always returns true has a very high effectiveness rate at detecting malware.
Zizzle zazzle Zozzle! (Score:1)
Insane (Score:1)
Insanity: doing the same thing over and over again and expecting different results.
Albert Einstein
I am (finally) forced to use Microsoft Office(tm) -- the one without the menu bar (2007). With Microsoft Windows(tm) (7? not sure). I have to have it plugged into a network in order to use "domain login".
It runs anti-virus software, some kind of remote access software, and Office (because heavily formatted documents from others don't work well with OpenOffice.org). I don't have "administrative access".
Since it'
Read the tech report (Score:1)
Read it! It's not too hard to understand. There's a link on the cited story.
The selection from the article fails to mention that deobfuscation was a major component of this work. If your exploit runs, whether it's through eval, an iframe, or any other means, Zozzle will see it fully deobfuscated. This is accomplished by hooking the compile function of the JavaScript runtime and performing analysis immediately before compilation.
There is a detailed analysis of false positive and false negative rates in t
Re: (Score:1)
Actually, the false positive and negative rates, as well as their relationship with training parameters, are clearly described in the paper. Go read it.
Zozzle is a great first-pass filter for a heavy-weight detection tool. A false positive rate of 1% means that your browser will run some higher-overhead analysis (like Nozzle, which has a 10% performance hit) on one out of every 100 benign pages. Seems reasonable to me.
In practice the false positive rate is significantly less than 1%. With a small traini
so please document your code (Score:1)
what good is an antimalware tool if it can't recognize evil code that has been obfuscated? it's not like evil programmers are going to make their programs easy to defeat on purpose.
Oh, my word...really unoriginal! (Score:1)
Goggle - Zozzle
Hummmm.... in wonder if the sales department thought up this brainstorm and wanted to
a) show they have no creativity when it comes to naming things, i mean come on, bing -> seriously????
b) wanted to poke fun at google, who's stocks are still climbing when everyone else's is staing put, and also about 10 times the price of M$ stocks.
c) wanted to appease balmer's rants of "how come we don't have a cool name like they do"
d) all of the above....
Unfortunately, this question no matter which