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

As a result of recent changes in Xmarks you may experience some problems if you’re also a NoScript user.

Xmark’s login dialog and setup wizard ask you to “Allow JavaScript on login.xmarks.com”, or directly come out broken as HTML source. You cannot exit the dialog (the browser seems stalled), and even if you manage to, you discover that allowing login.xmarks.com or even the whole xmarks.com does not help.

The solution

1. Use the “Esc” key to exit the dialog
2. Click the NoScript icon and look in the “Recently blocked sites” submenu.
3. Select Allow googleapis.com, Allow xmarks.com or both (whathever you find there).

Alternatively, you can open NoScript Options|Whitelist and manually allow xmarks.com and googleapis.com. Looks like the Xmarks folks overlooked the need of allowing the latter.

Extensions developers!

More in general, extensions developers who need some web site to be allowed in NoScript for their extension to work, may want to use some code like this:

Well, already a dozen requests today only.

Unfortunately, Safari 5’s support for extensions looks even more limited than Chrome’s.

So, no NoScript (nor FlashGot, nor any half decent ad blocker*, for the matter) as a Safari extension for the foreseeable future…

* Looks like ad blockers are actually possible, see Dave Hyatt’s comment below. Documentation of this feature is deeply buried inside a completely unrelated “Messages and Proxies” chapter, but whatever. NoScript is a very different beast though, and infrastructure to port just does not exist (yet?) :(

On his blog, Wladimir Palant complains about Google providing browser users with a not effective enough way to opt-out from Google Analytics.

Specifically, he doesn’t like how the Google Analytics Opt-out Browser Add-on actually allows Google Analytics scripts to load and run, just setting a global variable (

) in the hosting page which tells the code not to send back data.

This approach is inherently flawed, because the hosting page can easily force Google Analytics to run by simply overwriting the aforementioned

variable.

Worse, the

variable is automatically added to every single page you load. Hence, the fact itself you’re using this “opt-out” add-on can be easily detected if you keep JavaScript enabled, adding some extra points to your unanonymity score. Something like

can make a nice test to update the Panopticlick suite with, singling out privacy concerned persons.

However, the original sin is that the Google Analytics’ script still being downloaded and executed, and if you find this questionable from a security/privacy perspective, then the Google’s Analytics Opt-Out Browser Add-on serves no purpose.

Wladimir’s post initially advertised his own extension as a better solution, but later he had to retract:

Still, until Google can come up with something better I recommend people to use Adblock Plus with EasyPrivacy filter subscription, that’s the easy and reliable solution (check the update below).

Update: Sorry, that last part wasn’t entirely correct — EasyPrivacy doesn’t block Google Analytics script either, due to many websites being broken without it as mentioned above.

True, if you block Google Analytics’ script by using a proxy, a firewall, a host file or Adblock Plus with an ad-hoc filter, many sites are going to break because they depend on JavaScript objects provided by Google Analytics. They integrate GA calls within essential functionality, such as link and button event handlers or even initialization routines, and they fail more or less dramatically when the script is missing. Sad, silly but true.

This is no news (and no problem) at all for NoScript users, though: in fact, almost one year and half ago, this very issue prompted the development of NoScript’s Script Surrogates feature, which prevents the breakage by “emulating” the blocked script with dummy replacements. This means that NoScript users have Google Analytics blocked by default, with no site-breaking side effects.

So, until Google can come up with something better I recommend people to use the reliable and easy solution ;)

I’m receiving several reports by Ubuntu and Debian users having their desktops crashed as soon as they click the NoScript icon. Yes, your whole session gone, back to your logon page in one move!

Actually this may be triggered by different actions, not necessarily with NoScript installed, or reportedly just by having a long/complex enough interaction with Firefox.

It turns out to be a bug in the xorg-server package, which Ubuntu’s maintainers deemed not worth to get fixed before releasing Lucid Lynx.

My understanding is that a fix will be included in next automatic update, but in the meanwhile you can apply the available patch from Bryce Harrington’s PPA by issuing the following commands in a terminal:

Update

I was sure I had this crash reported by Debian users as well, but when some of them commented here that they couldn’t reproduce it, I double checked and could find Lucid Lynx reporters only. Better so.