DNS Rebinding – Behind The Enemy Lines

Introduction

DNS Rebinding is a technique or situation in which attacker relies on the gap between SOP and DNS to achieve access to otherwise restricted areas or services ( local network, another website, etc.). Here we’re going to try and explain DNS Rebinding with a short example.

DNS Rebinding

With DNS rebinding a remote attacker can bypass a victim’s network firewall, and use their browser as a proxy to communicate directly with the devices on their private home network. DNS Rebinding evades SOP (same-origin policy). If you visit a malicious link, that website shouldn’t be able to access or send requests to any other website you’re currently logged in (for e.g. bank website). Browsers restrict such behaviour, enabling only requests from the same domain or from another domain that explicitly enables cross-origin resource sharing. The code on malicious.com can’t access bank.com since they are different domains, so browser treats them as separate origins. That’s enforced by requirement that the domain name, port and protocol of a requested URL is identical to the URL of the page requesting it. So, in case malicious.com quickly changes IP address to bank.com IP address, nothing is changed in regard to SOP, but the browser would communicate with the wrong website.

DNS Rebinding Attack Example

1. Attacker controls malicious DNS, that answers queries for some domain, e.g. malicious.com
2. Attacker tricks user into loading malicious.com (XSS, Phishing,..)
3. Victim’s browser makes a DNS request looking for the IP address of malicious.com. Attacker DNS responds with malicious.com real address, and sets TTL value to a low value (1 second) so that the cache doesn’t last.
4. The malicious.com contains malicious JS that executes on victim’s browser. For instance, page can start making some strange looking POST requests to https://malicious.com/fire_sprinkler_system with a JSON: {“fire_sprinkler_system_test”: 1}
5. The requests are initially sent to malicious.com, but the low TTL value forces browser to resolve the domain again (via another DNS lookup)
6. This time, attacker’s DNS server responds with another IP, with an IP address from local network, for instance: 192.168.1.10, which happens to be the server on the victim’s network in charge of Fire Sprinkler System.
7. Victim’s machine sends a POST request intended for malicious.com to 192.168.1.10 and Sprinkler System gets everyone wet.

So, what can we conclude from all this? The attacker needs to force the user to open a link or to find a way to run some JS code on a page victim is visiting. He also has to have an intimate knowledge of the victim network and services. He had to know that there is a service on 192.168.1.10 that listens for the POST request with specific parameters. 

Attacker can also use this technique to enumerate victim network and explore vulnerable services. More on this some other time. As mentioned, browser acts as a proxy. That’s the main thing here.

Conclusion

DNS rebinding is relatively unreliabile because of the layers we have in between (DNS, TCP, HTTP). It’s one of the reasons why people have problems with it. A number of caches:

• Browser DNS Caches – Chrome might cache DNS records for 60 seconds (depending on the configuration), and getting users to stay on your malicious page for 60 might be a problem. (chrome://net-internals/#dns)
• OS DNS Caches – In some configurations, Chrome can rely on OS DNS Cache
• Nameserver DNS Caches – DNS Record Pinning. Internal DNS Resolvers cache records for some time
• Browser Protections – Sometimes they’re not going to allow to resolve host to a different IP on the same page
• Additional Network Protections – Fixed at DNS resolver. For instance, people tend to block resolving of the localhost (127.0.0.1), but it’s permissible to resolve 192.168.x.x. Correct configuration is important.
• General Hacky-ness – a Combined feat of constructing the attack and avoiding previously mentioned problems, syncing everything in order to achieve your goal

People frequently underestimate this technique, considering it as a non-practical real-world attack. I would somewhat disagree. Although stars must align as a precondition to a successful attack, it can be quite handy.