×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Microsoft Builds JavaScript Malware Detection Tool

timothy posted more than 3 years ago | from the canary-for-the-coalmine dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

88 comments

Too little, too late? (2)

Nialin (570647) | more than 3 years ago | (#34442516)

Firefox for 4+ years, and never looked back.

Re:Too little, too late? (-1, Troll)

wmac (1107843) | more than 3 years ago | (#34442820)

Firefox for 4+ years and recently looked seriously at IE9 and Chrome (because why the hell FF should take 1.5G of my RAM and slow down in an extent that context menu takes 5-10 seconds to open).

Used Chrome for 1 month but it is to limited. You should install an extension to add a button to toolbar and extensions are not as good as those available on FF.

I will use IE9 as soon as it comes out to see whether I can use that.

Chrome, IE, and FF/NoScript/Adbock/Ghostery (1, Informative)

billstewart (78916) | more than 3 years ago | (#34443170)

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 Javascript or Flash or just bugs, and sometimes it crashes, especially on AJAX pages, and sometimes it's unresponsive enough that I need to kill it even if it doesn't crash. It's become tolerable now that I've got a dual-core CPU and more than 1.5GB RAM, but it's annoying.

The application that doesn't work well on Chrome is reading news - take a news aggregator site like FARK, open a hundred news articles in tabs, and then start reading them; Chrome often gets stuck and can't handle it.

Re:Too little, too late? (0)

Anonymous Coward | more than 3 years ago | (#34444570)

Wait, what?! 1.5G?!! What the hell are you using it for? FF right now is taking up 7% f my 2Gig of ram and I have ~30 tabs open. I have 7 extensions installed and enabled. Whatever you're doing, it's not normal.

Re:Too little, too late? (0)

Anonymous Coward | more than 3 years ago | (#34444748)

because why the hell FF should take 1.5G of my RAM and slow down in an extent that context menu takes 5-10 seconds to open

Vista?

Re:Too little, too late? (1)

Deathlizard (115856) | more than 3 years ago | (#34444910)

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 list [googlecode.com] for awhile), and it's cumbersome to import adblock lists into IE every week to keep up. If someone made an BHO that would automatically update the InPrivate list, or MS would add a subscription option to it, I would probably go back to IE9.

Re:Too little, too late? (1)

wampus (1932) | more than 3 years ago | (#34445456)

There are IE extensions that do that, and you can subscribe to the same lists.

Re:Too little, too late? (1)

LesFerg (452838) | more than 3 years ago | (#34446912)

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 want to enable scripting I would like to do so quickly and easily.

Oh, and before somebody points out the 'prompt' option in security settings, check out how many times the prompt can appear while a single page is loading. Seriously unusable.

The Question (3, Funny)

Dunbal (464142) | more than 3 years ago | (#34442544)

Does this malware tool come with its own exploits built in like all the other Microsoft software?

De-obfuscated code? (5, Insightful)

aneroid (856995) | more than 3 years ago | (#34442554)

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:De-obfuscated code? (2)

clang_jangle (975789) | more than 3 years ago | (#34442782)

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.

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:De-obfuscated code? (2)

v1 (525388) | more than 3 years ago | (#34443008)

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:De-obfuscated code? (1)

no known priors (1948918) | more than 3 years ago | (#34446266)

"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 like the idea of "release early, release often". It gives users a chance to play with new features soon after they are written etc.

So, I'm going to suggest that in this case, MS is not being bad.
Links that are relevant:

Re:De-obfuscated code? (1)

bjourne (1034822) | more than 3 years ago | (#34443034)

Re:De-obfuscated code? (2)

sydneyfong (410107) | more than 3 years ago | (#34443054)

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:De-obfuscated code? (1)

WrongSizeGlass (838941) | more than 3 years ago | (#34443214)

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:De-obfuscated code? (1)

fatphil (181876) | more than 3 years ago | (#34443274)

Beauty's not possible, but de-uglifying's possible:

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 worked out how to Curry functions with it (I have a maths/lisp background), but never learnt it in enough depth to back that feeling up - I'd be quite interested to know which resource you learnt the above from, as I reckon that could keep me interested for many a cold winter evening!

Re:De-obfuscated code? (1)

sydneyfong (410107) | more than 3 years ago | (#34448328)

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:De-obfuscated code? (0)

Anonymous Coward | more than 3 years ago | (#34457058)

Geez, you are terrible. You are posting something like this and then you can't even explain it? Bad form, lad, bad form.

Anyway, it's not very 'mystical' at all. Everyone who has anything to do with javascript (for a given definition of 'has to do with') could figure it out.

1 is a [primitive] number. Once you try to access a property on it, it gets converted on the fly to Number(1) [an object], which possesses a toString method. All stock JS functions have Function(...){...} as their constructor.

The Function constructor is used to construct an anonymous function from strings (n-1 many for the parameter list and 1 for the body). Using the Function constructor in your JS is bad practice, though it has some legitimate use cases [stackoverflow.com]. It should raise red flags, however.

Everyone's point (or my interpretation thereof) is still valid though... static code analysis probably isn't the way forward.

Re:De-obfuscated code? (1)

AmberBlackCat (829689) | more than 3 years ago | (#34443158)

I don't like the thought of them making software that interferes with javascript in other web browsers. That makes the performance of the web browsers dependent on this plugin.

Re:De-obfuscated code? (1)

aneroid (856995) | more than 3 years ago | (#34443752)

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 ms including or after de-obfuscation? for which it depends on the browser:

We start by augmenting the JavaScript engine in a browser with a “deobfuscator” that extracts and collects individual fragments
of JavaScript.
...
Much of the novelty of ZOZZLE comes from its hooking into the JavaScript engine of a browser to get the final, expanded version of JavaScript code to address the issue of deobfuscation.

Re:De-obfuscated code? (2)

LordLimecat (1103839) | more than 3 years ago | (#34443924)

Was going to make the same snarky comment, but then kept reading the article where it states:

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:De-obfuscated code? (0)

Anonymous Coward | more than 3 years ago | (#34446068)

Was going to make the same snarky comment, but then kept reading the article...

...and spoiled all the fun Slashdotters like to have spouting misinformation, especially in regards to Microsoft-related things.

Re:De-obfuscated code? (0)

Anonymous Coward | more than 3 years ago | (#34444008)

Well - umm, I don't know what you're trying to say exactly, theres only ONE syntax it can be in: Javascript.

You can name your variables whatever you like, you can try your best to obfuscate it with garbage code, long drawn out ways of preforming the exploits, or even attempting things backwards...

You can't get around
window.location = "MyMalwaresite.com"

Sure, you can go with a variable, like "A" and give that a string "MyMalwareSite.com" and then go window.location = A. Heck, you can even hide that inside your own method. but you are still calling that function, and no amount of obfuscation on anyones part can take out the window.location in order to redirect like that.

So if Microsoft knows the exploits that people use in the browsers, its trivial to target them.

Why they simply haven't just fixed it in the browser, who knows.

Re:De-obfuscated code? (1)

HiThere (15173) | more than 3 years ago | (#34445032)

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:De-obfuscated code? (1)

tsj5j (1159013) | more than 3 years ago | (#34444404)

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

ZZzz (0)

Anonymous Coward | more than 3 years ago | (#34442562)

if char = g; replace with z; else copy

POC or Pointless? (0)

Anonymous Coward | more than 3 years ago | (#34442572)

"doesn't work with obfuscated code" == "doesn't work"

To do this effectively, wouldn't you need to parse the script into an AST or similar?

Wrong direction (5, Insightful)

a_claudiu (814111) | more than 3 years ago | (#34442582)

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.

Re:Wrong direction (2)

wierd_w (1375923) | more than 3 years ago | (#34442640)

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 quick hash check against the sandbox memory for known binary signatures for escalation payloads (The exploit causes a jump in execution, but there must be binary code ready to jump to for the escalation to work. You look for this binary blob with a quick hash check against the sandbox's memory before starting execution.) might be good approaches to catch the most common kinds of attack that would be used.

Granted, being too nosey about what the sandbox is doing opens up the potential for new escalation paths, (What happens if the monitor detects too many exploit packages in the execution stream to properly report? Can you get the monitor itself to cause the escalation by feeding it certain inputs? etc.) so the less it checks the specifics of execution, the better.

Re:Wrong direction (2)

HiThere (15173) | more than 3 years ago | (#34445196)

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 to solve the halting problem with a program that uses no more than a2^x + bx + c units of memory. a, b, and c are constants chosen so that the equation works for all of x == 0, x == 1, and x = 5G. (Note that I didn't specify that this is a minimal bound, nor what unit x measures. bit, bytes, words, kilobytes, it doesn't really matter. The point is that the system solving the problem has to be immensely more powerful (both in RAM available and in cycles used) than they system that is being solved for.

E.g., for a small state space one can just trace all paths to every state that halts. This obviously only works in a finite space. And you have to allow for cycles where only one variable is changing. (e.g.: for (x = 0; x 2^25; x++) continue; ) which will eventually halt.

Clearly smarter programs can handle simple degenerate cases in much less space, but to handle all of them requires tracing the possible paths of execution (forwards or backwards, or both, it doesn't matter).

So while programs that attempt this are interesting, they can't reasonably be general. And sandboxing is a much better and easier solution.

Re:Wrong direction (1, Redundant)

ThePromenader (878501) | more than 3 years ago | (#34442744)

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 (3, Interesting)

Jahava (946858) | more than 3 years ago | (#34442878)

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:Wrong direction (0)

Anonymous Coward | more than 3 years ago | (#34444870)

MS already has lots of other technology baked into the operating system that is designed to make it harder to exploit bugs. Search for ASLR, DEP, SEHOP, GS, and so on...

Re:Wrong direction (0)

Anonymous Coward | more than 3 years ago | (#34442796)

. Good luck with analizing a language which have eval function.
 

Well, as this is static analysis, analyzing input to the eval function is pretty much what they do.

Re:Wrong direction (1)

TheRaven64 (641858) | more than 3 years ago | (#34443456)

And if the input to the eval function is computed from the result of some network query? As a trivial example, what happens if you put the JS code, base64-encoded, in a hidden element in a remote page, fetch this with an AJAX request, decode it, and then eval() it? That's pretty hard for static analysis to catch.

Sandbox is why Java was better than JavaScript (2)

billstewart (78916) | more than 3 years ago | (#34443102)

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, and ad-blockers, and Ghostery, but even with that, the amount of ostensibly-non-malicious Javascript and flash out there on pages I want to see is enough that Firefox often tries to burn the entire CPU (and one of the nice things about dual-core machines is that now when that happens, FF is stuck on one core and the rest of my machine is still working fine.)

Re:Sandbox is why Java was better than JavaScript (1)

fatphil (181876) | more than 3 years ago | (#34443290)

One of the problems of having a dual core machine is that you don't notice immediately that Firefox is running amok! I'd rather kill it immediataly, thank you.

Re:Sandbox is why Java was better than JavaScript (1)

billstewart (78916) | more than 3 years ago | (#34445494)

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:Sandbox is why Java was better than JavaScript (1)

SanityInAnarchy (655584) | more than 3 years ago | (#34444948)

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:Wrong direction (1)

Anne Thwacks (531696) | more than 3 years ago | (#34443668)

adding an extra layer of bloatware

This is MS: Adding bloatware is their business model. You need to sandbox MS.

Re:Wrong direction (1)

halcyon1234 (834388) | more than 3 years ago | (#34443734)

What is a malicios Javascript?

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 tried to look up show times, I got the full-DIV, animated "scanning your desktop omg you're infected download this and send us money" js. (Running firefox, so nothing automatically installed like it would with IE). I did think it was kinda sad that a major website like that could get owned so hard on their busiest night. Sadder was since it was after business hours, it didn't get fixed all weekend.

Re:Wrong direction (1)

Bill, Shooter of Bul (629286) | more than 3 years ago | (#34445100)

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 note for consumer safety: Do NOT open any other browser windows/tabs of the same browser if you are accessing your online banking or other site which has a large amount of your personal data.

Re:Wrong direction (0)

Anonymous Coward | more than 3 years ago | (#34448190)

People who have a /. account and therefore should be smart enough, but instead are dumb enough to enable js on sites for getting movie listings or other simple textual content, frankly deserve to be hacked.

Is this attractive? (0)

Anonymous Coward | more than 3 years ago | (#34442584)

So instead of using firefox+NoScript, I could switch to IE, and install this tool to block the malware which is specifically de-obfuscated to be blockable?

Questionable (3, Interesting)

Mathinker (909784) | more than 3 years ago | (#34442610)

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:Questionable (1)

wmac (1107843) | more than 3 years ago | (#34442832)

I also do not statistical methods for serious job like this. I myself use evolutionary, genetic algorithm, NNet and Fuzzy most of the time, but i don't know why I prefer more deterministic algorithms when it comes to security.

Re:Questionable (0)

Anonymous Coward | more than 3 years ago | (#34443318)

I also do not statistical methods for serious job like this. I myself use evolutionary, genetic algorithm, NNet and Fuzzy most of the time, but i don't know why I prefer more deterministic algorithms when it comes to security.

I do not why your writing is so shitty.

Re:Questionable (4, Insightful)

VortexCortex (1117377) | more than 3 years ago | (#34443608)

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:Questionable (1)

SanityInAnarchy (655584) | more than 3 years ago | (#34444968)

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:Questionable (0)

Anonymous Coward | more than 3 years ago | (#34444978)

You don't seem to understand... all of your encoding tricks still depend on the javascript engine eventually interpreting the code, in order to do damage. You modify the javascript engine to decode and pattern-match the code it is about to interpret. In its most limited form, this would be a sort of keyhole analyzer that classifies small about-to-be-interpreted code fragments as malicious or not. However, if properly coupled with the entire just-in-time compiler infrastructure, you can probably widen the keyhole to view the fragments within the context of most or all of the other fragments decoded and interpreted so far.

At the limit, this approach could evolve into a sort of lazy whole-program analysis, just analyzing the whole program that has been reached so far. To beat it, you would have to play chess against it, building up a complex strategy that it does not recognize until it accidentally interprets your check-mate maneuver. You don't waste time trying to encrypt or encode your evil code, since it all gets stripped away before execution by definition. You spend your time creating a complex assembly of seemingly simple, innocuous code bits which add together to do something nasty. If they also introspect on the heap state to pattern match not just the code fragments but their current data values at runtime, it becomes much more difficult to pull this off.

Re:Questionable (1)

Mathinker (909784) | more than 3 years ago | (#34445166)

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 VM. I understand that because of the way VMs work vs. browser JS interpreters, one might be easier to write in a secure manner than the other, but the argument over which is easier to write in a secure manner is similar to the argument whether Linux is more secure than Windows (i.e., neither is absolutely secure, and the security attained actually has more to do with their use scenarios than with any structural feature in either OS).

Re:Questionable (1)

shutdown -p now (807394) | more than 3 years ago | (#34446422)

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 fairly easy. So long as you define the language spec such that it is inherently sandboxed (i.e. it does not permit any unsafe operations, and so long as your compiler is implemented to the spec (i.e. can compile only the language as defined, and refuses to compile any invalid program), then you're good. If need be, you can even use the formal proof methods to ensure that both the spec and the implementation are correct.

By the way, your use of the term "VM" as "doesn't execute native code" seems to be very much non-standard. JIT-compiling has been considered a perfectly valid implementation technique for VMs for decades.

Re:Questionable (1)

VortexCortex (1117377) | more than 3 years ago | (#34443958)

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, NoScript does increase your security because you're running less JS code, but it does not make you invulnerable to JS exploits unless you never allow JS to run.

The "control" you think you have can be ripped away from you by one XSS attack; So, what control do you actually have?

Re:Questionable (1)

Mathinker (909784) | more than 3 years ago | (#34445052)

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 because of the way the web is currently set up, such that the majority of websites are rather unusable unless I enable JS for them, at least temporarily.

> So, what control do you actually have?

Obviously, not the control to be absolutely "secure", since that is impossible. I was talking about the control to decide to trade greater security for greater usability.

Re:Questionable (0)

Anonymous Coward | more than 3 years ago | (#34449366)

Only because you're a fucking idiot.

The whole point of not running JavaScript from sites except those that you whitelist is one of risk management. An unprotected web browser loads and executes javascript from dozens to hundreds of websites through the course of a month. If any *one* of those sources is hacked / infected / malicious, then your machine is screwed.

By limiting the size of your whitelist, you cut your exposure. Now, in order to get infected, it's not enough that just one of those dozens or hundreds of sites is infected, it also has to be one of the few dozen sites that you've actually whitelisted.

That cuts your exposure by at least an order of magnitude, and probably a few orders of magnitude depending on how liberal you are with whitelisting.

And 90% of the sites out there work fine without JavaScript being enabled. Those that don't, have alternatives. Or else you have to decide to take the risk and trust them temporarily or permanently. And you get the option to trust the main site, but not the ad networks, or 3rd party sites that have no business integrating with the host site.

It's still a darned sight better then trusting the entire planet not to pwn your machine.

Re:Questionable (1)

Mathinker (909784) | more than 3 years ago | (#34449564)

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 different from mine.

As for "alternatives" always being available, that's kind of a reach --- or are you monitoring my web habits? LOL

A pity you couldn't actually comprehend my post, or at least relate to it like a normally socialized human being.

Microsoft? (-1)

Anonymous Coward | more than 3 years ago | (#34442612)

hahahaha

Punchline (3, Funny)

Anonymous Coward | more than 3 years ago | (#34442636)

The app is called Internet Explorer. And it finds ALL the javascript malware!

Re:Punchline (0)

Anonymous Coward | more than 3 years ago | (#34442686)

In soviet russia, javascript malware finds Internet Explorer.

Re:Punchline (1)

WrongSizeGlass (838941) | more than 3 years ago | (#34443228)

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 (4, Insightful)

hcs_$reboot (1536101) | more than 3 years ago | (#34442670)

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:Too much malware protection may alter good scri (1)

Anonymous Coward | more than 3 years ago | (#34444866)

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 display the next menu option effectively loads faster than all the bloated Javascript code these days.

If web designers want to have all the bells and whistles on their page, do it on the server side and stop using client side resources for what is effectively useless crap. Thank you.

No obfuscation please (3, Funny)

irober02 (1320181) | more than 3 years ago | (#34442722)

Dear Malware Writer, I've just installed this cool MS malware/JS detector but it doesn't work with obfuscated code so, please don't hide your tricky JS code otherwise I won't be able to stop you abusing my computer. thanks, much appreciated. ;-)

De-Obfuscated Code (0)

Anonymous Coward | more than 3 years ago | (#34442766)

It has to be pretty straightforward for Zozzle to catch it.

VirusHereNothingtoSee.Virus(inject, 1);

Don't need to read the article (1)

erroneus (253617) | more than 3 years ago | (#34442806)

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.

High effectiveness rate, until malware compensates (1)

noidentity (188756) | more than 3 years ago | (#34443186)

[It] can detect JavaScript-based malware on the fly at a very high effectiveness rate

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.

Re:High effectiveness rate, until malware compensa (0)

Anonymous Coward | more than 3 years ago | (#34445556)

Microsoft has a long proud history of thinking expertise in one thing makes them qualified to try to translate success to another domain. Best thing they could do would be to open source it. I wonder if they plan to use it and publish risk rankings on Bing searches?
If they do not open source it, its doomed to fail.

Insane (0)

ratboy666 (104074) | more than 3 years ago | (#34443806)

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's plugged in, I decided to portscan it. 10 open ports (AFAIR). Compare and contrast to 1 open port when I open my (considered non-secure) laptop (22, for ssh).

Yes, SSH has had two exploitable vulnerabilities in the past 15 years. (well... 1, unless you use debian/ubuntu in which case 2). But, client computers really don't need any other incoming ports. I guess it's a good thing my Windows laptop doesn't have port 22 open!

As to JScript? I have been using NoScript. Blanket denial of JScript unless I specifically enable it. We know that pattern-matching heuristics don't work (even though I am forced to put up with it on my MS Office laptop).

Still, I guess that the universal access to computers that has been enabled by Microsoft Windows and cheap Intel hardware has been a net positive to society.

The solution would be to produce two operating environments -- a "starter" and a "normal". We already have this, in the form of Windows vs. Everything Else. But, due to the commercial nature of Windows, there is limited compatibility across the tiers.

Read the tech report (1)

ccurtsinger (1952922) | more than 3 years ago | (#34444962)

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 the tech report. By "high effectiveness," the article means "high accuracy." Zozzle correctly classifies over 99% of JavaScript samples in the evaluation set, and has a false positive rate well below 1%.

It would be hard to claim Zozzle is bloatware: the static analysis requires little more time than simply parsing the code. Again, detailed analysis of Zozzle's performance is in the tech report.

The fancy name: I'm glad you think it's "fancy." Zozzle is trained on heap sprays collected by a highly precise runtime detector called Nozzle. Zozzle = zero-day Nozzle. Plus, it's fun to say. As a side note, Zozzle can detect ANY type of JavaScript attack, not just the heap sprays provided as training data. These attacks share many characteristics with other exploits.

Malware writers will adapt: Yes, almost certainly. However, there are some things you can't remove from your code, like calls to the JavaScript runtime functions being exploited. This means a lot of known attacks are off the table and malware writers will need to identify new vulnerabilities to successfully attack Zozzle's users. Even then, these attacks will eventually be picked up by other detection tools, Zozzle will be trained on them, and the malware writers need to start over. This is all assuming these new attacks don't contain patterns Zozzle has already been trained on. Zozzle raises the bar for malware writers, and significantly reduces the effectiveness of copy-pasted attacks (which are the vast majority of attacks on the internet today).

A false positive rate of less than one percent.... (0)

Anonymous Coward | more than 3 years ago | (#34445708)

      "Zozzle...has a false-positive rate of less than one percent"

So let's say it's a half percent. I bet most of us look at several dozen web sites a day...so once a week this thing is going to prevent me from visiting a perfectly cromulant website? I don't think that's anything like good enough. Notice that they don't tell us the false-negative rate.

Re:A false positive rate of less than one percent. (1)

ccurtsinger (1952922) | more than 3 years ago | (#34446824)

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 training set of 300 malicious samples, Zozzle has a false positive rate of 0.14%. In practice, a much larger training set can be constructed, further reducing the false positive rate.

The Pseudocode (0)

Anonymous Coward | more than 3 years ago | (#34446480)

Here is the pseudocode

test
{
if platform (windows)
      close browser;
}

so please document your code (1)

jsepeta (412566) | more than 3 years ago | (#34447160)

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.

Re:so please document your code (0)

Anonymous Coward | more than 3 years ago | (#34448020)

It would be no good. That's why this one deobfuscates the code. It's in the article.

Microsoft ... Malware Detection .... NO ! (0)

Anonymous Coward | more than 3 years ago | (#34448036)

Microsoft's "Malware Dection Tool":

1. Disables system setting regarding Malware ... i.e. allows Malware instalation at the system level.

2. Disables program settingis regarding Malware ... browsers ... outlook (especially ! ) ... Word and Excel.

Looks like M$ is revieving big $$$ from Malware Industries to perputuate Malware !

-- 308

Re:Microsoft ... Malware Detection .... NO ! (0)

Anonymous Coward | more than 3 years ago | (#34448106)

Uh... Where does it say any of that in this article? The paper doesn't even say a thing about settings, much less "disabling" them.

Oh, my word...really unoriginal! (1)

hesaigo999ca (786966) | more than 3 years ago | (#34459172)

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 you answer you chose, will always be correct.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...