Full Report
Google Home is a suite of products for around the house automation. While using the device, they noticed how seamless adding users was. Additionally, the set of automated routines, that can be ran remotely, made the linking process look like a fruitful target. First, they decided to use a proxy to look at the web traffic of the device. This took some shenanigans in order to intercept on the phone, such as adding the mitmproxy as a root CA and bypass the certificate pinning using a Frida script. They then observed the linking process via the web traffic, seeing a request made to /deviceuserlinksbatch. The request was using protobuf, a binary format made by Google. The linking process was made up of two requests: Get the devices' info through the local API. Send a link request to the Google server alongside this information. The author reimplemented everything in Python for their own sanity. Manually recreating the protobuf binary from scratch would have been very annoying. they found a script for calling Google Cloud APIs and another that did the whole Android Google login process. With the authentication and protobuf setup, they could make craft their own requests. It should be noted for testing protobufs, there is an assumption that both users have a .proto file that defines types and names. The requests themselves don't have types (so they must be guessed) and don't have names associated with them. The author made a request with this and it magically worked! There was no authorization check on whether an account had access to a particular Google Home device. Now, an attacker could link their own account to the Google Home app with ease. What can an attacker actually do with this though? This is where the article goes off the rails! First, they considered the different avenues of controls devices in the house, such as opening garage doors and other things, which was originally detailed here. While scrolling through the actions on the device, they noticed a call command. If the device could be tricked into calling a phone number, then the audio would be completely required in the routine. Spy capabilities unlocked! While trying to escalate the damage, they found an article from Dan Petro from 2014. This article mentions that when a Chromecast loses connection, it will go into a setup mode. By forcing the device to deauth with specific WiFi frames in close proximity, we can make a local API request to get the Cloud ID and certificate of the device. While reading docs, they author noticed the Local Home SDK for creating Smart home actions on the device. Even though this has docs to directly access the LAN, the device tries to restrict by only allowing connections to devices that pass a scan. However, when the app is in a development mode, the Chrome Devtools Protocol (CDP) is open on the device, which is a remote version of Chrome DevTools. Using this, we can access the standard JS API to make arbitrary requests on the LAN, read and write files, likely leading to RCE. With this finding and set of exploit chains, the author contacted Google. The author was rewarded with a 100K bounty, after initially getting hit with this being intended functionality. Google did a few things to patch these issues: You must request an invite to the 'Home' that the device is registered to in order to link your account to it through the /deviceuserlinksbatch API. Call commands cannot be invoked remotely anymore. Although the deauth attack still works, this cannot be used to link an account. This prevents the attack from occurring since we cannot get an auth token for the device now. Overall, excellent technical findings! It was really cool to see the bug and the exploits that were possible from it. I wish the article was more focused though; it seemed like their were a lot of unnecessary details, making it hard to figure out what to focus on.
Analysis Summary