Archive for the XSS Category

Senior NoScript community contributor Grumpy Old Lady finally sent me a link to these notes, taken live at BlackHat USA during Graig Heffner's "How to Hack Millions of Routers" talk, and to the tool he released, allowing to remotely control the many models of routers found vulnerable to a specific kind of DNS Rebinding attack.

Since I couldn't attend the L.A. conference, I've been anxiously in search of something like that to confirm al_9x's speculative forecast, i.e. that the exploited vulnerability was about routers exposing their administrative interface to the LAN on their WAN IP (even if remote administration is explicitly disabled), and now I'm delighted to find he was entirely correct!

Of course I must be happy, because I don't need to rush out another ABE feature like the WAN IP protection which I baked inside NoScript 2.0 last week, and because my own home router had been vulnerable as well :)

Some clarifications are still needed, though.

Among the mitigations reportedly enumerated by Heffner (even if he had previously claimed that NoScript couldn't help), there's

Use NoScript (disable javascript?) Maybe not practical to most users

Now, it is true that Heffner's attack fails if the attacker's domain, bound on the fly to user's WAN IP, is not allowed to run JavaScript (very likely, when you use NoScript). This means that most users of older NoScript versions (1.10 and below) were already protected against Heffner's tool and this kind of "XSS via DNS Rebinding".

However, like for many other "emerging threats", NoScript provides a specific protection against this class of vulnerabilities (in this case via its ABE module), completely independent from script blocking: in other words, it just works, no matter if you decide to keep JavaScript, plugins and frames enabled everywhere ("Allow Scripts Globally"). There'no reasonable excuse to renounce this protection, since it does not imply the alleged "non-practicality" of enabling JavaScript selectively.

So, since security experts themselves sometimes seem confused about NoScript's real "convenience vs security" tradeoffs, taking for granted that all the security it offers depends on and requires script blocking, recapping here a (non exhaustive) list of attacks blocked by NoScript even in "Allow Scripts Globally" mode may be useful:

  1. XSS, thanks to its "Injection Checker", the first anti-XSS filter ever released in a web browser.
  2. Clickjacking -- NoScript's ClearClick feature is still the only effective protection entirely implemented inside the browser and requiring no server-side cooperation.
  3. CSRF (and especially, by default, cross-zone attacks against intranet resources) via the ABE module.
  4. MITM, courtesy of HSTS and other HTTPS-enhancing features

These are just some of the many additional protections provided by NoScript which do not depend on scripting being disabled. So next time you hear people saying "yes, browsing with NoScript is safer but having to pick trusted sites to run JavaScript is a pain", point them to these good reasons for running NoScript, even if they give up the extra security provided by plain old script blocking.

As you probably know, the details about the paradoxical behavior of the Internet Explorer XSS Filter, introducing XSS vulnerabilities of its own on otherwise immune web sites, which we hinted at some months ago, have been revealed by Edoardo "Sirdarckcat" Vela and David "thornmaker" Lindsay recently at the Black Hat Europe conference, in Barcelona (on a side note, looks like Sirdarckcat enjoyed his stay there so much that he decided to remotely hack a certain volcano...)

I've been quite disappointed by the preamble of their paper, which calls IE8's XSS filter a new type of defense and a somewhat novel approach (before bashing it), when we all know that NoScript came first. Sirdarckcat personally apologized, blaming Lindsay for this and other "pro-big-players" bias, such as the decision of omitting, from the comparative table in their slides, Sirdarckcat's opinion about NoScript's being the safest among the in-browser filters and the hardest to bypass.

Notwithstanding, the technical core of this research is very worth reading, if you're interested in XSS attack and defense techniques.

After the Black Hat debacle got echoes in the press, David Ross, the main XSS Filter engineer at Microsoft, published a Guidance on Internet Explorer XSS Filter document on the Microsoft Security Response Center website, announcing a not better specified "patch" coming in June (mmm, two whole months? need some help?) and making two interesting statements:

In the case of the Internet Explorer XSS Filter, researchers found scenarios that are generally applicable across XSS filtering technologies in all currently shipping browsers with this technology built-in.

This essentially means just two, IE8 and Chrome... but wait, Chrome doesn't ship with its XSS Auditor enabled anymore because it was dog slow!
Hence the final recommendation by Ross...

Overall we maintain that it’s important to use a browser with an XSS Filter

... can really mean one thing only: Microsoft maintains that it's important to use Firefox with NoScript :)

Update Jul 29 2010

This "feature", eventually publicized by Sirdardckcat and Thornmaker, allowed Microsoft to win the BlackHat 2010 Pwnie award for the "Most Epic FAIL":)

Internet Explorer 8's famous XSS filter can be exploited to perform successful XSS attacks against web sites which would be otherwise safe. In other words, XSS "protection" is helping XSS attackers, oh the irony.

Well, this is not exactly news among security researchers, but those aware of the details (including Microsoft of course, Eduardo "Sirdarckcat" Vela and myself) have kept a low profile so far. Check, for instance, slide #17 in my OWASP presentation (alternate link), given two weeks ago.

However, after Microsoft left it unfixed for many months, someone apparently decided to whisper this dirty little secret in Dan Goodin (The Register)'s ear.

To Microsoft's credit, this problem has no quick fix: in fact, it's way worse than a simple implementation bug. Its root is a flawed design choice: when a potential XSS attack is detected, IE 8 modifies the response (the content of the target page) in order to neuter the malicious code. This is, incidentally, the only significant departure from NoScript's approach, which modifies the request (the data sent by the client) instead, and is therefore immune.

Anyway, here's the juice: IE 8's response-changing mechanism can be easily exploited to turn a normally innocuous fragment of the victim page into a XSS injection. The attacker just needs a certain degree of control on the content of the web site to be injected: social networks, forums, wikis and even Google Apps are good prey. To be fair, Google Apps are not vulnerable anymore, since Google's properties wisely choose to deploy the

X-XSS-Protection: 0

header, which is the "safety switch" disabling IE 8's XSS protection.

So, web site owners' dilemma is, opt out or not opt out?
For browser users, there should be no dilemma at all ;-)

Strict Transport Security (STS) has gone live on PayPal yesterday.

STS is a simple yet effective system for web sites requiring high safety levels, e.g. payment gateways or financial institutions, to force HTTPS connections on every request originated by supporting browsers.

It is currently supported by NoScript, Chrome 4 beta and Sid Stamm's Force TLS.

Together with NoScript's anti-XSS protection, this feature makes PayPal a much safer service for NoScript users.

When Microsoft unveiled its IE 8's "XSS filters", almost one year ago, we could notice how, despite their impressive resemblance to NoScript's anti-XSS protection, they were quite limited in comparison.

One of the limitations was their ability to mitigate a subset of reflective (AKA type 1) XSS vulnerabilities only, leaving them totally useless against DOM-based (AKA type 0) XSS attacks which, instead, are effectively defeated by NoScript.

Today I noticed via that such a DOM-based XSS attack is currently possible against Paypal and Ebay, no less, allowing the attacker to steal authentication info and other sensitive data, or even perform financial transactions on the behalf of the victim.

Even more interesting, modern browsers* except IE properly encode request URLs before sending them on the wire, but exploitation of this specific Paypal vulnerability requires the "double quotes" character to pass through with no encoding: therefore, while the vast majority of XSS exploits are cross-browser, this one affects exclusively IE**. Embrace and XSStend?

  1. * Latest versions of Firefox, Safari, Opera and Chrome.
  2. ** Variants could affect any browser, since IE's encoding bug is generally not required for DOM-based XSS. Firefox users can protect themselves by using NoScript, even in the permissive and not recommended "Allow Scripts Globally" mode.

Bad Behavior has blocked 1265 access attempts in the last 7 days.