Microsoft Builds JavaScript Malware Detection Tool

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

Comments

De-obfuscated code?

[aneroid]

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.

Wrong direction

[a_claudiu]

What is a malicios Javascript? I assume for them is a Javascript that takes advantage of your browser flaws. Good luck with analizing a language which have eval function.

You should just sand box the Javascript properly instead of adding an extra layer of bloatware.

Too much malware protection may alter good scripts

[hcs_$reboot]

I think it was in IE7, Microsoft decided to prevent by default the use of "Prompt" in Javascript to help fighting against phishing.
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:Questionable

[VortexCortex]

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