Attacking Private Networks from the Internet with DNS Rebinding | Hacker News Reader

Attacking Private Networks from the Internet with DNS Rebinding

medium.com

115 pointskiyanwang44 comments

Do you even need to play with DNS caching? Aren’t subdomains excluded from cross-origin request blocking?

Can badsite.com request a resource from subdomain.badsite.com, and the browser will allow it. The JavaScript on badsite.com can be clever then, and begin probing <ip>.badsite.com, so all badsite DNS need to do is resolve that to <ip>.

Same origin policy is an exact match on the protocol/domain/port tuple, so subdomains are not same origin.

While this is true, it is complicated by TLS terminating cloud services and the complexity nightmare that is TLS. For example, sub-domain takeover. Basically, TLS rules don't behave exactly as CORS: https://labs.detectify.com/2016/10/05/the-story-of-ev-ssl-aw...

You could also use the dangling domain to get a Let's Encrypt certificate.

It is quite common for sites to allow cross-origin loading from their own subdomains, with CORS and CSP headers.

Subdomains are excluded: the same-origin policy prevents that. You can still request resources (like images) from other domains, but usually there's no direct way to access the response to such requests. So you can't just fetch some JSON data from an API endpoint from another domain unless it's explicitly allowed by CORS, or workarounds like JSONP are available.

If the target doesn't implement CSRF protection, this might still be enough to trigger unwanted actions. So if I add <img src='http://192.168.1.1/cgi-bin/reboot.cgi'> to a website, this might reboot your router, if it's rubbish. No rebinding needed for that.

Rebinding enables you to do more than that. A vulnerable service can be interacted with just like your local backend. So you can send queries and read responses.

If you want to play with custom javascript payloads I created a website that lets you set one. http://dnsrebindtool.43z.one/

I was always wondering, if it would be possible, for example, to write an SMB Client in Javascript and so get access to an open SMB server in a LAN from a Website. (I don't know JavaScript at all)

I don't know much about SMB, but unless it's api is over http/https then AFAIK, no it wouldn't work. You might be able to get away with TCPSocket but it's super draft phase and no browser supports it. This means there isn't a direct way to directly connect to sockets over TCP, and UDP has been a problem here too (Games like agar.io can't use it.)

Maybe there's a new way to do it I haven't heard of, but that was the state of things last time I checked.

Modern versions of SMB are both authenticated and encrypted. Indeed JS cannot make such sockets.

websockets? at least for "scanning" http://localrouter.net

Websockets are on top of HTTP, so they don't provide anything for accessing non-HTTP resources.

there is no raw network access from JavaScript in a browser for precisely that reason

Not a comment about the subject being discussed, but about the style of the article, why the heck is that 1 paragraph full of emojis? Dear author(s), please don't do that, it makes me think of Kindergarten and "fill in the blanks according to the picture": https://i.pinimg.com/736x/bd/5c/cc/bd5ccc19946fba6d7484e4787...

As a matter of preference mainly for speed and reliablity, not as any sort of "security" measure, I do DNS lookups in advance and store the data, using various custom solutions.

Thus I do not need to do any lookups while viewing a page. The addresses are already available to HTTP clients locally, e.g., via HOSTS, a cdb key-value store, or an authoritative nameserver serving a custom zone file on the local network. In other words, I am not using a caching resolver.

"DNS cache poisoning" publicity circa 2008 gave me the impetus to end reliance on shared caches and later caches altogether. But it was the speed when not using a cache that kept me interested. It still does, even today.

Maybe "DNS rebinding" publicity will cause others to question the need for using shared caches, or even caches in general. Maybe not. In any event, with the increasing availability of bulk DNS data from a variety of sources, it is much easier to devise methods for avoiding caches today than it was in 2008.

Does your approach respect TTL, i.e. by updating your source of truth after a record expires? Because you'd still be affected by DNS rebinding attacks in that case - and if not, I imagine there'd be quite a bit of breakage when IPs change?

DNS caching in combination with an enforced minimum TTL (of something like 60 seconds) can be useful in mitigating certain categories of rebinding attacks (for example an attempt to bypass SSRF checks). Your solution might share this property if it behaves similarly.

I control the frequency of updates to the data. If something changes I see it. I decide whether I want to trust it. Usually in the case of a change I will do some research on the new IP address. "TTL" is a concept used for DNS caches. I do not use a cache.

This sounds interesting. Quick questions.

1. Is it possible at all to release some source code related to this? I know it's a big ask but I didn't want to leave without asking :)

2. Would it be ok to describe what this solution looks like a little more? Is it /etc/hosts being edited using a service? Is it at a deeper level? Do you use your own DNS server?

I'd love to adopt something similar, hence the curiosity :)

I was using a similar solution but probably quite different than the parent. I first generated the list of entries using Tinyproxy (turned out it was much easier than inspecting local DNS cache): you install Tinyproxy somewhere and use it for a few days. Then take the log and cut the lines:

  CONNECT Sep 08 08:29:04 [18050]: Connect (file descriptor 6): DOMAIN [IP]

So basically you almost have your hosts file ready, you just need to switch places of the DOMAIN and IP, cutting out all before and the brackets. A minute or so.

I used it for a short time and never bothered to take care of the updates though. I guess I'd have to temporarily disable the hosts file and run an async DNS resolver such as adnshost:

  adnshost -Vq +Dt

- filtering out the INET string to create a diff. It seems to much hassle to me though, to manually inspect DNS changes - I have so many things to do, I see no much reason to bother with every IP change on the Internet.

I am using bind9 for this and just looked up how to prevent it. It seems that bind9 has a (non-default) setting which prevents binding external host names to internal addresses (of which you control the A records).

Many dns servers have an option to block rebinding. For dnsmasq it's stop-dns-rebind. I added an exception for Plex, which relies on it for their personal ssl certs.

Quite a lot of routers use dnsmasq internally. Ideally this would be a default setting.

It seems to be the default for Unbound, at least on OPNSense. Though the POC allowed me to discover that my phone had been bypassing my local resolver because I tried to put 1.1.1.1 as a fallback in pihole as second option to my router, but for some reason pihole had been preferring CF over my local router.

Edit: To clarify, it seems that unbound by default blocks all RFC1918 addresses in DNS queries unless you specifically allow it for a specific domain (eg. plex.direct). OPNSense doesn't seem to expose an option to allow RFC1918 addresses in all dns responses.

Pihole doesn't fallback, it spreads DNS requests between all the upstream servers you specify.

Your router well may do the same.

I have OPNSense configured not to forward queries so it uses root servers directly, but it's of no consequence because like I said above, Unbound on OPNSense blocks RFC1918 responses by default anyways. As long as my devices are using my router as a resolver, I'll only get public IPs as responses to DNS queries. My misconfiguration in pihole just temporarily bypassed that.

But how long do you block/cache responses for? Many web pages run for days. As evidence: my 300 open tabs.

--stop-dns-rebind Reject (and log) addresses from upstream nameservers which are in the private IP ranges. This blocks an attack where a browser behind a firewall is used to probe machines on the local network.

There's no TTL, it just blocks any responses with private IP. Might break some software, because that's a legitimate DNS use.

Correct. For my internal DNS, I've added the option on the upstream outbound cache, so clients still can resolve the internal dns space.

But if you need to have the malicious DNS server connected as a requirement, aren't you already owned? The DNS server can tell you the bank's hostname is a malicious IP, and then you can both steal credentials, or MITM.

And the prevention is the same, verify DNSSEC, at least for a set of critical domains - starting with anything TLS related perhaps.

DNSSEC does nothing to prevent DNS rebinding attacks.

No, the malicious DNS server is the one for the domain the attacker controls, not the target.

But if you use a DNS server that's not trustworthy, how can you be sure that the site you're seeing is indeed the correct one?

I think you're confusing authority servers, which control the content for domains, and query resolvers. This attack works because it only requires an attacker to control an authority server, any authority, on the whole Internet. They can just register a domain to do this with.

> But if you need to have the malicious DNS server connected as a requirement, aren't you already owned?

DNS replies can be modified by anyone in the network path, so it is far more than just compromised DNS server.

> The DNS server can tell you the bank's hostname is a malicious IP, and then you can both steal credentials, or MITM.

All banks use HTTPS for their websites. A malicious IP is no t enough, unless it also has a forged certificate for the domain.

I tested the POC and it said I had several devices, Anyone want to help me search my small apartment for them because I would love to play with them.

   {{Object.keys(roku.devices).length}} Roku found
   {{Object.keys(googleHome.devices).length}} Google Home found
   {{Object.keys(radioThermostat.devices).length}} Radio Thermostat found
   {{Object.keys(phillips.devices).length}} Phillips Hue Bridge found
   {{Object.keys(sonos.devices).length}} Sonos speaker found

Sounds like you need to change the password on your WiFi.

No, that's just what it shows when it can't find anything.

Yet another symptom of the broken security model that is security through context dependent addressing (rfc1918 addresses or split horizon dns).

We should just give all things globally addressible addresses, and do ACLs explicitly. (Or have a really air gapped network).

Very interesting write up! But how likely is it to have control over the DNS-server someone uses? You either need to setup a malicious one and let the victim use your server. Or you've to hack the DNS-server the victim already is using.

This attack doesn't need control over the victim's DNS server. It uses attacker-controlled domain names to access private IPs via XHR. The DNS rebinding bypasses the standard CORS protection (without this protection the attacker could've used the IP directly). This attack is very easy to protect against (validate the Host header), but lots of IOT devices don't do this.

If I have *.int.my.domain mapped to internal hosts, am I putting myself at greater risk of rebinding attacks?

OK so I hit http://rebind.network/rebind/ from this VM. Gave it full JS permissions. And hey, it just spins its wheel.

Which isn't surprising, given that this VM's LAN router/firewall is a pfSense VPN-gateway VM. With another pfSense VPN-gateway VM as its uplink. With another pfSense VPN-gateway VM as its uplink. Oh, and a hardware router/firewall on the ISP uplink.

The first pfSense VPN-gateway VM would likely have been enough. There's no reason to expose your LAN to the Internet.

Is there some particular reason why your network has three layers of uplinks?

It's a nested VPN chain, for online compartmentalization. Like proxychains, except providing full network connectivity.

And actually, this VirtualBox host can run several different nested VPN chains. Dedicated to different personas. And those chains can be provided as "LANs" to other VirtualBox hosts, which can extend them through other VPN services. And of course, Tor.

Edit: Some diagrams:

https://keybase.pub/mirimir/VPN-Basics.png

https://keybase.pub/mirimir/VBox-One-VPN.png

https://keybase.pub/mirimir/VBox-Two-VPNs.png

VPNs do nothing to protect against DNS rebinding. It's possible you have something in your stack that does intentionally or as a side-effect (e.g. if a pfSense host handles DNS, it might reject private IPs in responses, or cache longer than it should), but it's unrelated to your VPNs.

One point is that my pfSense VMs have no routing to any physical LAN. Not without a guest-to-host breakout, anyway. The fact that they're VPN gateways is irrelevant for this.

Another point is that I have multiple LANs, to compartmentalize. There's no one router that can mix local devices and Internet hosts.

Reply on news.ycombinator.com