TL;DR Following the wrong link could allow remote attackers to control your WiFi router, Google Home, Roku, Sonos speakers, home thermostats and more.

The home WiFi network is a sacred place; your own local neighborhood of cyberspace. There we connect our phones, laptops, and “smart” devices to each other and to the Internet and in turn we improve our lives, or so we are told. By the late twenty teens, our local networks have become populated by a growing number of devices. From smart TVs and media players to home assistants, security cameras, refrigerators, door locks and thermostats, our home networks are a haven for trusted personal and domestic devices.

Many of these devices offer limited or non-existent authentication to access and control their services. They inherently trust other machines on the network in the same way that you would inherently trust someone you’ve allowed into your home. They use protocols like Universal Plug and Play (UPnP) and HTTP to communicate freely between one another but are inherently protected from inbound connections from the Internet by means of their router’s firewall. They operate in a sort of walled garden, safe from external threat. Or so their developers probably thought.

A few months ago, I began to follow a winding path of research into a 10 year-old network attack called DNS rebinding. Put simply, 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. By following the wrong link, or being served a malicious banner advertisement, you could inadvertently provide an attacker with access to the thermostat that controls the temperature in your home.

NOTE: This research has been simultaneously released with a counterpart WIRED article on the subject by Lily Hay Newman.

What is DNS Rebinding?

To better understand how DNS rebinding works it’s helpful to first understand the security mechanism that it evades; the web browser’s same-origin policy. Many moons ago, browser vendors decided it probably wouldn’t be a good idea for web pages served from one domain to be able to make arbitrary requests to another domain without explicit permission from that second domain. If you follow a malicious link on the web, the web page you arrive at shouldn’t be able to make an HTTP request to your bank website and leverage your logged in-session there to empty your account. Browsers restrict this behavior by limiting HTTP requests originating from a domain to access only other resources that are also located on that domain (or another domain that explicitly enables cross-origin resource sharing).

DNS can be abused to trick web browsers into communicating with servers they don’t intend to.

The code at http://malicious.website can’t make a standard XMLHttpRequest to http://bank.com/transfer-fund because malicious.website and bank.com are different domains and therefor the browser treats them as separate origins. Browsers enforce this by requiring that the protocol, domain name, and port number of a URL being requested is identical to the URL of the page requesting it. Sounds good, right?

Not so fast. Behind every domain name lies an IP address. malicious.website may reside at 34.192.228.43 and bank.com may call 171.159.228.150 home. The Domain Name System (DNS) provides a useful mechanism of translating easy-to-remember domain names into the IP addresses that our computer’s actually use to talk to each other. The catch is that modern browsers use URLs to evaluate same-origin policy restrictions, not IP addresses. What would happen if the IP address of malicious.website were to quickly changed from 34.192.228.43 to the IP address of 171.159.228.150? According to the browser, nothing would have changed. But now, instead of communicating with the server that originally hosted the website files at malicious.website, your browser would actually be talking to bank.com. See the problem? DNS can be abused to trick web browsers into communicating with servers they don’t intend to.

DNS rebinding has received a few brief moments of attention over the past year when vulnerabilities were found in a few popular pieces of software. Most notably, Blizzard’s video games, the Transmission torrent client, and several Ethereum cryptocurrency wallets were vulnerable to DNS rebinding attacks until recently. In just the wrong circumstance, the Ethereum Geth vulnerability could have given a remote attacker full-control of the victim’s Ethereum account, and with it, all of their coin.

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.

How DNS Rebinding works

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

This scenario is an actual exploit (CVE-2018–11315) that I’ve found and used against my Radio Thermostat CT50 “smart” thermostat. The implications and impact of an attack like this can have far reaching and devastating effects on devices or services running on a private network. By using a victim’s web browser as a sort of HTTP proxy, DNS rebinding attacks can bypass network firewalls and make every device on your protected intranet available to a remote attacker on the Internet.

What’s Vulnerable?

After finding and exploiting this vulnerability in the very first device that I poked around with, I feared that there were likely many other IoT devices that could also be targeted. I began to collect and borrow some of the more popular smart home devices on the market today. Over the next few weeks every device that I got my hands on fell victim to DNS rebinding in one way or another, leading to information being leaked, or in some cases, full device control. Google Home, Chromecast, Roku, Sonos WiFi speakers, and certain smart thermostats could all be interfaced with in some way by an unauthorized remote attacker. Seems like a big problem huh?

The idea that the local network is a safe haven is a fallacy. If we continue to believe it people are going to get hurt.

I’ve been in contact with the vendors of these products and all of them are working on or have already released security patches (more on that disclosure in this essay). Those are just the companies whose devices I’ve personally tested in my spare time. If companies with such high profiles are failing to prevent against DNS rebinding attacks there must be countless other vendors that are as well.

I’ve authored a proof-of-concept exploit that you can use to target these devices on your home network today. That demo is live at http://rebind.network.

Google Home

The apps used to control Google Home products make use of an undocumented REST API running on port 8008 of these devices (e.g. http://192.168.1.208:8008). The first mention of this service that I’ve been able to find surfaced back in 2013 when Brandon Fiquett wrote about a Local API he found while sniffing the WiFi traffic to his Chromecast. Fast forward five years and it seems that Google has integrated that same mysterious API into all of its Google Home products, and as you can imagine, that undocumented API is fairly well documented by amateurs and hobbyists at this point. In fact, earlier this year Rithvik Vibhu published detailed API docs to the public.

This API provides extensive device control without any form of authentication. Some of the most interesting features include the ability to launch entertainment apps and play content, scan and join nearby WiFi networks, reboot, and even factory reset the device.

Imagine a scenario where you’re browsing the web and all of a sudden your Google Home factory resets. What if your roommate left their web browser open on their laptop and an HTML advertisement sends your Chromecast into reboot loops while you are trying to watch a movie? One of my favorite attack scenarios targeting this API is an abuse of the WiFi scanning capability. Attackers could pair this information with publicly accessible wardriving data and get accurate geolocation using only your list of nearby WiFi networks. This attack would be successful even if you’ve disabled your web browser’s geolocation API and are using a VPN to tunnel your traffic through another country.

Here is an example of some of the data that I’ve exfiltrated from my own Chromecast. Can you figure out where I might be writing this post from?

UPDATE (06/19/2018): Craig Young's simultaneous and independent research on this vulnerability was disclosed yesterday, just ahead of this post. He actually created a PoC for the geolocation attack scenario that I described above, but never implemented! His work, and Brian Kreb's commentary on it are both excellent 👏👏👏.

I notified Google about this vulnerability when I discovered it in March and again in April after receiving no response. According to Kreb's post, Young reported the bug to Google in May and his ticket was closed with "Status: Won’t Fix (Intended Behavior)." It wasn't until Krebs himself contacted Google that they agreed to patch the vulnerability. Google is expected to release a patch in mid-July 2018.

Sonos WiFi Speakers

Like Google Home, Sonos WiFi speakers can also be controlled by a remote attacker (CVE-2018–11316). By following the wrong link you could find your pleasant evening jazz play list interrupted by content of a very different sort. That’s fun for simple pranks, but ultimately pretty harmless, right?

After a bit of digging I found a few other interesting links to be followed on the Sonos UPnP web server that might not be so innocent. It appears that several hidden web pages are accessible on the device for debugging purposes. http://192.168.1.76:1400/support/review serves an XML file that appears to contain the output of several Unix commands run on the Sonos device (which itself seems to run a distribution of Linux).

http://192.168.1.76:1400/tools provides a bare bones HTML form that lets you run a few of these Unix commands on the Sonos device yourself! The Sonos HTTP API allows a remote attacker to map internal and external networks using the traceroute command and probe hosts with ICMP requests with ping using simple POST requests. An attacker could use a Sonos device as a pivot point to gather useful network topology and connectivity information to be used in a follow up attack.

UPDATE (06/19/2018): Sonos has published a statement along with this public release; "Upon learning about the DNS Rebinding Attack, we immediately began work on a fix that will roll out in a July software update."

Roku

While exploring the network in the lounge at my work building, I found an HTTP server running on port 8060 of a RokuTV. I soon found that Roku’s External Control API provides control over basic functionality of the device, like launching apps, searching, and playing content. Interestingly, it also allows direct control over button and key presses like a virtual remote, as well as input for several sensors including an accelerometer, orientation sensor, gyroscope and even a magnetometer (why?) As you’ve probably guessed, this local API requires no authentication and can be exploited via DNS rebinding (CVE-2018–11314).

I reported these findings to the Roku security team, who initially responded saying:

There is no security risk to our customers’ accounts or the Roku platform with the use of this API… We are aware of web apps like http://remoku.tv that can be loaded into a browser and used to interact with the Roku on the same local network.

After describing a detailed attack scenario, a security VP at the company clarified that their team does “consider this a valid threat and it is not mundane in the least.” To the team’s credit, they immediately halted the release roll out of Roku OS 8.1 and began to develop a patch, which they expected could take as long as 3–4 months if they couldn’t find a solution that worked in time for their upcoming release.

After some consideration, I informed the team that I was working with a reporter at WIRED and that we were likely going to publish the research quickly. The next morning I received an email from the team that a patch had been developed and was already in the process of being pushed to over 20 million devices through a firmware update!

UPDATE (06/19/2018): Roku has released a statement along with this public release; “After recently becoming aware of the DNS Rebinding issue, we created a software patch which is now rolling out to customers. Note that any potential exploitation of this vulnerability poses no security risk to our customers’ accounts, our channel partners’ content security or the Roku platform.”

Radio Thermostat

The Radio Thermostat CT50 & CT80 devices have by far the most consequential IoT device vulnerabilities I’ve found so far. These devices are some of the cheapest “smart” thermostats available on the market today. I purchased one to play with after being tipped off to their lack of security by CVE-2013–4860, which reported that the device had no form of authentication and could be controlled by anyone on the network. Daniel Crowley of Trustwave SpiderLabs had attempted to contact the vendor several times before ultimately publishing the vulnerability after hearing no response from the company. Unfortunately, this lack of response is a recurring theme of vulnerability disclosure over the years, especially with smaller manufacturers. I expected that the chances that the vulnerability had gone unpatched for five years was actually high, so I purchased a brand new CT50.

That assumption turned out to be correct and the thermostat’s control API left the door wide open for DNS rebinding shenanigans. It’s probably pretty obvious the kind of damage that can be done if your building’s thermostat can be controlled by remote attackers. The PoC at http://rebind.network exfiltrates some basic information from the thermostat before setting the target temperature to 95° F. That temperature can be dangerous, or even deadly in the summer months to an elderly or disabled occupant. Not to mention that if your device is targeted while you’re on vacation you could return home to a whopper of a utility bill.

The severity of this vulnerability, and the continued negligence by the Radio Thermostat Company of America who’ve had years to fix it, are perfect examples of why we need security regulation for IoT devices.

WiFi Routers

If you’ve been following all of this so far you may have already started to think of other devices on home networks that could be targeted. Would it surprise you to learn that, historically, network routers themselves are some of the most common targets to DNS rebinding attacks? Probably not.

That’s because network routers hold the keys to the kingdom. Own the router and you own the network. There are two common attack vectors that I’ve seen with DNS rebinding:

1. POSTing default credentials to a login page like http://192.168.1.1/loginto own router admin. Once the attacker has authenticated they have full device control and can configure the network as they please.
2. Using a router’s Internet Gateway Device (IGD) interface through UPnP to configure permanent port forwarding connections and expose arbitrary UDP & TCP ports on the network to the public Internet.

The first is pretty basic. Many routers ship with default login credentials and consumers never change them. Sure, maybe they will enable WPA2 and set a WiFi password, but I bet many of them don’t realize their router’s configuration panel is still accessible to anyone on the network using “admin:admin”.

The second attack is even worse, a downright travesty. Somehow, in this day and age, most brand-spanking-new home routers still ship with UPnP servers enabled by default. These UPnP servers provide admin-like control over router configuration to any unauthenticated machine on the network over HTTP. Any machine on the network, or the public Internet through DNS rebinding, can use IGD/UPnP to configure a router’s DNS server, add & remove NAT and WAN port mappings, view the # of bytes sent/received on the network, and access the router’s public IP address (check out upnp-hacks.org for more info).

A DNS rebinding attack that targets a router’s UPnP server can punch a hole in the victim’s firewall, leaving a permanent entry point to execute raw TCP & UDP attacks against devices on the network without being bound to the normal HTTP-only limitations of DNS rebinding attacks. They can even configure port forwarding rules that forward traffic to external IP addresses on the Internet, allowing an attacker to add a victim’s router as a node in a large network of infected routers that can be used to mask their traffic from authorities (see Akamai’s recent UPnProxy research).

IGD also provides an interface to discover a router’s public IP address through a simple unauthenticated HTTP request. This functionality, combined with DNS rebinding, can be used to de-anonymize users who are otherwise attempting to mask their public IP address through a VPN or by using TOR.

In my experience router vulnerability to DNS rebinding is a mixed bag. I’ve seen routers that completely block DNS rebinding attacks, routers that randomize their UPnP server port to make discovery and attack more difficult, and I’ve seen routers that are completely wide-open to the attack. I should mention though that I’ve largely stayed away from applying my DNS rebinding research to routers so far... Mostly because I’m almost too afraid to look 😨.

The Walled Garden Is a Lie

How is it that so many devices today could be vulnerable to an attack that was introduced over ten years ago? There are likely more reasons for this than I can explain, but I’m willing to bet money on two of them.

The first is awareness. Best I can tell, DNS rebinding isn’t as popular of an attack as it should be. Sure, security nerds may have heard of it but I’d wager that very few of them have actually ever tried it. It’s historically been a sort of cumbersome and difficult to pull off attack in practice. You have to spin up a malicious DNS server in the cloud, write some custom JavaScript payload targeting a specific service, serve that to a victim on a target network, and then figure out how to use their web browser to pivot to a target machine running that service, which you probably don’t know the IP address of. There’s overhead and it’s error prone. (I’ve written some tooling to ease some of that pain. More below…)

We need developers to write software that treats local private networks as if they were hostile public networks.

Even if DNS rebinding becomes more popular in cybersecurity communities, that isn’t a guarantee that we’ll see a large drop in the number of vulnerable devices. That’s because security nerds aren’t the ones implementing these APIs, web developers are. Sure web developers should know that externally facing API endpoints need authorization of some kind, but there is a recurring general consensus that private networks themselves can be used to secure intranet facing APIs. Local APIs consistently offload trust and security to the private network itself. Why would your local REST API need authorization if your router has it? Entire protocols like UPnP are built around the idea that devices on the same network can trust each other. This is the root of the problem.

We need developers to write software that treats local private networks as if they were hostile public networks. The idea that the local network is a safe haven is a fallacy. If we continue to believe it people are going to get hurt.

Protecting against DNS Rebinding

Consumers

As the user of a product or service you are often at the mercy of the the people who built it. Fortunately, in the case of DNS rebinding, you have some control over protecting your network so long as you can make changes to your router’s configuration. OpenDNS Home is a free DNS service that can be configured to filter suspicious IP addresses like private IP ranges out of DNS responses. You should be able to change the DNS server your router uses from the default ISP’s DNS server to one of OpenDNS Home’s DNS servers in your router settings.

If you’d prefer to control this filtering on your router itself instead of trusting a public DNS server like OpenDNS to do it, you can use Dnsmasq or opt to install libre router firmware like DD-RT on the router itself. Either of these solutions are adequate if you have control over your router, but watch out, because you may still be a target of DNS rebinding attacks whenever you are on a network that hasn’t been explicitly configured to protect against them.

Developers

If you’re a developer, or are involved in creating a product that has an HTTP API, there are several things you can do to protect it from DNS rebinding attacks. There are three simple solutions to choose from.

The first, and simplest to implement without side-effects to your existing system, is to add “Host” header validation to your HTTP server. This header is included in all HTTP requests sent from a modern browser and it contains the host (hostname:port) of the server it is expecting to communicate with. This value can be a domain name or an IP address, but either way, the server that receives the request should validate that it’s own host matches the host being requested. Because DNS rebinding relies on the change of an underlying IP address associated with a domain name, the Host header included in a malicious HTTP request that’s been rebound to a target service will maintain the original domain name as its Host header value. A malicious POST request to your router’s login page will have a Host header value that doesn’t match your router’s hostname or IP address on the network. It would instead look like Host: malicious.website. Web servers should validate that the requested Host header matches it’s expected value exactly and respond with a 403 Forbidden HTTP status code if it doesn’t. I’ve written an NPM module that does this for Express.js web servers, but it should be pretty easy to implement in any web server or language.

Another effective method of spoiling DNS rebinding attacks is to use HTTPS instead of HTTP, even for local network connections. When rebinding occurs, the service being targeted will have an SSL certificate that isn’t valid for malicious.website and so a security warning will block the request from reaching your API endpoint. This solution has the added bonus of providing extra privacy and security for your users in general with the usual benefits that come with TLS/SSL. Vendors have historically shied away from shipping IoT devices with their own TLS/SSL certificates, but the Plex media server software has tackled this problem in an interesting way by actually using DNS rebinding to issue certificates and protect their customers!

Probably the best solution, albeit the one that involves the most potential disruption to your existing service, is to add some form of user authentication to your API. If your API controls real world functionality or provides access to sensitive information it should be accessible to select parties only. Period. It should not be accessible to the entire private network and therefore the public Internet as well through DNS rebinding. There is absolutely no reason that any device on the WiFi network should be able to arbitrarily control the heat in a building. People forget how easy it is to crack WPA2 WiFi.

Tooling & Details

To help spread awareness of DNS rebinding attacks I’ve built tooling and libraries that others can use to author their own DNS rebinding attacks. Aside from the JavaScript payload written to target a specific device or service, the process of delivering that payload, interacting with the malicious DNS server, and enumerating hosts on the victim’s private network is pretty much the same between different attack targets. To lower the barrier to entry to learn about and perform DNS rebinding attacks, I’ve open sourced:

• A “malicious” DNS server called whonow
• A front-end JavaScript library called DNS rebind toolkit

Whonow DNS Server

Whonow is a custom DNS server that lets you specify DNS responses and rebind rules dynamically using domain requests themselves. Here’s an example of how it works:

# respond to DNS queries for this domain with 34.192.228.43 the first
# time it is requested and then 192.168.1.1 every time after that.
A.34.192.228.43.1time.192.168.1.1.forever.rebind.network

# respond first with 34.192.228.43, then 192.168.1.1 the next five
# times, and then start all over again (1, then 5, forever…)
A.34.192.228.43.1time.192.168.1.1.5times.repeat.rebind.network

What’s great about dynamic DNS Rebinding rules is that you don’t have to spin up your own malicious DNS server to start exploiting the browser’s same-origin policy. Instead, everyone can share the same public whonow server running on port 53 of rebind.network.

You can try it now if you’d like, just use dig to query the public whonow instance. It responds to requests for *rebind.network domain names.

# dig is a unix command for making DNS requests
dig A.10.10.10.50.forever.rebind.network

;; QUESTION SECTION:
;10.10.10.50.forever.rebind.network. IN A

;; ANSWER SECTION:
10.10.10.50.forever.rebind.network. 1 IN A 10.10.10.50

Whonow always sets TTL values to one second so you can expect that it’s responses won’t stay in a DNS resolver’s cache for long.

DNS Rebind Toolkit

DNS Rebind Toolkit is a utility library that automates the process of executing DNS rebinding attacks. Once you’ve written a JavaScript payload to target a specific service, DNS Rebind Toolkit can help you deploy that attack on a victim’s network.

• It uses a WebRTC IP address leak to discover the victim’s local IP address.
• It automates network subnet enumeration so that you can target devices even if you don’t know their IP addresses on the private network.
• It automates the DNS rebinding portion of the attack. You get a Promise that resolves once the rebind has finished.
• It uses whonow behind the scenes so that you don’t have to worry about the DNS server component of a DNS rebinding attack.
• It comes with several payloads for attacking common IoT devices and well-documented examples so that you learn to write your own exploits.

Launching an attack against a Google Home device on a 192.168.1.1/24 subnet is as easy as embedding a code snippet in and index.html page.

That index.html file will launch the attack, spawning one iframe for each IP address in the array passed to rebind.attack(…). Each iframe embeds payloads/google-home.html with the following JavaScript snippet:

🌐🔗 Links & Thanks 👏

Thanks to Lily Hay Newman for three months of helpful conversations leading towards her coverage of this research in WIRED. Mega-thanks to William Robertson for his help with this work, especially for letting me pwn his home network + Sonos device 🤝. I’d also like to thank the security teams at both Roku and Sonos for their swift response in developing and deploying firmware updates to protect their users against DNS rebinding attacks.

Below are a collection of DNS rebinding resources I’ve found useful in my research. You might too!