hackademix.net

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

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

with

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

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.

I’m pleased to announce that ABE, the Application Boundaries Enforcer meant to fight CSRF and related web attacks, has finally been included in a stable NoScript release: version 1.9.5, available here.

It’s been quite a long development journey since my first announcement, made possible by NLNet’s foresight, and it required more than one month of beta testing: among the thousands of testers victims I inflicted twenty builds upon, I must especially thank therube, GµårÐïåñ, Tom T., Alan Baxter, dhown and the other friends at the NoScript forum, who devoted their time to aid debugging and optimization. A special thanks goes also to Edoardo “Sirdarckcat” Vela, talented hacker and loyal NoScript fan, who offered many useful suggestions to model the threats which ABE can counter react.

Great but.. now that I’ve got ABE, what can it do for me?

If you’ve got latest NoScript version installed on Firefox 3.0.11 or another compatible Gecko >= 1.9 browser, you’ll notice a new “ABE” tab in NoScript Options|Advanced. There you can find a list of the loaded “Rulesets”, i.e. groups of firewall-like rules (syntax specification PDF).
Rulesets can be:

1. Built-in like the “SYSTEM” ruleset, shipping with ABE and meant to provide automatic protection against “general” threats; you don’t want to edit them unless you know exactly what you’re doing.
2. User-defined like the “USER” ruleset, which is empty for you to customize according to your needs.
3. Subscription-provided, coming from a centralized location which delivers “trusted” rules (not supported yet).
4. Site-specific, created and made automatically available by site developers or administrators to protect their own web applications.

All these rulesets (built-in, yours, centralized and site-specific) cooperate to properly insulate your most sensitive web applications and prevent them from being abused by unrelated malicious web sites.

Drop-in LocalRodeo replacement

The “SYSTEM” built-in ruleset currently contains just one rule definition:

Site LOCAL
Accept from LOCAL
Deny

This simple rule protects your local network from CSRF attacks coming from outside, for instance from a malicious web page trying to hack your router. If this scenario does not sound new to you, maybe you’ve heard of LocalRodeo, an experimental Firefox extension which was meant to defeat exactly this kind of internet-to-intranet threats. In facts, the default ABE configuration shipping with NoScript 1.9.5 and above is as effective as LocalRodeo at least, but more performant, especially when DNS queries are involved, and much more flexible, since it’s not limited to this specific attack scenario: if you’re using both NoScript and LocalRodeo, it’s time to uninstall the latter.

ABE for web authors

While centralized subscriptions aimed to protect the most popular web applications have been planned but are not implemented yet, you as a web author can already start experimenting how to protect your own web application by enforcing your own rules.
Just deploy your

file at the root of your HTTPS site and be sure to check Allow sites to push their own rules in the ABE options panel. This preference is initially disabled in 1.9.5, but this default will be likely inverted in next stable iteration, as soon as it gets enough testing.
More details here.

Looks like my follow up to Gareth Heyes’ Twitter Hack produced two effects:

1. Twitter guys closed their hole by requiring an additional basic HTTP authentication step to retrieve the friends timeline JSON feed. Well done, albeit still lacking as an anti-CSRF countermeasure, because if user already performed basic authentication for any reason during this session, the hack still works flawlessly (not sure about how likely this is, though).
2. Some readers complained about me slightly criticizing Adblock Plus’ new 3^rd party blocking, by calling it “rather inconvenient” (especially if compared with the new NoScript 1.8.8.95’s anti-hijacking protection which doesn’t require any script blocking), although I was actually praising the famous ad blocker as a countermeasure against this attack.
   Yesterday evening, when I wrote that post, I was overly tired from a very stressful week, so I fell in the trap of suggesting to use Adblock Plus for a security purpose. After some sleep, a bit more in my mind, I recalled why I always recommend Adblock Plus as a wonderful annoyance blocker, but not to be relied upon for security: there are too many easy ways to circumvent it.
   More in general, Adblock Plus and FlashBlock, despite a popular superstition, can’t be considered security tools because they’re not conceived nor developed with the necessary defensive and proactive paranoid mindset.

I updated my PoC to reflect both these events.
Now it “hijacks” Twitter’s public listings feed which, as the adjective “public” suggests, has no reason to be protected.
And this time Adblock Plus’ 3^rd party blocking won’t help :)

Some days ago my friend Gareth Heyes exposed an authorization bug in Twitter’s JSON interface, by writing a short post titled I Know What Your Friends Did Last Summer. Do not click on his PoC with JavaScript enabled, unless you want to find yourself bombed by a lot of alert boxes showing some interesting Twitter data about you and your friends.

For your convenience, I’ve reproduced a less annoying PoC here:

Notice/update: after some hours this article was out, Twitter secured its “friends timeline” feed. Therefore I updated this PoC to consume the “public” feed, still demonstrating the hijacking technique, albeit on a non-sensitive data set.

Twitter’s JSON feed is spied upon using __defineSetter__, a useful JavaScript extension introduced by Mozilla and now implemented in all the modern browsers (i.e. all the popular ones except IE). After redefining a property setter on Object.prototype, we can read the values being set when the feed is loaded through a <SCRIPT> element:

Object.prototype.__defineSetter__("user",
  function(value) { // do something with user's value }
);
<script src="https://twitter.com/statuses/friends_timeline/"></script>

The main problem here is, obviously, Twitter leaving this feed unsecured against cross-site requests, under the wrong assumption that it could be read only through XMLHttpRequest (which actually does not work cross-site). We can expect errors like this to be quite widespread, since so-called “AJAX security” is still in its infancy: consider that Twitter guys are not exactly newbies…

This JSON-hijacking technique won’t work if any of the following conditions applies:

• The feed provider (Twitter) secures its JSON to ensure 3rd party sites can’t access it (i.e. implementing any anti-CSRF countermeasure).
• The JSON payload is not enclosed in square brackets. If the JSON starts directly with curly braces, it gets intepreted as a code block, rather than an object initializer, and nothing happens.
• You’re using an antiquated browser (like IE).
• JavaScript execution is disabled on the attacker’s site (e.g. by using NoScript in its default configuration).
• You’re preventing 3rd party scripts from loading (e.g. by using Adblock Plus with its rather inconvenient 3rd party script blocking feature enabled). Forget it, too much easy to work-around :(
• You’re using NoScript 1.8.8.95 or above, even if you’re allowing scripts everywhere!

Yes, that’s right: in the best NoScript tradition, while there’s some ongoing work to prevent this kind of leakage from happening in next major version of Firefox, NoScript already provides a specific protection feature. Even better, this works even in Allow Scripts Globally mode, just like anti-XSS filters and the ClearClick anti-clickjacking technology, so you’ve got no excuse to stay unsafe.

P.S.:
another thing you can do for your Twitter security, especially if you use public wifi, is adding twitter.com to your HTTPS behavior forced list and enabling automatic secure cookies management, to defeat cookie hijacking attacks.

Update

Twitter fixed this issue by requiring HTTP authentication in order to retrieve the https://twitter.com/statuses/friends_timeline.json feed.
I’ll post a new innocuous didactic PoC fetching the public feed and circumventing Adblock Plus as soon as I’m done with breakfast.