Google Home speakers allowed hackers to snoop on conversations

A bug in the Google Home smart speaker allowed the installation of a backend account that could be used to remotely control it and turn it into a listening device by accessing the microphone feed.

Researcher Matt Kunze discovered the problem and received $107,500 for responsible reporting to Google last year. Earlier this week, the researcher published technical details about the finding and an attack scenario to show how the flaw could be exploited.

The compromise process

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

Using an Nmap scan, the researcher found the gateway for Google Home’s local HTTP API, so he created a proxy to intercept the encrypted HTTPS traffic, hoping to grab the user’s authorization token.

HTTPS traffic captured (encrypted) (downrightnifty.me)

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

To add a rogue user to a target Google Home device, the analyst implemented the connection process in a Python script that automated exfiltrating the device’s local data and replayed the connection request.

Connection request carrying device ID data (downrightnifty.me)

The attack is summarized on the researcher’s blog as follows:

The attacker wants to spy on the victim within wireless range of the Google Home (but does NOT have the victim’s Wi-Fi password). The attacker discovers the victim’s Google Home by listening for MAC addresses with prefixes associated with Google Inc. (eg E4:F0:42). The attacker sends deauth packets to disconnect the device from its network and make it enter configuration mode. The attacker connects to the device’s configuration network and requests its device’s information (name, certificate, cloud ID). The attacker connects to the Internet and uses the obtained device information to link his account to the victim’s device. The attacker can now spy on the victim through the Google Home on the Internet (no need to be closer to the device).

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

PoCs take things a step further than simply planting a rogue user and enable spying through a microphone, making arbitrary HTTP requests to the victim’s network, and reading/writing arbitrary files to the device.

Possible implications

Having a rogue account associated with the target device makes it possible to perform actions through the Google Home speaker, such as controlling smart switches, making online purchases, remotely unlocking doors and vehicles, or forcing a secret PIN code of users for smart locks.

More disturbingly, the researcher found a way to abuse the “call [phone number]” command by adding it to a malicious routine that would activate the microphone at a certain time, calling the attacker’s number and sending a live microphone feed.

Malicious drive that captures microphone audio (downrightnifty.me)

During the call, the device’s LED would turn blue, which is the only indication that any activity is occurring. If the victim notices it, they can assume that the device is updating its firmware. The standard indicator of microphone activation is a flashing LED, which does not occur during calls.

Finally, it’s also possible to play media on the compromised smart speaker, rename it, force a reboot, force it to forget saved Wi-Fi networks, force new Bluetooth or Wi-Fi pairings, and more a lot.

Google rules

Kunze discovered the issues in January 2021 and submitted additional details and the PoC in March 2021. Google fixed all issues in April 2021.

The patch includes a new invitation-based system to handle account connections, which blocks any attempts that haven’t been added to Home.

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

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

It’s worth noting 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 who found the issue before April 2021 would have plenty of time to take advantage.