A bug in the Google Home smart speaker installed a backdoor account that could be used to remotely control it and turn it into a spy device by accessing the microphone feed.

A researcher discovered the issue and was awarded $107,500 for responsibly reporting it to Google last year. Earlier this week, the researcher released technical details of the discovery and an attack scenario to show how the flaw could be exploited.

Compromise process

While experimenting with his own mini Google Home speaker, the researcher discovered that new accounts added using the Google Home app could send commands to it remotely via the cloud API.

Using an Nmap scan, the researcher found the local Google Home HTTP API port, so he set up a proxy to capture encrypted HTTPS traffic, hoping to retrieve the authorization token of the user.

The researcher discovered that adding a new user to the target device is a two-step process that requires the device name, certificate, and “cloud ID” from its local API. With this information, they could send a link request to the Google server.

To add a malicious user to a target Google Home device, the analyst implemented the binding process in a Python script that automates data exfiltration from the local device and replicates the binding request.

The attack is summarized in the researcher’s blog as following:

1. The attacker wants to spy on the victim in wireless proximity to Google Home (but does NOT have the victim’s Wi-Fi password).
2. The attacker discovers the victim’s Google Home by listening for MAC addresses with prefixes associated with Google Inc. (eg E4:F0:42).
3. The attacker sends dead packets to disconnect the device from its network and put it into configuration mode.
4. The attacker connects to the device’s configuration network and requests their device information (name, certificate, cloud ID).
5. The attacker connects to the internet and uses the obtained device information to link their account to the victim’s device.
6. The attacker can now spy on the victim via his Google Home on the Internet (no need to be near the device anymore).

The searcher published on GitHub three PoCs for the actions above. However, these should not work with Google Home devices running the latest firmware.

PoCs go one step further than implanting a malicious user and allow snooping on the microphone, making arbitrary HTTP requests to the victim’s network, and reading/writing arbitrary files on the device.

Possible consequences

Having a rogue account linked to the target device allows actions to be performed through the Google Home speaker, such as controlling smart switches, making online purchases, remotely unlocking doors and vehicles, or stealthily force user PIN for smart locks.

More worryingly, the researcher has found a way to abuse the “call [phone number]by adding it to a malicious routine that would activate the microphone at a specific time, call the attacker’s number, and send a live microphone stream.

During the call, the LED on the device would turn blue, which is the only indication that an activity is taking place. If the victim notices it, they can assume that the device is updating its firmware. The standard microphone activation indicator is a pulsating LED, which does not occur during calls.

Finally, it is also possible to play media on the compromised smart speaker, rename it, force a restart, force it to forget stored Wi-Fi networks, force new Bluetooth or Wi-Fi pairings, and more.

Google fixes

The analyst discovered the issues in January 2021 and sent additional details and PoCs in March 2021. Google resolved all issues in April 2021.

The patch includes a new invite-based system for managing account links, which blocks all unadded attempts on Home.

Google Home deauthentication is still possible, but this cannot be used to bind a new account, so the local API that leaked the basic device data is also inaccessible.

As for “the call [phone number]”, Google has added protection to prevent its remote initiation via routines.

It should be noted that Google Home was released in 2016, scheduled routines were added in 2018, and the Local Home SDK was introduced in 2020, so an attacker finding the problem before April 2021 would have had all the time to enjoy it.