Bob is doing some web browsing from his PC. Within the same network, there are some other connected devices including PC, laptops, mobile phones, other “smart” devices like Google Home, Smart TVs, even some IoT devices like thermostat, refrigerators, security cameras and so on.
Bob feels safe with any of these devices connected to the same network. As they say, the local area network is supposed to be safe, right? This logic also applies in the same way as those devices trust one another in a “safe” environment.
As he clicked on a link that caught his interest, Bob had no idea that an attacker had been waiting for this moment. In a matter of seconds, the attacker had infiltrated Bob’s private network and had gained access to all of his connected devices.
Bob continued to browse, unaware that his thermostat had started behaving strangely. He thought it was just a glitch, but little did he know that it was the attacker’s doing. The attacker had taken control of the thermostat and was using it as a way to gain access to other devices on the network.
As Bob continued to work, he noticed that his smart TV had turned on by itself. He was startled but assumed it was just a technical glitch. However, the attacker had taken control of the TV and was using it as a tool to spy on Bob’s every move.
Bob soon realized that something was very wrong. All of his devices were acting strangely, and he had no idea what was causing it. He quickly realized that he had been hacked and that the attacker had gained access to all of his private information.
Well, this story is indeed fictional, but is it really fictitious and impractical in a real case scenario? Brannon Dorsey has a very comprehensive article regarding the scenario that is similar to this on Medium and has reported the vulnerability that involves the DNS rebinding technique.
This is a quite old vulnerability since it was first found, yet some services may still have this. In a previous post we have talked about DNS rebinding as a technique used to get into the internal victim’s network. However, we don’t get into the details of how it could be effective. In this article we will get into the details of what DNS rebinding really is.
What is DNS rebinding?
Before going into the definition, there are at least two concepts that could be helpful for better understanding: same-origin policy and DNS resolution.
Same-origin policy
The origin is defined by three main parts: the scheme or protocol (e.g. https://), hostname or domain (e.g. binaryte.com), and port (e.g. 443). It is considered the same origin if the scheme, hostname and port are all matched. Let’s get into the example real quick.
Consider the following urls.
https://binaryte.com:443/about/
Are they the same origin? The answer is yes, because both use the same scheme, hostname and port.
How about these?
https://binaryte.com:443/about/
These belong to the same origin as well as the https use port 443 by default. So these still belong to the same origin
How about these?
https://content.binaryte.com/about/
The first one has no subdomain whereas the second one has ‘content’ as subdomain. Therefore, they are not the same origin as they have different hostnames.
At this point I hope that you understand the concept of origin. The next question you might be asking is why is it important? The same-origin policy plays a crucial role in limiting the way a document and script can load based on their interaction with resources from other origins. Thus, any malicious website on the internet won’t be able to arbitrarily execute JS in a browser to read data from another service or website. In this manner, interaction may only occur with the same origin.
DNS resolution
To simplify, DNS resolution works like this. When you enter the URL, your browser will ask the DNS resolver (e.g. ISP) to look for specific domains (see more detailed information here). In this process, the DNS server will translate the user’s request into an IP address that the machine understands in order to get you into your requested web page. This is what we call the DNS resolution.
DNS rebinding takes advantage of this behavior to deceive the victim’s browser into thinking that the request to the intranet comes from the same-site origin. In other words, DNS rebinding is a technique that uses the victim’s browser as proxy to access his/her internal network.
How does DNS rebinding work?
Let’s take the above scenario as our example.
Before Bob visits the attacker, the attacker controls the DNS server to queries to the domain where Bob was accessing. Say that the domain is evil.com with the IP address 1.2.3.4. Working like the previous scenario, the attacker tricks Bob into visiting this website.
To illustrate, see the diagram below.
Executing script
When Bob visits the website, by default the resolver makes a DNS request for the website evil.com. Bob’s browser will receive the original IP address of the malicious website. Unfortunately, the attacker also has control over the DNS records as well. Thus, the attacker can set a script inside the evil.com to force the one who visited it to query the DNS server once again.
Disabling cache
This script also sets the TTL for the response to be the shortest time possible so the browser won’t cache for long. As the attacker wants to force the web browser to rebind to the new IP, the running script needs to set some parameter in the header so that it basically asks the web browser to not store any cache on Bob’s web browser. In this way, the browser will get the fresh copy of evil.com. Utilizing the same script, the attacker may also turn off the browser’s [DNS prefetch control](https://developer.mozilla.org/en- US/docs/Web/HTTP/Headers/X-DNS-Prefetch-Control) behavior as well.
Replacing the original IP address
After a while, the victim’s browser realizes that the DNS entry it received earlier is stale, and so it makes another request to the DNS server. In this way, the original IP (1.2.3.4) is then replaced to the local network or loopback interface (127.0.0.1). After the attacker gets what he/she wants, the connection to the browser needs to be dropped, preventing the socket alive by setting up the SetKeepAlivesEnabled() function to false.
Entering the intranet
The web browser thinks that evil.com belongs to the same network as the IP address is set to a loopback address. As this intranet is considered as safe, some protection implemented in the network is like a firewall is no longer effective. The website may contain another script that would be able to get sensitive information from the victim’s network and also be able to access the service or other IoT devices especially those that don’t require authentication.
Conclusion
In conclusion, DNS rebinding is a powerful attack that exploits the trust placed in the DNS system to bypass the same-origin policy and launch attacks on unsuspecting users. The attack is particularly dangerous for IoT devices and home routers that are often left with default configurations and weak security. To protect against DNS rebinding, it is essential to keep software and firmware updated as some IoT devices are known to be vulnerable and avoid trusting unverified sources. Enforcing authentication for service whenever possible is mandatory to reduce the impact of this attack.