Image

- Devices rarely require authentication for connections received on a local network
- HTTP is frequently used to configure or control embedded devices
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.Image

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