DNS Rebinding, AKA How I Learned to Start Worrying and Hate DNS

By Joshua Niemann     

      Web applications have come a long way from their original inception.  In today’s modern web landscape, we have a sweeping array of browser-based protections designed to protect consumer privacy, and to prevent malicious activity.  Same Origin Policy, Content Security Policy and other browser protections are in place in an attempt to keep malicious sites at bay.  However, you can’t really say, “No” to a hacker.  As a direct result, web-based attacks and trackers have gotten more and more complicated as browser protections, DNS protections, and host-based privacy and ad blocking solutions have become commonplace.

            One of these protections is known as the Same Origin Policy.  The basic idea behind the Same Origin Policy (or SOP) is that you don’t really want a website accessing data from a different origin than the source.  In SOP, an origin is defined as a combination of the protocol, full domain name, and port.  An an origin could be, for example, https://csec380.chaim.com:443.  So, same origin verifies that a script from https://csec380.not-chaim.com:443 cannot see any of the data on the page of  https://csec380.chaim.com:443.  This is an incredibly important security policy of the internet as we know it.  But to understand why that is, let’s look at a quick example.

            Let’s again return to our origin of  https://csec380.chaim.com:443.  Now this page has web application on it.  This application allows users to log in, comment, post, and otherwise interact with the website.  However, this application also has a problem.  It has something called a persistent cross site scripting vulnerability (XSS).  Although I won’t go into persistent XSS right here, suffice it to say in this case it allows me to load an arbitrary script from a malicious source, just by opening a popular user’s profile.  So I can run arbitrary javascript on a remote user’s computer without their knowledge.  Without same origin policy, an attacker could perform a lot of different types of attacks at this point.  You could steal the session cookies and allow the attacker to log in, grab passwords typed on the site before the user presses enter, grab personal information off the web page and much more.  However, once same origin is applied, the attacker can only interact with the website in ways that does not touch the original document.  So while I could use the XSS vulnerability to spin up a iframe that has the ability to embed some content, the remote attacker can’t necessarily touch or see the original website.

            Now that we have the background of what Same Origin Policy does, let’s shift gears and take a look at SOP from another perspective.  What if, for instance I was an attacker, and I wanted to pull in data from somewhere else, like a router sitting inside the victim’s internal network?  Obviously, I can’t access this router from the public internet because of the user’s firewall, but the user definitely can.  So I want to be able send a GET request to this user’s protected router, but send that data back to me, the attacker.  Same origin policy would prevent this, because a script is not allowed to access data from an origin other than it’s own.

            So we want to get access to this data, but we’re not in the same origin.  192.168.0.1, for example, is not the same as a hypothetical origin of https://csec380.chaim.com.  Notice the only thing being compared here is the full domain name and protocol, not necessarily the ip address.  So… What if csec380.chaim.com suddenly became 192.168.0.1?  More specifically, csec380.chaim.com would originally return the attacker’s ip, until a second or so later when it returns 192.168.0.1.  According to the browser, https://csec380.chaim.com is the same as https://csec380.chaim.com, and would allow javascript from the attacker to get information from the router and forward that back to the attacker.

            So how would this be possible?  An attack like this would require really fast changes in DNS, and DNS is usually cached, and a bit slow.  To make this work, we change the TTL, or time to live field of the DNS entry.  This tells the client not to keep this DNS entry cached for more than a second.  So after a second, the DNS cache will invalidate itself, and it will go and refresh the value, which will contain the updated, 192.168.0.1 value.  So, after you set up your malicious DNS server, you just have to write some javascript that continually attempts to download the endpoint csec380.chaim.com/router/command_injection.php.  This is called a DNS Rebinding Attack, and it has the ability to completely invalidate Same Origin Policy.

            So, let’s give a little example to show how to set up a DNS rebinding attack.  It’s a lot simpler than you would think.  One useful tool is a DNS implementation called rebindr.  Rebindr is a DNS server written in C that is designed for testing dns rebinding attacks.  Rebindr is super useful because it allows you to not have to write your own implementation of the DNS protocol.  That being said, Rebindr isn’t that long, at 250 lines.  Rebindr is also a fantastic base if you are looking for some code to base a DNS rebind server off of.

            Another useful tool is NCCGroup’s singularity project. This is a really recent development that was announced at DefCon27 this year.  Singularity is a framework designed from the ground up to orchestrate dns rebinding attacks.  On running singualrity, you get a nice web interface that you can use to set up the DNS options, and even the payload. 

            When I set this up, I used a digitalocean server hosted with a personal domain and a virtualized network.  I set up both sides, and configured dns records on dnsrebind.<mydomain>.ninja.  I can easily say that this was the simplest version of DNS rebinding that I’ve ever experienced.  The Singularity framework is a great platform for testing for dns rebinding issues.  That being said, I would still write my own code if I was trying to attack infrastructure.

            Now that we’ve explored the malicious uses of DNS Rebinding, let’s take a quick look at one slightly different, legitimate use this technique.  This is a bit different than the attack described above, but the motivations are similar.  With that said, Plex Media Server is a legitimate use of DNS rebinding techniques, and is unique in how it rolls out HTTPS for all of it’s users. Plex Media Server sells a self-hosted product that is designed to be very easy to store and get access to TV, Movies, and media.  However, plex also makes it easy to access your content on the broader internet.  The way it works is that you can use your browser to go to the website app.plex.tv, and somehow you get either a page served from your server’s public ip address, or a ip address that points internally if you are already inside the network.

            To pull off this feat, Plex assigns every user a domain name with a wildcard certificate for the https://<ip&gt;.<hash>.plex.direct:32400 domain.  Plex’s dns server resolves each request to whatever the domain name in <ip> is.  For example, https://192.168.1.1.<hash>.plex.direct:32400 would resolve to 192.168.1.1.  That way, app.plex.tv can redirect you to both your internal IP or the external address, based on what situation it comes across.  Plex’s solution differs from the above DNS rebinding example slightly by using different origins for internal and external by taking out the very temperamental domain DNS switching.  Plex doesn’t necessarily need to access content on both the internal and external origins at a time, and thus doesn’t need any quick DNS switching.  If you want more information on Plex’s specific implementation, take a look here.  https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

            DNS rebinding attacks are a really new, yet interesting attack in the world of web security.  A lot of people, including myself, have thought at times that our local network was safe.  As a result, putting endpoints up that were never designed to be publicized became really common.  I at one time had a open endpoint for opening my garage door for example.  However, it has become increasingly clear that with attacks like DNS rebinding, we can no longer treat local networks as secure.  Instead, all home applications and IOT devices need to take into consideration the potential of external sources attempting to manipulate devices from the public internet, even if the device itself has no public endpoints.  Good luck getting all of the IOT vendors to recognize this cold fact, but until then, just be careful on what devices go on your private networks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s