Archive for the CSRF Category

NSA++, NoScript on Android

NSA++ (NoScript Anywhere Plus Plus, or NoScript 3.5 alpha for Android Native) has been in the works for a while now, and it’s finally ready for prime time, thanks also to the continuous help of the NLNet Foundation.

Even if it’s not as complete as its legacy Electrolysis-orphaned obsolete predecessor (NSA, designed for the now discontinued XUL Fennec, AKA Firefox 4 Mobile) yet, NSA++ already provides the best security you can get in any mobile browser: beside its trademark flexible script blocking facility, it features the first ever and still strongest XSS filter available, plus partial but functional portings of the unique ClearClick anti-Clickjacking technology and ABE’s firewall/LAN CSRF protection.

You can read more or try it with a recent Firefox Nightly (mobile or desktop, too!) on the NSA project page.

NoScript 2.0.4 has been released yesterday, with some bug fixes and one main addition: strict X-Content-Type-Options: nosniff enforcement.

NoScript, for a long time, had already being enforcing content type checks on cross-site Javascript and CSS includes, and recent Firefox versions introduced similar built-in mitigations, albeit limited to stylesheets, in order to mitigate CSS-based data theft.

Nevertheless, X-Content-Type-Options offers a nice opportunity to further hardening, by allowing web sites to opt-in for the strictest checks, on more file types and also same-domain, in a theoretically compatible way.

A side effect of this addition is that Firefox 4 + NoScript now scores 14/16 on Browserscope’s Security Test, in “Allow Scripts Globally” mode (i.e., without blocking any JavaScript or active content)!
Browserscope Security Test
For those who don’t know it, Browserscope is a project which aims at profiling and comparing browser capabilities, with a special eye for security features.

By comparison, only Google Chrome boasts a higher score of 15/16, because it supports both the HTTP Origin Header and the HTML 5 Sandbox Attribute, which are not implemented yet by Firefox nor by NoScript. For the curious, “vanilla” Firefox 4 nightlies stop at 11/15 (even if you’re going to read 12/15 because of a XSS test bug), Firefox 3.6.12 + NoScript is at 13/15, while disabling NoScript makes it fall down to 9/16 (reported as 10/16 because of the aforementioned bug).

However, a fair comparison would need to cover also Content Security Policies, a very powerful and flexible security technology developed by Mozilla (test should be added soon, it seems) and countermeasures for cross-zone CSRF attacks (e.g. against routers), which are currently provided by NoScript and, partially, by Opera (Mozilla is working on something, too)*. If and when these features get tested, Firefox 4 + NoScript will lead at 16/18, followed by Chrome at 15/18.

That said, I’d really love to see Origin and Sandbox implemented natively by Firefox, for a perfect 18/18. Which is, I guess, the real raison d’être of Browserscope: getting good stuff implemented everywhere by the power of childish envy ;)

* I won’t advocate including tests for other non-blocking security features provided by NoScript, such as ClearClick anti-Clickjacking, because they’re not suitable for web-based automation.

Update 2010-11-13

Firefox 4 + NoScript scores 15/17 now!

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.

Web-based router hacking is hardly a new topic, but new variants pop up from time to time.

The most obvious attacks against a router which malicious web sites can pull are CSRF, XSS and DNS Rebinding. Of course changing the default password of your router helps mitigating these threats a lot, but unfortunately it’s not enough if you happen to be already logged in the administrative console, or if your device is affected by any of the commonplace holes which are left open by an unsafe development attitude, on the flawed assumption that just because a vulnerable service is not exposed on the internet side it can’t be reached by an internet attacker (see this HNAP D-Link Hack for a glaring example).

NoScript’s ABE module has been protecting routers and intranet web resources against this kind of attacks for a long time, thanks to the following built-in SYSTEM rule:

# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny

However security researcher Craig Heffner, interviewed by Andy Greenberg on his “The Firewall” Forbes blog, recently announced a new DNS Rebinding variant which can be used to remotely control your router and (the scary part) allegedly bypasses the defenses provided by NoScript against this class of attacks.

Even though the details are still to be presented — together with an automated attack tool! — at the BlackHat USA 2010 conference (today or tomorrow), al_9x, one of the most active members of the NoScript community, provided a very convincing speculative assessment of the new threat, based on the sparse data found in this briefing summary, and also a simple and clever suggestion for a remedy:

Many routers will respond to requests to their public ip on the private interface. This allows an external site not merely to load the router config in an iframe by ip (without triggerring ABE LOCAL rule) but also by the site’s name (by dynamically dns binding it to the router’s public ip), thereby bypassing same origin check and gaining access to the router.

I suppose NoScript could (optionally) lookup the public ip and include it in the abe LOCAL pseudo-list.

And so it does now :)

Since version 2.0rc5, released past week, NoScript detects your public (WAN) IP by sending a completely anonymous query on a secure channel to https://secure.informaction.com/ipecho, then treats it as a local address when enforcing its policies against CSRF and DNS Rebinding.

There are a few optimizations, meant to reduce the traffic to less than two hundreds of bytes per user per day (and prevent my servers from melting down), but if you do notice this background request, now you know what it is about (it is also mentioned in the NoScript’s Privacy Policy, BTW). This new feature, enabled by default, can be disabled at any time by clearing the NoScript Options|Advanced|ABE|WAN IP ∈ LOCAL checkbox *.

Now, let’s just hope al_9x’s guess is correct.
I’m quite confident it is, but if it’s not, expect a brand new ABE protection feature in a week or so, anyway :)

Update

Looks like al_9x was entirely correct, indeed :)

* Note for network administrators

This feature tries to be nice: device fingerprinting can be turned off by sending a “X-ABE-Fingerprint: Off” HTTP header, and fingerprinting requests are identified by a “Mozilla/5.0 (ABE, http://noscript.net/abe/wan)” User-Agent header. Furthermore, custom local subnets or IPs can be configured as a space-separated list in the noscript.abe.localExtras about:config preference.

Many people use their hosts file for resources blocking purposes, especially against ads or known malicious sites.

Since your hosts file takes precedence over your DNS in domain name resolution, you can redirect undesired domain to invalid IP addresses, saving both bandwidth and CPU because resolved IPs are cached.

Unluckily, most information sources about this useful technique, including the Wikipedia article above, instruct the reader to use 127.0.0.1 (the local loopback IP) as the dead-end destination, rather than a truly invalid address such as 255.255.255.0. This is not very smart, especially if you installed a web server on the loopback interface (like many web developers do), because you’re spamming it with dummy requests whenever you browse an ad-laden web site.

Furthermore, I’m currently receiving several reports about ABE warnings popping up everywhere. If you read my post about ABE yesterday, you know that it ships with a built in “SYSTEM” ruleset containing just one rule which alone implements the whole LocalRodeo functionality:

# Prevent Internet sites from requesting LAN resources. Site LOCAL Accept from LOCAL Deny

Such a rule blocks any HTTP request for resources placed in your local network, including localhost (127.0.0.1) and any other LAN IP, unless it is originated from your local network as well. This protects your internal servers and devices (e.g. routers and firewalls exposing web interfaces) against CSRF and XSS attacks performed from the internet.

As a side effect, though, if you’re redirecting arbitrary hosts to 127.0.0.1, you’ll get bombed by a storm of ABE warnings whenever those sites are linked from external web sites. The solution is simple: just open your host file and replace

127.0.0.1

with

255.255.255.0

everywhere it’s used to block something, but being careful to keep

127.0.0.1

on the

localhost

entry and other really local domains, if any.

Update:

NoScript 1.9.5.5 beta automatically suppresses notifications for the commonest case covered here (HTTP requests for a domain name resolving to 127.0.0.1 on the default port), and also introduces an option to disable all ABE notifications.

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