"DNS rebinding" bypasses ABE LOCAL & same origin protection

[Giorgio Maone]

BTW, I'm baking an experimental implementation of al_9x's idea using http://ipecho.net/ as the echo service.

Afterthought: better not relying on 3rd party services, because if the site gets hacked or is ran by malicious people they could interdict ABE's users access to any popular site of their choice or, viceversa, make them selectively vulnerable to cross-zone CSRF attacks by designating a site under their control as "local" to everybody.

I should really use https://secure.informaction.com/ipecho/ for this, but I'm afraid it would melt down

[al_9x]

In case dyndns (or other 3rd party services) have a problem with this, can you ask Mozilla for this echo?

[Giorgio Maone]

In case dyndns (or other 3rd party services) have a problem with this, can you ask Mozilla for this echo?

I'm gonna try.

[dhouwn]

2 thoughts on this:

• What about configurations with a pool of public IP addresses?
• What about IPv6? (TBH, I never looked into IPv6 and the many techniques for routing IPv6 traffic through an IPv4 network, but is there a possibility that an IPv6 address could be converted to the public WAN address? Also, what about native IPv6?)

[Giorgio Maone]

2 thoughts on this:

• What about configurations with a pool of public IP addresses?
• What about IPv6? (TBH, I never looked into IPv6 and the many techniques for routing IPv6 traffic through an IPv4 network, but is there a possibility that an IPv6 address could be converted to the public WAN address? Also, what about native IPv6?)

This is essentially a design flaw of many routers: there's no reason to make the web administration console reachable on the WAN IP from the LAN, especially if WAN access is explicitly disabled.
So talking about different configuration is merely academic, since routers may implement different variations of this bug.

@al_9x:
I submitted an "help wanted" request on the security group mailing list to use a Mozilla ipecho server, but I already received a couple of objections about the privacy concerns outweighing the benefits (NoScript users being likely to change the default administration password anyway).
I explained that the privacy point is rather moot with a Mozilla server (provided that the request is properly anonymized) since the only information disclosed (possibly over a secure channel) is that IP xyz is running NoScript a time t, while Firefox users automatically (and often unconsciously) submit to Mozilla this very piece of information (through the update ping service) and much more about their browser configuration and usage patterns.
Also, even if you changed your administration password, you're still subject to session riding and CSRF attacks while you're logged in your router, and firmware vulnerabilities which would be otherwise considered of minor severity on the assumption that an attacker should be inside the LAN to succeed, would become unexpectedly exploitable instead.

I'm waiting for further replies there.

[dhouwn]

This is essentially a design flaw of many routers: there's no reason to make the web administration console reachable on the WAN IP from the LAN, especially if WAN access is explicitly disabled.

Definitely.

So talking about different configuration is merely academic, since routers may implement different variations of this bug.

You are probably right.
IMHO, after releasing the ABE NoScript solution to this, you should make clear that this should not be used as a substitute to fixing the bug on the router's side.

PS: This issue could also affect Modem configuration interfaces I guess.
PSS: What about using NAT-PMP or UPnP for public IP discovery? (of course only when it's supported and activated) Maybe future generations of Firefox could implement something like this and offer this information to extensions like NoScript?

[al_9x]

After looking up the ip the first time, you could attempt the router connection and if it fails (times out), there is no need for further lookups.

[Giorgio Maone]

After looking up the ip the first time, you could attempt the router connection and if it fails (times out), there is no need for further lookups.

Yes, I had already implemented this optimization.

[dhouwn]

you could attempt the router connection

What about Telnet configuration interfaces or HTTP configuration interfaces on non-standard ports, etc.?

[Giorgio Maone]

you could attempt the router connection

What about Telnet configuration interfaces or HTTP configuration interfaces on non-standard ports, etc.?

Telnet interface are a non-issue, given that the attack uses HTTP.
How many router web admin consoles do you know on non-standard ports, and which ports do they use?

[dhouwn]

Telnet interface are a non-issue, given that the attack uses HTTP.

I wouldn't be so sure about this, I guess there is a reason behind why HTTP requests over certain ports are blocked.

How many router web admin consoles do you know on non-standard ports, and which ports do they use?

I remembered that I did once access a router web interface over a non-standard port, but now I do recall that it was from outside the network.
I guess you would be right to said that there are probably only a negligible amount of router web config consoles being served over non-standard ports, even much less on home routers.

[Giorgio Maone]

Please check latest development build

[al_9x]

Please check latest development build

1. no warning/permission - if you introduce features that necessitate background unsolicited connections I certainly want to know about it (why, where, what's sent)
2. [ABE WAN] logging seems to be broken, don't see it in the console
3. the "element of" symbol in the label is perhaps too arcane: the NS documentation is rather sparse so ui labels should be as descriptive as possible (something like: "regard/treat public ip as LOCAL" with possibly a link to the vulnerability description)

[Giorgio Maone]

no warning/permission - if you introduce features that necessitate background unsolicited connections I certainly want to know about it (why, where, what's sent)

1. I'm not sure whether a warning prompt (especially if modal) is actually a good idea, because it should be issued at the very beginning of the session, which is against the new "good first run experience" principle dictated by AMO.
2. No data, except your IP for very obvious reasons, is sent. The request is stripped off of all its headers (even the most innocuous ones) except the "Host" one which is mandated by HTTP/1.1, so your request is completely unidentifiable among the other ABE requests, exactly like this:

   Code: Select all

   GET /ipecho/ HTTP/1.1
   Host: secure.informaction.com
   

   
   The release page notes which gets opened after a NoScript update could theoretically collect much more data, since it's loaded through a "normal" browser request.
3. Because of 1 & 2 combined, a middle ground may be issuing a confirmation prompt only to users who choose not to opt out of the release notes page (which are the vast majority): the other ones would be informed of the absolute anonymity and benefits of this feature by the release notes page itself and by the privacy policy posted on AMO.

[ABE WAN] logging seems to be broken, don't see it in the console

It's logged on the terminal, rather than on the Error Console -- even though doing the latter is probably better and the feature is quiet enough.

the "element of" symbol in the label is perhaps too arcane: the NS documentation is rather sparse so ui labels should be as descriptive as possible (something like: "regard/treat public ip as LOCAL" with possibly a link to the vulnerability description)

I choose the "belongs to" symbol (which should be familiar enough to the kind of people capable to understand what this feature is about) in order to prevent the need for localization, which would surely not be updated in a short time: I really want to push out 2.0 with this feature before the BlackHat talk, and I'm already running out of time
Of course the math symbolism can be changed into a more descriptive label like the ones you suggest as soon as localization is ready.

[al_9x]

I'm not sure whether a warning prompt (especially if modal) is actually a good idea, because it should be issued at the very beginning of the session, which is against the new "good first run experience" principle dictated by AMO.

This happens once per implemented feature, not even on every install, I don't get your objections. Being upfront about these things and letting the user decide is a signal of honorable intentions. Does it not annoy you when other software does this behind your back?

Because of 1 & 2 combined, a middle ground may be issuing a confirmation prompt only to users who choose not to opt out of the release notes page (which are the vast majority): the other ones would be informed of the absolute anonymity and benefits of this feature by the release notes page itself and by the privacy policy posted on AMO.

Did you perhaps mean "who chose to opt out?"

It's logged on the terminal, rather than on the Error Console -- even though doing the latter is probably better and the feature is quiet enough.

Console is better, console logging can be toggled, but a terminal requires a restart. Are you sending other things to the terminal only? Why?