Google’s Newest Feature: Find My Home

The commoditization of personal data in recent years has created huge opportunities for anyone with the skills to collect, catalogue and correlate every aspect of our lives. For many years now, there has been a war between browser vendors and unscrupulous advertisers looking for tricks to uniquely identify users and track their movements across websites. Mozilla, for example, has implemented a long list of protections against browser fingerprinting within Firefox and EFF’s Privacy Badger anti-tracking browser plugin has more than one million installs across Firefox and Chrome. Despite all of these efforts to thwart unwanted online tracking, it turns out that our connected gadgets may not only uniquely identify us but, in some cases, they can reveal precise physical locations. In this blog post, I will reveal a new attack against Google Home and Chromecast devices that does exactly that. These problems stem from two fundamental design choices that are prevalent among IoT devices:

1. Devices rarely require authentication for connections received on a local network
2. HTTP is frequently used to configure or control embedded devices

The confluence of these properties means that web browsers and, therefore, websites can sometimes interact with network devices. This is something I’ve talked about before with regard to using cross-site request forgery (CSRF) or DNS rebinding to achieve code execution.

Analyzing Google Cast Devices

This research started with the simple goal of creating a lab exercise for my Black Hat training demonstrating how a website can identify and commandeer screens or speakers on a local network to play Rick Astley’s “Never Gonna Give You Up.” (A ‘Drive-by Rick Roll’ if you will.) Using the IoT analysis techniques I’ve been teaching, I quickly realized a far more interesting attack surface. It turns out that although the Home app – which allows users to configure Google Home and Chromecast – performs most actions using Google’s cloud, some tasks are carried out using a local HTTP server. Commands to do things like setting the device name and WiFi connection are sent directly to the device without any form of authentication. Although Google’s app, which uses this functionality, implies that you must be logged into a Google account linked with the target device, there is, in fact, no authentication mechanism built into the protocol level. On my home network, with the aid of my DNS rebinding server, I was not only able to hijack the screen attached to my Chromecast but I was actually able to use data extracted from the devices to determine their physical location with astonishing accuracy. If you’ve ever explored the HTML5 location API, you’ll probably agree that it’s nothing short of amazing. If you haven’t seen this before, open Google Maps in Chrome’s incognito mode, click the “My Location” icon, and enable location tracking if asked. (Using incognito mode is just to make sure Google can’t use location history data pulled from a phone.) Even without a GPS receiver, Maps has typically been able to locate my machine within 10 meters. This apparent magic trick is made possible by analyzing signal strengths for surrounding WiFi networks and then triangulating a position using WiFi access point maps collected by the millions of phones opted into Google’s enhanced location services.

Exploitation and Impact

Using the DNS rebinding software from my IoT training, 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. The implications of this are quite broad, including the possibility of more effective blackmail or extortion campaigns. Common scams like fake FBI or IRS warnings or threats to release compromising photos or expose some secret to friends and family could use this to lend credibility to the warnings and increase their odds of success. DNS rebinding is not the only way to exploit this, however. Browser extensions and mobile apps can use their unrestricted network access to directly query the devices without relying on or waiting for a DNS cache refresh. This gives advertisers a direct path to obtain location data without alerting the end-user. The location data can then be correlated with other tracked web activity and possibly tied to a specific 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.

Mitigating Exposure

The only way to completely mitigate the risk of being tracked by your devices is to disconnect them. Assuming, however, that you want to keep on binge-watching the latest Netflix series and asking your smart speaker to dim the lights, there are some less drastic steps you can take to minimize exposure. Option #1: Professional Grade Network Segmentation In my home, I have at least three distinct networks at any given time. One network serves as the main home network used for transferring files and general web browsing, another is used for connected devices, and the last one is a “wild-west” network where I sometimes configure devices for security audits. This means that if I am surfing the web on my main network, a rogue website or app would not be able to find or connect to my devices. When using Chromecast, I need to then either switch networks temporarily or else use the sometimes glitchy “Guest Mode.” Option #2: The Easy Method of Network Segmentation VLANs and firewall rules work for me because I’ve spent the past decade working on network security products, but it is not so suitable for most users. There are some consumer routers where this can be done with relative ease, but this is not always easy to configure or verify that it is working as intended. A much easier solution is to add another router on the network specifically for connected devices. By connecting the WAN port of the new router to an open LAN port on the existing router, attacker code running on the main network will not have a path to abuse those connected devices. Although this does not by default prevent attacks from the IoT devices to the main network, it is likely that most naïve attacks would fail to even recognize that there is another network to attack. Option #3: DNS Rebind Protection The DNS rebinding attacks rely on vulnerable default configurations of commonly used name servers. Although DNS servers can be configured to stop the rebinding attack, most public DNS resolvers do not enable such protections as they could possibly interfere with legitimate activities. It turns out, however, that the DNS software commonly used in consumer routers actually has DNS rebind protection as a feature even if most routers do not enable it by default or even have an option to enable it manually. OpenWRT and DD-WRT users can and should enable this protection. Advanced users may also consider deploying their own local DNS server (such as on a Raspberry Pi) with rebinding protections enabled.

Conclusions

For many years now, device makers have focused to a large degree on a low-friction user experience that ultimately lends itself to abuse. In the face of DNS rebinding and mobile apps, though, 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. Until we reach that point, consumers should separate their devices as best as is possible and be mindful of what websites or apps are loaded while on the same network as their connected gadgets. This post was published in coordination with Brian Krebs, who wrote an article in which I discuss the data leak weakness and provide IoT security recommendations. You can view Krebs' article here.