DNS Rebinding – Behind The Enemy Lines

January 19, 2019 | Views: 3701

Begin Learning Cyber Security for FREE Now!

FREE REGISTRATIONAlready a Member Login Here

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 http://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.

Share with Friends
FacebookTwitterLinkedInEmail
Use Cybytes and
Tip the Author!
Join
Share with Friends
FacebookTwitterLinkedInEmail
Ready to share your knowledge and expertise?
Comment on This

You must be logged in to post a comment.

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Cybrary On The Go

Get the Cybrary app for Android for online and offline viewing of our lessons.

Get it on Google Play
 

Support Cybrary

Donate Here to Get This Month's Donor Badge

 
Skip to toolbar

We recommend always using caution when following any link

Are you sure you want to continue?

Continue
Cancel