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.

32 Responses to “ABE Patrols the Routes to Your Routers”

  1. #1 AnonymousCoward says:

    Kudos al_9x ! The annoying ;-) bug-finder strikes again!
    May you continue to hassle Giorgio like this :-)
    And thanks Giorgio for a very clear explanation of your actions and motivations making the fix.
    All solutions vendors should take a leaf out of your book.

  2. #2 Anonymous Coward #2 says:

    Am I mistaken or is your server already paying the price of your generosity? ;)

  3. #3 Paeniteo says:

    Could the ipecho-URL be made configurable (or is it, already)?
    I (along with many other NoScript-users, probably) could easily run an appropriate script on a private server (or cater for some other means of providing the WAN IP in response to some http(s) request).

    - Paeniteo

  4. #4 Adam says:

    What if I'm behind a proxy? My isp works this way. My external ip is like 123.176.x.x. My local router has a fairly common ip, 192.168.1.1. So what would noscript detect? I can manually change my ip to match my router, or would simply disable this feature if I'm safe (since I'm behind a proxy?). Just curious.

    @#2: It kinda looks like it, the css stylesheet didn't load the first time

  5. #5 Giorgio says:

    @Anonymous Coward #2:
    Yes, it's been quite a hot day for my servers (I had to setup a DNS round-robin on the fly, and it's not balanced enough yet).

    @Paeniteo:
    The ipecho URL is configurable, just edit the noscript.ABE.wanIpCheckURL about:config preference.

    @Adam:
    This feature gets automatically disabled if a proxy is detected.

  6. #6 Thomas says:

    I hope this program can fix internet problems itselves

  7. #7 Cesar says:

    (I tried to post this while the last comment was still comment #4, but the site kept returning errors.)

    What if I am behind a double NAT? My router is at 192.168.x.y (internal) and 10.x.y.z (external), but your site will return 200.x.y.z to noscript. Which will protect the outer NAT router, but not the inner one.

    This will only become more common with the coming IPv4 exhaustion.

    Also, what if the router IP address changes several times per day? (At home in the morning, at work and/or school in the middle of the day, at home in the night.)

  8. #8 Cesar says:

    @Giorgio:

    > This feature gets automatically disabled if a proxy is detected.

    Why not keep it enabled and protect the proxy's router instead? Not only does the proxy (if it is within a private LAN) make its router vulnerable to the claimed attack (after all, the HTTP requests will all come from the proxy), but also it is quite probable that both the proxy and the browser are in the same network.

    And what about transparent proxies? How do they affect this feature?

  9. #9 Giorgio says:

    @Cesar:

    Your inner router was already protected by old ABE's LOCAL pool matching all the private IPV4 and IPV6 reserved addresses.

    Also, what if the router IP address changes several times per day?

    This feature fingerprints your router and checks for changes every 5 minutes. Whenever a change is detected, or you go offline then back online, or you suspend your PC then resume it, or you restart your browser, or every 24 hours, the WAN IP is detected again on the assumption it may have been reassigned.

    Regarding the proxy, to be precise WAN IP protection gets disable while your connections are detected to be made via an external (Internet) proxy. If your proxy is internal, it keeps working on the assumption the internet facing IP belongs to your router and may need protection.

  10. #10 AnonymousCoward says:

    After your self-induced DOS is fixed, Console tells us that secure.informaction.com server does not support RFC 5746. An artefact of load balancing I guess.
    Not actually worried for our own use of your ABE WAN feature, but is the insecure re-negotiation going to affect confidence in version downloads from secure.informaction.com?

  11. #11 Giorgio says:

    @AnonymousCoward:
    Almost no server support RFC 5746 yet (web servers should catch up soon), but anyway the TLS negotiation vulnerability is not relevant at all for this service, since it doesn't use any user-provided information from the application layer.

  12. #12 Bill says:

    I have used NoScript for many months, along with a software firewall (ZoneAlarm Pro 7.x) which also provides script-filtering.

    That combination protects me even when I can't use Firefox (using those few applications that are hard-coded to IE)... although managing the double-layer has been mildly annoying.

    Since upgrading to NoScript 2.0, I am getting random script warnings from ZAPro, even when all apps (including Firefox) are idle. These "attacks" all appear to emanate from my router's WAN IP address... and, they appear to occur at approximately 5-minute intervals.

    Are these likely to be produced by your every-5-minutes router fingerprinting?
    How can I verify the actual source, since to the outside world, these "attacks" are coming from my own IP address?

    Might they actually be coming from my router itself? (made by ActionTec, if that helps)

    Since ZoneAlarm no longer offers script-filtering in current versions, I've been thinking of adopting NoScript-only filtering... but, that doesn't help those IE-hardcoded apps.

  13. #13 Giorgio says:

    @Bill:
    If it's exactly every 5 minutes then it's almost surely the periodic fingerprinting from ABE.

    Would you show me the exact message you get from ZA?

  14. #14 Bill says:

    (sent screen-shots via email)

  15. #15 Giorgio says:

    @Bill:
    Answered by email, but in short ZA is detecting the JavaScript code of your router's administrative interface being fetched in background by ABE's fingerprinting routine. Nothing to be worried about.

  16. #16 John says:

    [quote] 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. [/quote]

    1/ With your new feature off, will Noscript be protecting us if we don't allow iFrames even from same origin? This way the attacker site cannot load the router interface...can it?

    2/ Do you know how this vulnerability can be fixed globally on one's computer? (instead of just Firefox being protected, since NoScript is an addon)

    3/ Can someone be affected by just being idle with no internet application active? (by being spotted by some automated bot or whatever)

    BTW, thank you for the neverending perfectionism that you put into Noscript and customer support :)

  17. #17 John says:

    I suppose that modems are unaffected, right? (assuming Sagem F@st 800-840 are modems and not routers)

  18. #18 James says:

    Giorgio, is the answer about the ipecho URL you gave at #5 correct?

    You said to alter noscript.wanIpAsLocal.checkURL but I don't have that.

    Instead, I have noscript.ABE.wanIpcheckURL. Did something get changed or are these two different options?

  19. #19 Giorgio says:

    @John:

    With your new feature off, will Noscript be protecting us if we don’t allow iFrames even from same origin? This way the attacker site cannot load the router interface…can it?

    If it gots scripts enabled it can, by using XMLHttpRequest, because after DNS rebinding he's same domain and the Same Domain Policy doesn't block him.

    Do you know how this vulnerability can be fixed globally on one’s computer? (instead of just Firefox being protected, since NoScript is an addon)

    You can make your external IP not routable from inside the LAN, but it's not trivial for the average user and may be very complex if you've got a dynamic IP.

    Can someone be affected by just being idle with no internet application active? (by being spotted by some automated bot or whatever)

    Generally speaking no, because you need to load the attacker web page in order for the attack to begin.

    I suppose that modems are unaffected, right? (assuming Sagem F@st 800-840 are modems and not routers)

    It depends on how "smart" they are. If they offer a web-based administrative interface, they may be vulnerable.

    @James:
    The correct option is the one you found, noscript.ABE.wanIpcheckURL. My fault, I've corrected also the original comment, thanks.

  20. #20 piran says:

    @Giorgio:
    My server has a transparent proxy and uses a static IP.
    Port 445 (https) is not opened externally eg to the internet.
    Would it assist things if I put my own static IP into...
    1) workstation's M$ hosts file and/or
    2) NoScript|Advanced|HTTPS|Behavior|force site to use HTTPS

  21. #21 Giorgio says:

    @piran:
    1) hosts file won't help, because you can't "redirect" an IP -- only a domain name.

    2) It would be OK (HTTPS port is 443, though)

    However if your proxy is transparent, i.e. Firefox is not aware of it, ABE will keep working as intended.

  22. #22 Adam says:

    Turns out I'm not behind any proxy after all. Noscript correctly detects my routers external ip. I'm pretty sure I used to be behind a transparent proxy (I remember wikipedia reporting as such). Thank you for your generosity

  23. #23 DareDeMo says:

    Something else noticed after upgrading to 2.0: with NoScript enabled, when starting up Firefox, netstat -a notes a brief http connection out and established to a1plpkivs-v03.any.prod.ash1.secureserver.net . Is this related? If not, what might that be?

    Thank you for all of the work you've put into NoScript & keeping us well protected from so many potential pitfalls that are out on the net.

  24. #24 Giorgio says:

    @DareDeMo:
    I'm almost sure it's not related.
    All you should see is a HTTP connection to ocsp.godaddy.com (Firefox checking the SSL certificate of secure.informaction.com agaisnt GoDaddy's CA) and a HTTPS connection to secure.informaction.com.

    Are you sure this goes away if you disable NoScript and comes back when you enable it?
    Have you got an home page opened at startup?

  25. #25 spirat says:

    Thanks guys. I was wondering what the new DNS rebinding attack was about, that's a clever guess.

    This kind of attack will be now useless with NoScript, but only for the external router. I believe that some corporations host their own web servers at the same place, on the same network they connect their employees. So ultimately, a road may be traced through the firewall via a DNS Rebinding attack, even with NoScript.

    To address this potential threat, why not allowing the user to set manually the IPs of not only the external gateway, but also all the hosts accessible on the same network having other(s) IP(s) on other(s) subnet(s) ?
    This would permit to have more control and would address too the problem of the external proxy. Am I wrong ?

  26. #26 DareDeMo says:

    @Giorgio:
    Sorry to have asked the question and then dropped off the face of the earth there. 93 hours last week and am cresting 60 already this week. Ack.

    Pardon the lengthy reply below – I can take this offline if it would be better than flooding this board, & if you’re game.

    Setup – 2 different VMs, each running Server 2003. One with Firefox 3.6.8 + NoScript 2.0, Firebug 1.5.4 & Web Developer 1.8 add-ons. One with NoScript 2.0 & Web Developer 1.8 add-ons. Each use a blank page upon Firefox startup.

    Between the two, the experiment results are consistent:

    A:
    run netstat –a, see that it’s clean, turn on Firefox w/ NoScript 2.0 enabled, fire off netstat –a again within seconds of having started Firefox, see that netstat reported connection out to a1plpkivs-v03.any.prod.ash1.secureserver.net briefly.

    B:
    Next, disable NoScript, turn off Firefox, netstat (clean), turn on Firefox, netstat a bunch of times – clean / no ‘*.secureserver.net’ line.

    As a different experiment, I rolled one VM back to a snapshot prior to upgrading NoScript to 2.0. No *.secureserver.net oddities observed when fiddling with netstat & Firefox at load. Then installed 2.0 and that crazy guy was back in existence each time Firefox starts unless NoScript is disabled.

    So, I trotted out a third VM, also Server 2003, with Firefox 3.6.8 on it w/ Firebug 1.5.4 and Web Developer 1.8. NoScript is also on it, but I’d left it at version 1.10. Like the roll-back experiment, with NoScript either enabled or disabled, *.secureserver.net doesn’t make an appearance.

    Anyhow, I anticipate having more time toward the middle of next week to continue exploring this. I can snapshot that 3rd VM, upgrade NoScript to 2.0 and see if it joins the ranks. May be able to see what Fiddler 2 has to say as well during the various scenarios.

    Again – thanks for all of the work you’ve done with NoScript as well as casting your eye toward this bit of weirdness my paranoia had me stumble across. ;)

  27. #27 Giorgio says:

    @spirat:
    It's gonna be implemented as an about:config preference (it's for networking-aware people, after all) in next release.

    @DareDeMo:
    Nothing to be worried about: n1plpkivs-v03.any.prod.ams1.secureserver.net, despite its scary shape, is just the same as ocsp.godaddy.com, which is queried by Firefox to validate secure.informaction.com's SSL certificate:

    > dig ocsp.godaddy.com
    [...]
    ocsp.godaddy.com.akadns.net. 36 IN      A       188.121.36.239
    
    > dig n1plpkivs-v03.any.prod.ams1.secureserver.net
    [...]
    n1plpkivs-v03.any.prod.ams1.secureserver.net. 3319 IN A 188.121.36.239
    
  28. #28 DareDeMo says:

    A-ha!

    When I'd pinged a1plpkivs-v03.any.prod.ash1.secureserver.net, I'd gotten 72.167.239.239 last week... but last night I spaced and didn't ping ocsp.godaddy.com to compare. Result: in my neck of the woods, that turns into ocsp.godaddy.com.akadns.net & resolves to 72.167.239.239 as well. Cool beans.

    Thanks for getting me back on to the straight and narrow -- have an excellent weekend!

  29. #29 Peter says:

    Hi Giorgio,

    thanks a lot for this new feature! Very nice :-)
    And general thanks for noscript! Firefox without noscript is like a dog without a bone.

  30. #30 c calver says:

    seems like this new feature is seen by my 3Com OfficeConnect router firewall as a Land Attack - but only by my note books that use Intel Pro Wireless - not the single one I have that uses a Broadcom chip - is that a good or bad thing? Any way when I saw this I was not a happy bunny as I try very hard to keep my pcs clean and was wondering what was up and how it happened - especially as I had just installed a new harddrive and fresh Xp in one and this pc was so behaving

  31. #31 CISO says:

    Scan your networks now, make sure your DNS servers are responding well,
    and make sure they do NOT answer to anyone at the world,
    want to know why it's important? read here:

    http://sites.google.com/site/dnslocator/

  32. #32 Lee says:

    hello, i use no script all the time in fact when i install a browser its the first thing i do to add NS.
    I came here from a google search "what does a website requesting lan resources mean". ABE stopped a website from applying something though what i dont know, the site was http://www.cluesforum.info/ i jus went back to get the link and the warning has gone, can someone tell me (a total idiot) what has happened please?.

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