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