Vulnerabilities in Google Home Smart Speakers Allowed Eavesdropp Users

Vulnerabilities in Google Home columns
Written by Emma Davis

Last year, an information security specialist discovered dangerous vulnerabilities in Google Home smart speakers that allowed listening to users.

The problems made it possible to create a backdoor account and use it 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 a bug bounty program.

Let me remind you that we also wrote that Microsoft spent twice more than Google on bug bounty programs last year, and also that Facebook (Meta) expands the bug bounty program to combat scraping.

Now that the problems have been fixed, the expert, hiding under the nickname DownrightNifty, has published on his blog a detailed technical description of the bugs, as well as various attack scenarios in which the vulnerabilities could be exploited.

It all started when, while studying his own Google Home Mini speaker, the researcher discovered that new accounts added using the Google Home app can remotely send commands to the device via a cloud API.

Interested in this functionality, he used Nmap and found the local HTTP API port of Google Home, and then set up a proxy server to intercept encrypted HTTPS traffic, hoping to intercept the user’s authorization token.

Vulnerabilities in Google Home columns

In the end, it turned out that adding a new user to the target device is a two-step process that requires a device name, certificate, and cloud ID from the local API. With this information, the column could generate a linking request to the Google server.

To create an account on the target column for a potential attacker, DownrightNifty wrote a Python script that automates the extraction of data from the local device and reproduces the request to link a new account.

Vulnerabilities in Google Home columns

As a result, the researcher describes the theoretical attack on Google Home as follows.

  1. The attacker wants to spy on his victim while within range of the Google Home wirelessly (but does NOT have the victim’s Wi-Fi password).
  2. The attacker finds the victim’s Google Home by listening to MAC addresses with prefixes associated with Google Inc. (e.g. E4:F0:42).
  3. The attacker sends deauthentication packets to disconnect the device from the network and put it into setup mode.
  4. The attacker connects to the device setup network and requests information about the device (name, certificate, cloud ID).
  5. The attacker connects to the Internet and uses the obtained device information to link his account to the victim’s device.
  6. The attacker gets the opportunity to spy on the victim through his Google Home, over the Internet (no need to be near the target device anymore).

The media also reported that Researchers developed a method for intercepting data from smartphone speakers.

As an appendix to his article, the researcher published three PoC exploits on GitHub to perform the above actions. Moreover, these exploits allow not only to inject a new user on the victim’s device, but also to spy on the target through a microphone, make arbitrary HTTP requests on 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.

In the blog, the expert explains that having an account associated with the target device allows to perform a variety of actions through Google Home, for example: control smart switches, shop online, remotely open doors and unlock vehicles, and even covertly brute force PIN codes. from smart locks.

Even worse, the researcher found a way to abuse the “call [phone number]” command and created a malicious procedure (routine) that activates the microphone at a specified time, calls the attacker’s number and arranges for him to live broadcast everything that happens near the victim’s microphone.

Vulnerabilities in Google Home columns

The only indicator of such wiretapping will be the device’s LED, which will turn blue during a call. But even if the victim pays attention to this, he may assume that the device is just updating the firmware, since the standard microphone on indicator is a blinking LED, and during a call it does not blink.

DownrightNifty also says that he was able to play media on a compromised device, rename the speaker, force reboot it, make it “forget” saved Wi-Fi networks, force it to pair with new Bluetooth and Wi-Fi devices, and perform many other actions.

The researcher discovered this whole bunch of problems back in January 2021, in March he provided Google with additional information about bugs and PoC exploits, and in April 2021, Google engineers fixed all the flaws discovered by DownrightNifty.

The released patch includes a new system for adding linked accounts based on invitations, which blocks any attempts to link a device to an account that is not added to the column itself.

Google Home deauthentication is still possible, but it can no longer be used to link a new account, because the local API that leaked the device’s basic data is no longer available.

As for the “call [phone number]” command, Google has added a separate protection to prevent it from being triggered remotely.

And while all bugs are now closed, DownrightNifty notes at the end of its article that Google Home columns appeared back in 2016, the ability to add scheduled procedures was added in 2018, and the Local Home SDK was introduced in 2020. That is, the attackers had a lot of time to discover the same problems that he eventually found, and use them at their discretion.

User Review
0 (0 votes)
Comments Rating 0 (0 reviews)

About the author

Emma Davis

I'm writer and content manager (a short time ago completed a bachelor degree in Marketing from the Gustavus Adolphus College). For now, I have a deep drive to study cyber security.

Leave a Reply