In a network, computers are addressed with numerical values called IP addresses. Computers use these IP address to communicate with each other. Since these values are not easy to remember, you have to read host names, which are also the names given to these IP addresses.
The purpose of DNS (Domain Name System) is to map these human-readable host names with their corresponding IP addresses. This blog attempts to discuss the topic of DNS rebinding attacks which is a type of attack that abuses the functionality of DNS itself.
When a user searches for example.com, the computer checks if this hostname’s corresponding IP address is present in its local DNS cache. If not, it will send a DNS query to a DNS server asking for the IP address mapped to the hostname.
The DNS server responds with the IP address that is mapped to the queried host name. DNS records can be configured to have a set expiration time. This is called the Time To Live (TTL) for the DNS record. After the expiration time, a computer system will need to reissue the DNS request to the DNS server if they need to communicate with the said hostname.
If you are interested to learn about the process from the perspective of a browser, check out this blog How the Web Works: Architecture Behind the Screens!
DNS Rebinding – What is it And How it works?
DNS rebinding attack works on the fact that hostnames are used to refer to the IP addresses and not the actual network device. The owner of the hostname has full authority on how they want to configure their host to IP DNS records on their DNS server.
This means, any person who has the authority to configure his own hostname record on DNS can point his hostname to any IP address of his choice. This means they can rebind his hostname to point to any IP address of his choice. Preferably, this will be the IP address of the network device he wants to target.
DNS rebinding attacks are created to bypass security controls and policies that restrict someone on a network from accessing a network device to which they don’t have any access. A particular scenario related to IoT (Internet of Things) devices: DNS rebinding can be used by an attacker to communicate with these IoT devices present in the victim user’s home intranet network.
For example, the attacker could view the camera feed, get temperature information, or even change the room temperature by connecting to smart thermostats.
The DNS rebinding attack can be summarized in the following four steps.
- The attacker creates an A record in DNS for his hostname foo.bar to point to his internet-facing web server. He carefully sets the TTL (time-to-live) of the record to a very short time, such as 5 seconds.
- The victim visits the malicious hostname foo.bar.
- The attacker now changes the DNS A record for that hostname to point it to the target IP address. Usually, this IP address is behind a firewall.
- The JavaScript in the malicious webpage tries to connect to foo.bar but since the DNS record has been set with a low TTL, the victim’s computer will again make a DNS request for foo.bar. This time, it will resolve to the IP address set by the attacker in step 2.
Similar to creating DNS A records to resolve internal IPs, an attacker can also create a CNAME record to an internal hostname to rebind their hostname to that internal hostname.
DNS rebinding can also be used to circumvent the Same Origin Policy. According to the Same Origin Policy, the client-side JavaScript can only access resources from the same Origin. In this attack, since the hostname remains the same and only the associated IP address changes, the Origin is the same according to the Same Origin Policy.
An example attack scenario for a DNS rebinding attack would be as such:
Bob plans to target Alice’s router which is at an internal IP of 192.168.0.1. Alice loves watching cat videos, so Bob registers a hostname catvideos.net and sets the DNS record to point it to his web server at 12.13.14.15. He also configures the DNS records to have a low TTL value such that after Alice visits his website, the DNS record, instead of resolving to Bob’s webserver, resolves to the IP address of 192.168.0.1.
Bob lures Alice to visit his website at https://catvideos.net. Unknown to Alice, along with cat videos, the website also hosts malicious JavaScript that Bob will use to attack Alice’s router. After Alice visits Bob’s website, DNS record now points to 192.168.0.1 instead of 12.13.14.15. The JavaScript on the website will now try to again make connections to catvideos.net but it will again have to query the host name, and this time, it will be resolved to 192.168.0.1 instead of 12.13.14.15.
According to the Same Origin Policy, the router’s endpoint will be on the same origin as the scheme, hostname and port are the same as the origin which the requests are coming from. Therefore, the client-side JavaScript will be able to access the router portal. Bob has carefully written his script to log in to the portal and change the router’s DNS to his own DNS server. So, now any DNS query that Alice’s computer makes will go to Bob’s DNS server.
The Attack Surface
Internal websites are an interesting target due to them hosting sensitive information. These internal websites do not usually use HTTPS; there won’t be SSL name mismatch errors which can hamper or cause disturbance in our attack.
DNS rebinding can be used to target web application servers and any network device on the network. For example, you may leverage an SSRF vulnerability on a web server to bypass its filter, which prevents local addresses on the vulnerable parameter from accessing an internal FTP server.
IoT devices can also be targeted with this attack technique. Most IoT devices do not even have a proper authentication mechanism. With this, add that even if there is any authentication mechanism, the end user would be least bothered to change it, allowing the attacker to log in with default known credentials.
Mitigations and Preventive Measures against DNS Rebinding
There have been attempts made to mitigate and prevent DNS rebinding attacks. One such attempt is called DNS pinning. This attempt makes the browser ignore the TTL of the DNS record and itself set an amount of time to live. For example, a DNS record may have a TTL of 4 hours, the browser may ignore the 4 hours and instead set TTL to be 4+1 hour = 5 hours.
This can however be bypassed if the attacker implements a firewall in front of their web server. After the victim visits the server, the firewall drops subsequent requests from victim to the webserver. This makes the victim’s browser to reissue a DNS request ignoring the DNS pinning protection.
Another way of protecting web server from DNS rebinding is by configuring the webserver to check the HTTP host header in the request. If it does not match the host header set explicitly by the developer/admin, the request will be dropped. The firewall can also be configured to prevent external host names to resolve to internal IP addresses.
Also, as mentioned above, HTTPS can be used to protect against DNS rebinding attacks. This is because the HTTPS handshake requires matching of the domain set in the certificate and the domain that is being requested.
Conclusion
Security vulnerabilities can hide itself in many ways. Vulnerabilities such as the one discussed in this blog post is difficult to detect using traditional scanners. We at Payatu, combine our expertise with our research-based approach to help companies find security vulnerabilities.
Payatu is a Research Focused, CERT-In impaneled Cybersecurity Consulting company specializing in security assessments of IoT product ecosystems, Web applications & Networks with a proven track record of securing applications and infrastructure for customers across 20+ countries.
