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

Google Home Mini

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

Sonos Play:1

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

RokuTV

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

Radio Thermostat CT50

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:

POST ing default credentials to a login page like http://192.168.1.1/login to own router admin. Once the attacker has authenticated they have full device control and can configure the network as they please. 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.

Whonow public server output

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!