Developing Security

Crossing the Border - JavaScript Exploits

Recently I had the pleasure of giving an OWASP presentation on JavaScript Exploits. I had some fun with the talk and compared countermeasures used to prevent JavaScript Exploits to Chinese border security.



I really appreciate all of the people who came out both in Ottawa and Montréal, and the feedback I received was really positive. A special thanks to the chapter leaders for making this possible.



If you are interested in giving a presentation to either of these OWASP chapters, they are always looking for volunteers. More information can be found on the Ottawa OWASP or Montréal OWASP pages.



Download the PDF (3.3 MB) or view the slides below (if your reader supports iframes).

Using Research Methods From HIV Studies to Protect Sensitive Data

As a vendor its useful to have information flowing back from the user base about encounters with exploits, malware, etc. As a customer, however I may not want anyone outside of my security department to know that we have been infected by the Conflicker Worm (at least until we have cleaned it up ...or covered it up).

How do I as a vendor, automatically collect usage data directly from a customer, while giving them anonymity? They are not likely to trust us if we simply say we don't look at the source of the information (after all we may have web-server or firewall logs that could correlate their source IP back to the data collected). Since the information is sent to us, customer by customer over the network how can we assure them that we divulge sensitive information?

To solve this problem, we can take a cue from the most unlikely source... the study of human sexual behaviors. In the late 80's when HIV/AIDS was becoming an epidemic, it was important for researchers to have a way of asking people questions they wouldn't want to admit to. These may be behaviors that were illegal or immoral and hard for a subject of a study to answer truthfully to an all to human research assistant sitting across from them. The answers however were important as researchers were trying to determine how the virus was spreading. A mathematician named Joel E. Cohen came up with an answer⁽¹⁾. His idea was to have each person flip a coin (or do some other random 50/50 generation). If they had done the illegal or immoral behavior they would ignore the coin and answer yes. If they had not, they would answer yes or no depending on the flip of the coin.

This gave the people answering yes (where they had actually done the illegal or immoral thing) anonymity, because many of the others would be answering yes too. Each subject had plausible deniability when answering yes. To get the actual average they would simply double the number who had answered 'No' (Which remember was about half of the people for which it was ACTUALLY no). In a large enough set this gave a accurate percentage. So if 20% had done the illegal/immoral thing and the half of the other were forced into answering yes, you would have around 60% saying yes. At the end of the study the No's would be doubled to come up with the real 80%/20% ratio.

So you can likely see where I'm headed with this... If I'm automating a usage statistic system that reports to me daily from customer environments that reports when a certain exploit or malware has been encountered I could simply have the program respond yes half of the time when it's no (very counter intuitive for a programmer).

As a vendor, if I did have malicious intent and decided to start snooping these reports I couldn't tell from a single customer report if the yes was real or not. I can't actually tell if any given customer has been infected by Conflicker. Once I put together hundreds or thousands of reports, I can double the No's and get the real ratio accurate to a few percentage points.

Now I only have to convince the customers of this :)

⁽¹⁾ It was later understood that others had used forms of random responses in previous studies including Fiddler and Kleinknecht (77), Dawes and More (80), and Fiering and Hooper (85)

Take Evasive Action

Javascript is an incredibly easy language to evade signature-based detection with. Because Javascript can dynamically execute instructions from strings, it's easy to use simple url/html escaping, base64 encoding, Unicode escaping, string concatenation and dozens of other techniques to obscure exploits from pattern-based analysis. The de-obfuscated code can then be injected into the page through document.write("..."), eval("..."), new Function("...") or event handlers anywhere in the DOM.

As DPI and Anti-Malware engines worked to factor out basic evasion methods, the attackers stepped it up using Javascript-based cryptographic algorithms, substitution functions, obscure options like Microsoft's Javascript encryption for IE and an ever evolving library of fragmentation techniques. Over in the Fortinet Blog David Maciejak points out that scanners that take a file-based approach can be evaded simply by deploying portions of the malicious attack in different files, since no one file contains the full exploit. Brian Prince at eWeek covered a new trend of using AJAX to pull portions of the exploit low and slow before finally running the reassembled exploit in code. This scary method would easily evade any form of network-based inspection by slowly passing fragments as small as a few bytes. To make it worse, many of these techniques can be combined and exploits can be randomly obfuscated for each request.

Ultimately there is no way to reliably stop Javascript exploits with signatures.

This problem has researchers and developers thinking laterally about innovative ways to solve the issue.

In 2005 a team at Microsoft began work on a technique they called BrowserShield. It essentially re-wrote an incoming page and wrapped the scripts with a safety function that would, in essence be its own mini-IPS, capable of evaluating the script for malicious intent. The same thing could likely be accomplished in Greasemonkey for Firefox. While this technique showed some merit there are issues involved with re-writing the original content. The page itself may not function correctly if it was using reflection, dynamic code generation, or odd Javascript quirks like arguments.callee. Latency is also an issue anytime content is proxied and altered and it's unclear how many of the vulnerabilities in a browser could really be mitigated by this technique after all, the vulnerabilities could be in the Javascript interpreter itself. 

In 2007 researchers from Google automated an instance of Internet Explorer inside a Virtual Machine. They performed a fingerprinting of the file system and registry before and after visiting URL’s from Google’s database. The technique was successful in identifying URLs that loaded malicious code onto the operating system. They found that, in paged with possible indicators of malicious intent, ten percent of the pages engaged in drive-by downloads. The same technique is used in Capture-HPC (part of The Honeynet Project) to instrument a variety of client browsers, productivity applications and multimedia applications. Due to the size of the Internet, the only conceivable way to maintain this type of bad list is a central service. A service of this nature, like Google's Safe Browsing API, is a step in the right direction but has many caveats. Like all forms of bad URL blocking (for example phishing sites) the information is quickly out of date. Malicious sites are rotated in and out every minute and legitimate sites can be compromises at any time. Besides lagging coverage of sites, this technique also is blind to authenticated or private content. It's also troubling that this technique only accounts for instances where the exploit made detectable system alterations. In the case of information leakage or rootkits the changes may not be visible. Trend Micro's Web Threat Protection augments this by including factors like a site’s age, any historical location changes, and other suspicious behavior.

If sanitizing script is too risky and blocking malicious URL's is spotty, there is always the big-stick method of NoScript. I swear by NoScript myself. Since its inception in 2006, NoScript has become a very comprehensive tool for protecting yourself when surfing. The problem with relying on it as a wide spread mechanism for the non-technically inclined is the potential for desensitized click-through (like those pesky SSL warnings). Users could fall into a behavior of automatically setting 'Allow All On This Page' every time the bar pops up or the page looks wrong. It also does nothing to prevent you from being infected by legitimate sites you choose to trust or sites you already trust that have since been compromised. Unfortunately well known sites being hacked to server up exploits is a constant reality.

Another approach, that can be implemented without user interaction is heuristics on the Javascript using a flow rather than file-based approach. A DPI engine can look for suspicious characteristics of the content, such as specific code-injecting functions, apparent regions of obfuscated strings (by density, length and spacing characteristics), patterns of crypto functions, AJAX bootstrappers that execute code, and the like. This significantly adds to the ability to do realtime detection and prevention but may result in false positives in a Web 2.0 world that legitimately uses many of these techniques when creating the dynamic web. Even looking for regions of obfuscation isn't safe due to its use in IP protection and bandwidth savings of increasingly script-heavy websites. As a detection mechanism, this works well, but in prevention the chances of false positives are very high.

While all of these methods help in the fight against Javascript exploits, no single method is the answer.

I would like to hear from you, what other techniques are being tried to face this threat?

(Reposted to fix the formatting)