Google Devices Leak Precise Physical Locations: Researcher
21.6.18 securityweek  Attack

A newly discovered attack against Google Home and Chromecast devices can reveal a user’s precise physical location, a security researcher has discovered.

The issue, Tripwire’s Craig Young reveals, is related to two problems common to Internet of Things (IoT) devices: the rare use of authentication for connections received on a local network and the frequent use of HTTP for configuration or control. Because of these poor design choices, websites can sometimes interact with network devices.

Young discovered that Google’s Home app, which is used to configure Google Home and Chromecast, performs some tasks using a local HTTP server, and some commands are sent directly to the device, without authentication.

The app implies that the user should be logged into a Google account linked with the target device, but no authentication mechanism is built into the protocol level, Young says.

Using an attack technique called DNS rebinding, the security researcher was able to “use data extracted from the devices to determine their physical location with astonishing accuracy.” Young also published the video below detailing the attack.

Through DNS rebinding, an attacker can implement a piece of code on a website to bridge to the local network and bypass the same-origin policy (SOP).

The code points to a subdomain of the site, while the DNS server is configured to respond alternatively with an address that both the attacker and localhost control. When the victim accesses the website, the browser resolves to the attacker-controlled DNS server, which has a short time to live (TTL), and then switches to localhost.

“I was able to create a basic end-to-end attack that worked for me in Linux, Windows and macOS using Chrome or Firefox. Starting from a generic URL, my attack first identifies the local subnet and then scans it looking for the Google devices and registers a subdomain ID to initiate DNS rebinding on the victim. About a minute after the page had loaded, I was looking at my house on Google Maps,” Young says.

The security researchers also notes that, even in incognito mode, Google Maps can typically locate a device within 10 meters. This is apparently possible through the analysis of Wi-Fi access point data and triangulation using information collected from devices that opted into Google’s enhanced location services.

The newly discovered attack, the researcher says, can be leveraged for blackmail or extortion purposes, in scams like fake FBI or IRS threats to release sensitive information or photos to friends and family.

Furthermore, because DNS rebinding is not the only way to exploit this bug, browser extensions and mobile apps can abuse “their unrestricted network access to directly query the devices without relying on or waiting for a DNS cache refresh.” Thus, advertisers can obtain location data and correlate it to other tracked web activity to tie it to a real-world identity.

“These problems are not specific to Google devices. Over the years that I’ve been auditing embedded devices, it is not the first time that I’ve seen a device supplying WiFi survey data or other unique device details like serial numbers. Smart TV’s, for example, commonly identify themselves with a unique screen ID as part of the DIAL protocol used to support Cast-like functionality,” Young says.

While the best mitigation is to completely disconnect devices, Young agrees that in today’s connected world such an option might not be possible. However, there are steps users can take to minimize exposure.

One way to dealing with this is network segmentation, where all connected devices use their own network, separate from the normal home network where all Internet browsing occurs. Adding a second router on the network, specifically for these connected devices, is the best option for most users, the researcher suggests.

Using a DNS rebind protection solution is another way to prevent such an attack. According to Young, the DNS software commonly used in consumer routers does include DNS rebind protection, although it isn’t always enabled or easy to enable. Deploying a local DNS server with rebinding protections enabled is also an option.

“In the face of DNS rebinding and mobile apps, all services running on the local network (and especially HTTP services) must be designed as if they were directly exposed to the Internet. We must assume that any data accessible on the local network without credentials is also accessible to hostile adversaries. This means that all requests must be authenticated and all unauthenticated responses should be as generic as possible,” Young says.