1475605 - (dns-rebinding) Comprehensive DNS Rebinding Protection

Status: NEW

(Core :: Networking: DNS, enhancement, P3)

Description

[Tom Ritter [:tjr]]

See Also https://groups.google.com/forum/#!topic/mozilla.dev.platform/bfbblcydBgo

DNS Rebinding is an attack where the Same Origin Policy in the browser gets confused because subdomain.evil.com changes from a public IP address (say 1.1.1.1) to another IP address (say 192.168.1.1).  This happens because evil.com (the attacker) has changed the IP address reported by the authoritative DNS server, set a low TTL on the reocrds, and has waited out the browser's DNS cache.

You can rebind to any IP address, public or private.  But rebinding to a public IP address has limited exploitability:
a) Your host header will be set to evil.subdomain.com, so you'd be limited to be able to attack whatever the default vhost of your target IP is
b) Any cookies sent will be the cookies of evil.subdomain.com, so you'd be limited to be able to attack something that doesn't require cookies

There aren't a lot of public websites that rely on originating IP as an authorization mechanism (although university academic publication portals come to mind).

DNS Rebinding is more commonly used to attack devices on a local network that do not have authorization schemes, such as those illustrated in https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325 (Google Home, Sonos Wifi Speakers, Roku, some wireless routers, etc).



There was discussion on dev-platform, see above, about how to address this. We certainly cannot outright deny DNS responses for private IP addresses. The proposal was to keep a second DNS cache of recently resolved names that resolved to public IP addresses. The entries in this cache are not used for resolutions, but instead of we receive a DNS response that resolves to a local address, to check this cache and confirm that it was not recently resolved to a public address. 

If it was - we could replace the resolution with NXDOMAIN, or use the old address, or something else.

Comment 1

[Brannon Dorsey]

Thanks Tom for submitting this report. I wanted to add a small note here about some research that was published in response to some of the security research that I and many others have been doing in the domain of DNS rebinding in the last several months. Last week, Armis published a report (https://www.armis.com/dns-rebinding-exposes-half-a-billion-iot-devices-in-the-enterprise/) claiming that their research suggests that over half a billion devices on enterprise networks are vulnerable to DNS rebinding in some way. Based on what I've seen from my personal research over the past four months, I can't express enough just how serious of an issue DNS rebinding is and will continue to be in the future if large, sweeping changes are not made. 

Firefox is in a position right now to pioneer a real solution to this decade-old problem. Third party product vendors and software authors have proven time and again that they they cannot be relied on to take the necessary steps to protect their users from this systemic problem. By providing protections in-browser, we can offload the burden from the authors of thousands of individual products and services, and protect millions of user's home networks and devices. If Firefox can implement a real solution to this problem, I expect other browsers will follow suit, and we may actually be able to nip this problem in the bud before it has the opportunity to get worse. If recent reports are any indication, DNS rebinding could get a lot worse, with the possibility of playing a significant role in large-scale botnets and DDoS attacks the likes of Mirai.

As Tom mentioned, see the brief discussion on the dev-platform for a more detailed overview of the problem and a proposed solution: https://groups.google.com/forum/#!topic/mozilla.dev.platform/bfbblcydBgo

Comment 3

[Emanuel Czirai]

Please at the very least block 0.0.0.0/32 because some DNS resolvers(well, one of them for sure, at least) return 0.0.0.0 for any blocked hostname, instead of NXDOMAIN.
Similarly, lines like the following might exist in /etc/hosts :
0.0.0.0 someblockedhost
which is the same as:
127.0.0.1 someblockedhost

That is, anything that resolves to 0.0.0.0 points to 127.0.0.1, thus DNS Rebinding attacks on localhost are a reality.
Say for example you run this as root:

nc -l -p 443 -s 127.0.0.1

then you start Firefox, using unnamed DNS provider that returns 0.0.0.0 for incoming.telemetry.mozilla.org instead of NXDOMAIN (this provider currently exists, I just don't want to name them here)
so what happens is that you see a connection attempt on the terminal where netcat is running.

Comment 4

[Emanuel Czirai]

Some attempted discussion about blocking 0.0.0.0/24 (not /32) was mentioned here: https://bugzilla.mozilla.org/show_bug.cgi?id=1672528#c17

If running dnsmasq, I've two workarounds(any will work):

1. run dnsmasq with arg --stop-dns-rebind

       --stop-dns-rebind
              Reject  (and  log)  addresses from upstream nameservers which are in the private ranges. This blocks an
              attack where a browser behind a firewall is used to probe machines on the local network. For IPv6,  the
              private range covers the IPv4-mapped addresses in private space plus all link-local (LL) and site-local
              (ULA) addresses.

2. use this line in /etc/dnsmasq.conf:

bogus-nxdomain=0.0.0.0

This makes dnsmasq return NXDOMAIN itself for any hostname that resolves to 0.0.0.0 but prevents any warning from --stop-dns-rebind to reach the log, for obvious reasons.

Comment 5

[Daniel Veditz [:dveditz]]

Access to address 0.0.0.0 is happening in bug 1889130

Comment 6

[Emanuel Czirai]

(In reply to Daniel Veditz [:dveditz] from comment #5)

Access to address 0.0.0.0 is happening in bug 1889130

You are not authorized to access bug 1889130., well I guess I don't need to have access to it, what could I possibly add to it anyway?! ok maybe this:
I've been using a tiny kernel patch for the past 2 years that treats destination IP 0.0.0.0 as -ENETUNREACH as the workaround for this, instead of what it normally does(the 2 cases can be seen in patch, they're commented out with block comment)

https://github.com/correabuscar/patches_gentoo/blob/08d6ca1d98a91d7cc7ff524a2a409a9ba71e137d/portage/sys-kernel/gentoo-sources.reused/6900_destaddr_quad0_is_unreachable.patch

Comment 7

[Emanuel Czirai]

Attachment: a copy here in case github or my repo/account ever gets deleted