Man
Professional
- Messages
- 3,077
- Reaction score
- 614
- Points
- 113
Last year, an information security specialist discovered dangerous vulnerabilities in Google Home smart speakers. The problems allowed a backdoor account to be created and used to remotely control the device, effectively turning the speaker into a spy device with access to the microphone. Given the complete compromise of the smart speaker, Google paid the researcher $107,500 as part of the bug bounty program.
Now that the issues have been fixed, an expert who goes by the name DownrightNifty has published a detailed technical description of the bugs on his blog, as well as various attack scenarios in which the vulnerabilities could be used.
It all started when, while studying his own Google Home Mini speaker, the researcher discovered that new accounts added using the Google Home app could remotely send commands to the device via a cloud API.
Intrigued by this functionality, he used Nmap to find the Google Home local HTTP API port, then set up a proxy to intercept encrypted HTTPS traffic, hoping to intercept the user's authorization token.
It turned out that adding a new user to a target device was a two-step process that required the device name, certificate, and cloud ID from the local API. With this information, the speaker could generate a linking request to Google's server.
To create an account for a potential attacker on the target speaker, DownrightNifty wrote a Python script that automated the extraction of data from the local device and reproduced the request to link a new account.
In the end, the researcher describes the theoretical attack on Google Home as follows.
As an appendix to his paper, the researcher published three PoC exploits on GitHub to perform the above actions. Moreover, these exploits allow not only to introduce a new user to the victim's device, but also to spy on the target via the microphone, make arbitrary HTTP requests to the victim's network, and read/write arbitrary files on the compromised speaker.
DownrightNifty emphasizes that all this will not work on devices with the latest firmware version.
In the blog, the expert explains that having an account associated with the target device allows you to do a variety of things through Google Home, such as: control smart switches, shop online, remotely open doors and unlock vehicles, and even secretly brute-force smart lock PINs.
Even worse, the researcher found a way to abuse the “call [phone number]” command and created a malicious routine that would activate the microphone at a specified time, call the attacker’s number, and broadcast everything that happens near the victim’s microphone to him.
The only indicator of such wiretapping will be the device's LED, which will light up blue during a call. But even if the victim pays attention to this, he may assume that the device is simply updating the firmware, since the standard indicator of microphone activation is a blinking LED, and it does not blink during a call.
DownrightNifty also says he was able to play media on the compromised device, rename the speaker, force it to reboot, make it “forget” saved Wi-Fi networks, force it to pair with new Bluetooth and Wi-Fi devices, and do many other things.
The researcher discovered this entire bouquet of problems back in January 2021, provided Google with additional information about the bugs and PoC exploits in March, and in April 2021, Google engineers fixed all the flaws discovered by DownrightNifty.
The released patch includes a new invite-based linked account system that blocks any attempts to link the device to an account that has not been added to the speaker itself.
Deauthenticating Google Home is still possible, but it can no longer be used to link a new account because the local API that was leaking the device's core data is no longer available.
As for the "call [phone number]" command, Google has added a separate protection to prevent it from being run remotely.
And while all the bugs are now closed, DownrightNifty notes at the end of his article that Google Home speakers were released back in 2016, the ability to add scheduled routines was added in 2018, and the Local Home SDK was introduced in 2020. That means attackers have had plenty of time to discover the same problems he eventually found and exploit them as they saw fit.
Source
Now that the issues have been fixed, an expert who goes by the name DownrightNifty has published a detailed technical description of the bugs on his blog, as well as various attack scenarios in which the vulnerabilities could be used.
It all started when, while studying his own Google Home Mini speaker, the researcher discovered that new accounts added using the Google Home app could remotely send commands to the device via a cloud API.
Intrigued by this functionality, he used Nmap to find the Google Home local HTTP API port, then set up a proxy to intercept encrypted HTTPS traffic, hoping to intercept the user's authorization token.

It turned out that adding a new user to a target device was a two-step process that required the device name, certificate, and cloud ID from the local API. With this information, the speaker could generate a linking request to Google's server.
To create an account for a potential attacker on the target speaker, DownrightNifty wrote a Python script that automated the extraction of data from the local device and reproduced the request to link a new account.

In the end, the researcher describes the theoretical attack on Google Home as follows.
- The attacker wants to spy on their victim while within wireless range of the Google Home (but does NOT have the victim's Wi-Fi password).
- The attacker finds the victim's Google Home by listening for MAC addresses with prefixes associated with Google Inc. (e.g. E4:F0:42).
- The attacker sends deauthentication packets to disconnect the device from the network and put it into setup mode.
- The attacker connects to the device's setup network and requests information about the device (name, certificate, cloud ID).
- The attacker connects to the internet and uses the obtained device information to link their account to the victim's device.
- The attacker is able to spy on the victim through their Google Home, via the Internet (there is no longer a need to be near the target device).
As an appendix to his paper, the researcher published three PoC exploits on GitHub to perform the above actions. Moreover, these exploits allow not only to introduce a new user to the victim's device, but also to spy on the target via the microphone, make arbitrary HTTP requests to the victim's network, and read/write arbitrary files on the compromised speaker.
DownrightNifty emphasizes that all this will not work on devices with the latest firmware version.
In the blog, the expert explains that having an account associated with the target device allows you to do a variety of things through Google Home, such as: control smart switches, shop online, remotely open doors and unlock vehicles, and even secretly brute-force smart lock PINs.
Even worse, the researcher found a way to abuse the “call [phone number]” command and created a malicious routine that would activate the microphone at a specified time, call the attacker’s number, and broadcast everything that happens near the victim’s microphone to him.

The only indicator of such wiretapping will be the device's LED, which will light up blue during a call. But even if the victim pays attention to this, he may assume that the device is simply updating the firmware, since the standard indicator of microphone activation is a blinking LED, and it does not blink during a call.
DownrightNifty also says he was able to play media on the compromised device, rename the speaker, force it to reboot, make it “forget” saved Wi-Fi networks, force it to pair with new Bluetooth and Wi-Fi devices, and do many other things.
The researcher discovered this entire bouquet of problems back in January 2021, provided Google with additional information about the bugs and PoC exploits in March, and in April 2021, Google engineers fixed all the flaws discovered by DownrightNifty.
The released patch includes a new invite-based linked account system that blocks any attempts to link the device to an account that has not been added to the speaker itself.
Deauthenticating Google Home is still possible, but it can no longer be used to link a new account because the local API that was leaking the device's core data is no longer available.
As for the "call [phone number]" command, Google has added a separate protection to prevent it from being run remotely.
And while all the bugs are now closed, DownrightNifty notes at the end of his article that Google Home speakers were released back in 2016, the ability to add scheduled routines was added in 2018, and the Local Home SDK was introduced in 2020. That means attackers have had plenty of time to discover the same problems he eventually found and exploit them as they saw fit.
Source