What's new

Article: Attacking Private Networks from the Internet with DNS Rebinding

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Note that dnsmasq (the caching DNS proxy used by many routers) has had protection against this since at least 2010 (I couldn't find the exact version that added it, but found references to it as far back as 2010). This is one good reason (among others) to use your router as your LAN's DNS server, as directly using your ISP's DNS might not be secure. Dnsmasq will provide you with a layer of protection between you and remote servers.

Might also be a good reason to pressure router manufacturers into upgrading dnsmasq (some of them are still using 10+ years old versions, for crying out loud...)
 
This is not a new technique, though I think what surprised people is how much sensitive information is retrievable via LAN without authentication.

Edit: or rather, the blind trust of LAN by IoT manufacturers.
 
I think the best defense right now is to lock down your smart devices on a separate VLAN with a different network. If they need outside access then lock them to the manufacture's IP range. Locking down DNS is also a good defense to limit the number of DNS servers you trust on your network. But I have been saying this for years as I was hacked many years ago.
 
DNS Rebinding has been around for a long time - first hints of this, with proofs of concept go back to the 2007 time frame...

More recently, another approach that is extremely similar to the article that @thiggins mentions...

https://www.tripwire.com/state-of-security/vert/practical-attacks-dns-rebinding/

Getting to the point, embedded controllers are very much a surface - look at esp32's that can run javascript and speak http/https, and have their own resolvers - and an esp32 is cheap enough to be a throwaway device...
 
OpenDNS protects against DNS rebinding, but the best approach is not from DNS but by segmenting your network. This is something you will have to do at some point, you are either hacked or leak private information first then learn it or do it before ...

This is also why costly WiFi systems that do not offer VLAN support annoy me so much, e.g. Netgear Orbi.
 
Last edited:
From what I recall dnsmasq indeed has DNS rebinding protection but it's disabled by default.

I'd have to recheck, I thought it was enabled by default (or at least it used to be).

I'll need to setup a test DNS record to see what happens.

EDIT: confirmed, as of dnsmasq 2.80 at least, rebind protection is not enabled by default. Users of my firmware can easily enable it by creating a dnsmasq.conf.add containing "stop-dns-rebind" then restarting dnsmasq. After doing so:

Code:
Jun 21 17:48:18 dnsmasq[29899]: possible DNS-rebind attack detected: dummytest.lostrealm.ca
 
Last edited:
For some of us who are new at this, would any of you be so kind to describe the steps to enable rebind protection in Asuswrt-Merlin? So, we go to Administration first, then System then enable "Format JFSS partition at next boot" then enable "Enable JFFS custom scripts and configs" and so on?

Thank you so much!
 
EDIT: confirmed, as of dnsmasq 2.80 at least, rebind protection is not enabled by default. Users of my firmware can easily enable it by creating a dnsmasq.conf.add containing "stop-dns-rebind" then restarting dnsmasq.
Thanks @RMerlin, although it begs the question "If stop-dns-rebind is a good thing why isn't it enabled by default? What's the catch?".
 
Folks might consider that DNS Rebinding doesn't just affect routers....

Clients have been, and still are, at risk...

https://bugzilla.mozilla.org/show_bug.cgi?id=689835

https://bugs.chromium.org/p/chromium/issues/detail?id=98357

The dnsmasq fix suggested above helps the router itself (since it can resolve to itself), but the LAN side clients are actually still at risk.

DNSSEC can help if the clients and DNS server support it, by ensuring that the resolution has not been tampered with... and dnsmasq does support DNSSEC - and if I recall correctly, @RMerlin did implement this in AsusWRT back in Nov of 2015... which helps the router side for AsusWRT-RMerlin.

Pi-Hole also supports DNSSEC for their part...
 
Here are some of the recent dnsmasq bugs which were tested in the Cisco Rv320 router series. So I assume Cisco is fixing any problems as we go.

Last Modified
Mar 19, 2018
Products (3)
  • Cisco Small Business RV Series Routers
  • Cisco RV320 Dual Gigabit WAN VPN Router
  • Cisco RV325 Dual Gigabit WAN VPN Router
Known Affected Releases
1.4.2.15
Description (partial)
Symptom:
This bug has been filed to evaluate the product against multiple Dnsmasq vulnerabilities released on October 2nd 2017, identified by CVE IDs:

CVE-2017-14491 - Dnsmasq DNS Reply Heap Buffer Overflow Vulnerability
CVE-2017-14492 - Dnsmasq IPv6 Router Advertisement Handling Code Heap Buffer Overflow Vulnerability
CVE-2017-14493 - Dnsmasq DHCPv6 Code Stack Buffer Overflow Vulnerability
CVE-2017-14494 - Dnsmasq DHCPv6 Relay Code Information Disclosure Vulnerability
CVE-2017-14495 - Dnsmasq EDNS0 Code Memory Exhaustion Vulnerability
CVE-2017-14496 - Dnsmasq EDNS0 Code Buffer Over-Read Vulnerability
CVE-2017-13704 - Dnsmasq Size parameter overflow via large DNS query
 
Last edited:
DNSSEC can help if the clients and DNS server support it, by ensuring that the resolution has not been tampered with... and dnsmasq does support DNSSEC

DNSSEC does not protect against DNS rebind attacks because nothing is tampered with during transit.
 
DNSSEC does not protect against DNS rebind attacks because nothing is tampered with during transit.

It's a signed response - so trust is established with DNSSEC if the client supports it.

You make a point though, if the TTL is still valid, one can play games with cached data until the TTL expires.
 
It's a signed response - so trust is established with DNSSEC if the client supports it.

You make a point though, if the TTL is still valid, one can play games with cached data until the TTL expires.

I think you’re misunderstanding these recent iteration of DNS rebind attacks. The DNS responses are not tampered with during transit, meaning that evil.domain can claim it is located at 1.2.3.4 with a very short TTL, then change the IP to 192.168.1.1 after the initial query, both answers signed with DNSSEC. It does not involve ‘playing games with cached data’; in fact it *relies* on cache data being expired correctly otherwise the attack wouldn’t work.

Edit: bold, I think you were thinking of the older attack, which DNSSEC could protect against and you already recognized that in last comment :) I just haven’t realized before posting this comment..
 
Last edited:
I think you’re misunderstanding these recent iteration of DNS rebind attacks.

Not really - I get it, and it has been, and will continue to be a challenge.

At the same time, I'm not going to get overly excited about it.
 
At the same time, I'm not going to get overly excited about it.

+1 Also don’t understand all the hype generated. My guess is that people are surprised by the amount of private information accessible without authentication on their LAN.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top