Millions of Roku and Sonos Devices Easily Hacked: What to Do
Two days ago, we reported that Google Home and Chromecast devices were vulnerable to attacks through regular web browsers running on ordinary computers. Today (June 20), a researcher disclosed that Roku and Sonos streaming-media devices, as well as some cheap "smart" thermostats, can be attacked in the same way, and that he suspects many home Wi-Fi routers can be too.
Credit: Tom's Guide
The attack comes through a process called DNS rebinding in which a web browser, such as the one you're reading this on right now, is used to directly attack smart-home and Internet of Things devices on the same local Wi-Fi 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," wrote Brannon Dorsey, a web developer, artist and researcher based in Chicago, on a Medium piece posted today. "Every device that I got my hands on fell victim to DNS rebinding in one way or another."
How to Protect Yourself
To protect yourself from DNS rebinding attacks, Dorsey recommended the free OpenDNS Home service, which can filter out "external" communications from private IP address ranges that are set aside for internal network use. (We'll explain how that works below.) You'll have to change your router's settings so that it uses OpenDNS's Domain Name System (DNS) servers, but the OpenDNS site has instructions on how to do that.
Google is already working on a patch for Google Home and Chromecast devices, but it won't be ready until sometime in July. Sonos and Roku are also working on fixes. However, Dorsey believes that these known vulnerable devices may just be the tip of the iceberg.
Dorsey has put up a website with which you can detect vulnerable devices at http://rebind.network/rebind/. It takes a while to find everything, and so far it's configured to only detect Google Home/Chromecast, Sonos, Radio Thermostat, Philips Hue and Roku devices, but it's likely that more will be added soon.
Why This Is Possible
The problem exists because many smart-home devices, including smart TVs, cable boxes and appliances, implicitly trust requests coming from other devices on the same internal network. There's no request for authorization, such as with a password, because smart-home device makers assume (or pass the buck, if looked at another way) that the network itself is secure and behind a firewall.
A home or enterprise Wi-Fi network will generally put all its devices on one of three "private" Internet Protocol (IP) address ranges, which are 10.0.0.0 – 10.255.255.255, 172.16.0.0 – 172.31.255.255 and 192.168.0.0 – 192.168.255.255, respectively.
For example, the Windows laptop I'm typing this on currently has an internal IP address of 172.16.42.15, and my home Wi-Fi router's internal address is 172.16.42.1. My Chromecast is 172.16.42.3, my Samsung smart TV is at 172.16.42.4 and my TiVo is at 172.16.42.29. Other devices also appear on the network.
Most of these devices can talk to each other. For example, the Chromecast will let itself be controlled by any Android smartphone on the same network, no questions asked. The TiVo runs a web server of its own (common among smart-home devices), which I can view at http://172.16.42.29/index.html — as long as I'm on the same Wi-Fi network.
"The idea that the local network is a safe haven is a fallacy," Dorsey said in his blog posting. "If we continue to believe it, people are going to get hurt."
My TV doesn't run a web server, but it does have two other kinds of servers running on high-numbered network ports. It's also waiting for UPnP (Universal Plug and Play) commands from other devices on my home network, such as computers or smartphones, and it will carry out such commands without authentication.
As such, the smart TV is probably the most vulnerable networked device in my house, which is one reason I keep it on my "guest" Wi-Fi network instead of the network where the primary PCs and printers hang out.
The DNS Binding Attack
A malicious website, or even a malicious web ad that anyone can buy ad space for, can take advantage of this implicit trust with DNS binding. That's an old technique to bypass network firewalls by spoofing IP addresses so that commands can appear to come from within the home network. To paraphrase the old horror-movie trope, the call is coming from inside the house.
Say Boris Badenov the Russian cybercriminal sets up a rogue DNS server. DNS servers are meant to be the phone books of the internet — when you type in a web address (a URL) such as tomsguide.com, your browser asks a DNS server where it should go. The DNS server tells your browser that tomsguide.com is at the IP address 188.8.131.52, and your browser uses your network connection to take you there.
But Boris is smart, and Boris's malicious ad contains a small bit of code that calls out to his own website, badenov.ru. When it loads in your browser, it calls out for a DNS request for that URL, and that request leads Boris's own DNS server.
At first, Boris's DNS server will tell your browser badenov.ru's real IP address. But after a little while, it will change its tune and tell your browser that badenov.ru is at, say, 172.16.42.10. That's a private IP address that no websites actually use.
If your home network happens to use an address range containing that private IP address, as mine does, then commands coming from the browser that Boris' malicious ad is displayed on will be seen by other devices on your home network as trustworthy.
For all intents and purposes, Boris is now inside your network. He can reach out from the browser on your PC to other devices on your network and start telling them what to do.
Real (Proof-of-Concept) Attacks
We've already seen how DNS rebinding, combined with implicit same-network trust, can lead Google Home and Chromecast devices to disclose your physical location to an attacker.
"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," Dorsey noted.
Dorsey said he could have used this technique to raise the temperature on a smart thermostat, launch apps and change the channel on a Roku TV, and not only change the music on a Sonos wireless music system, but also use the Sonos administrative interface to map out the user's home network.
"If companies with such high profiles are failing to prevent against DNS rebinding attacks," Dorsey wrote, "there must be countless other vendors that are as well."
But Wait, It Gets Worse
There was one thing Dorsey didn't try, although he thinks it's possible — directly attacking a home Wi-Fi router.
Many people don't change their routers' default administrative passwords, and an attacker using DNS binding would simply have to bring up the router's administrative web interface — say, 172.16.42.1/index.html — and toss a bunch of known router factory-default admin usernames and passwords at it. (You can find lists of these on the web.) Bingo, router hijacked.
Many routers also have UPnP enabled. In other words, they will accept commands, without authentication, from other devices on the home network. An attacker using DNS rebinding could change the router's ports to create a permanent backdoor, or change the router's DNS settings to point to his own malicious DNS server.
Either way, the attacker will control your home network and can send you to clones of banking or social-media websites to steal your passwords or empty your bank accounts. He can see all the traffic between your computer and other devices to unencrypted web servers.
"Network routers hold the keys to the kingdom," Dorsey wrote. "Own the router, and you own the network."
If you're comfortable going into your router's administrative settings, make sure the username and password have been changed from their factory settings, and that UPnP services are turned off, if they are available at all.
And It's Not Going Away
Dorsey thinks we're just beginning to see what can happen with DNS rebinding attacks on smart-home devices, because the implicit-trust model is fundamental to the operation of many internet of things devices. If the devices need to ask for passwords from each other, they'll get slower, more expensive and will have shorter battery lives.
"Entire protocols like UPnP are built around the idea that devices on the same network can trust each other," Dorsey wrote. "This is the root of the problem."