Article: Attacking Private Networks from the Internet with DNS Rebinding

[RMerlin]

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?".

The way dnsmasq implements this is by rejecting any resolved IP coming from an upstream server and that's within a non-routable block. So if for instance you somehow had mynas.mydomain.com pointing to 192.168.1.200, dnsmasq would prevent its resolution. Granted, using a public DNS zone to resolve a LAN IP is generally not a good idea, however it's not that uncommon, and would cause hard-to-troubleshoot problems (I actually do it for a customer of mine, using a delegated subdomain).

There's an example on how it looks like when dnsmasq tries to resolve a hostname pointing to 192.168.1.1, with this option enabled:

Jun 21 17:48:18 dnsmasq[29899]: possible DNS-rebind attack detected: testrb.lostrealm.ca

Name resolution attempt that I've done from my desktop returned an error message.

So since dnsmasq's solution is to partly break the way name resolution works, it's not a good idea to enable it by default. For this reason, while I do intend to add a webui setting to enable/disable it, it will default to be disabled.

 

[RMerlin]

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.

With Asuswrt, LAN-side clients are provided the router's IP for name resolution when they obtain their DHCP lease, therefore they also get covered by that protection measure. The rest result you see in my post above were made from my Windows desktop.

 

[RMerlin]

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.

DNSSEC doesn't help in the IoT example documented in that article.. If you have router.maliciousdomain.com point to 192.168.1.1, then the website will still be able to exploit any XSS vulnerabilities present in your router to pwn it. The hacker controlling maliciousdomain.com obviously isn't using a signed zone.

And here's a good view of things - remember, DNS Rebinding is nothing new...

No, but as the article points out, it's something that has very limited public awareness about its existence, because it doesn't carry a trendy name like VPNFilter or BadCOW...

 

[RMerlin]

So I assume Cisco is fixing any problems as we go.

What dnsmasq version are they using?

 

[RMerlin]

+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.

The important point IMHO isn't the fact that DNS rebind attacks can allow XSS vulnerabilities to be exploited in IoT devices with crap security - it's the fact that these IoT devices HAVE crap security for starting. That's where the real fixing is required IMHO.

That, and every single device should make it mandatory for the default password to be changed before the device can even be configured or used.

 

[sfx2000]

With Asuswrt, LAN-side clients are provided the router's IP for name resolution when they obtain their DHCP lease, therefore they also get covered by that protection measure. The rest result you see in my post above were made from my Windows desktop.

Unless the clients have their own DNS resolvers and assignments - this is a well known issue with many client applications, and it's fairly simple to override the DHCP assigned DNS - either manually or not - hence the issue.

 

[RMerlin]

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!

No need to reformat the JFFS partition (which would lead to loss of information - Asuswrt stores various pieces of data there), just enable custom scripts and configs.

Then, create the /jffs/configs/dnsmasq.conf.add file with the keyword I mentioned. After that, enable it with either a router reboot, or by running "service restart_dnsmasq" on the router.

 

[RMerlin]

Unless the clients have their own DNS resolvers and assignments - this is a well known issue with many client applications, and it's fairly simple to override the DHCP assigned DNS - either manually or not - hence the issue.

Google is the most frequent abuser there, with hardcoded 8.8.8.8 in some of their apps...

 

[charlie2alpha]

Google is the most frequent abuser there, with hardcoded 8.8.8.8 in some of their apps...

Indeed it is, I got so annoyed with it that I forced the router's DNS to all clients whether they like it or not. The DNS Filter in @RMerlin 's firmware can do that job just fine.

 

[Marin]

No need to reformat the JFFS partition (which would lead to loss of information - Asuswrt stores various pieces of data there), just enable custom scripts and configs.

Then, create the /jffs/configs/dnsmasq.conf.add file with the keyword I mentioned. After that, enable it with either a router reboot, or by running "service restart_dnsmasq" on the router.

Thank you as always Eric! I learn so much here and this is what keeps me coming back here!

Marin


Sent from my iPhone using Tapatalk

 

[sfx2000]

Google is the most frequent abuser there, with hardcoded 8.8.8.8 in some of their apps...

Wasn't Netflix on Android doing the same thing for a while?

 

[charlie2alpha]

Wasn't Netflix on Android doing the same thing for a while?

They're still doing it and not only in Android, the Netflix app on my Roku is doing it too.

 

[RMerlin]

Wasn't Netflix on Android doing the same thing for a while?

Yes, and it sounds pretty stupid to me, since it breaks geolocation for their CDN (unless they are confident their particular CDN provider works well with Google DNS - don't remember if Google supports EDNS or not).

 

[sfx2000]

Yes, and it sounds pretty stupid to me, since it breaks geolocation for their CDN (unless they are confident their particular CDN provider works well with Google DNS - don't remember if Google supports EDNS or not).

Google does... as do many of the "public" DNS providers these days...

dig @<dns server ip>

Should see something similar in the response... EDNS version 0 means that it's compliant with the supporting RFC..

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096​

If one add +dnssec, one can confirm if the queried DNS server supports dnssec, if supported, one should see the RRSIG-Records entry in the response.

 

[Paliv]

Last week out of curiosity I asked ASUS if AiProtection had any mitigations for DNS rebinding attacks. They have elevated the case continually and seem to not be sure. I haven't followed up at all, but they keep sending me e-mails apologizing for the delay and saying that their engineers are investigating. Kind of interesting/concerning they don't know what the extent of the TrendMicro features are on their devices.

 

[quant88]

No noticeable issue. Enabled DNS Rebind protection. Thank you !