Smart speakers, such as Google Home, have become increasingly popular in recent years due to their convenience and functionality. They allow users to control their home, access information and play music using voice commands. However, a security researcher recently discovered that these devices may not be as secure as users may think they are. The researcher, who goes by the name Matt Konza, Publish a technical article Earlier this week he detailed the vulnerabilities he discovered in the Google Home smart speaker.

The researcher began investigating Google Home after noticing how easy it was to add new users to the device from the Google Home app. He found that linking an account to a device gave the user a significant amount of control over it, including the ability to create “routines” — shortcuts to run a series of commands — and install “actions” (tiny apps).

Konza became concerned about the potential security risks when he realized that anyone with an account linked to the device could send commands to it remotely through the “routine” feature. He then decided to investigate the linking process to determine how easy it would be for an attacker to link an account and possibly gain access to the device.

To investigate further, Konza wanted to intercept and analyze the traffic between the Google Home app and the Google Home device, as well as between the app and Google servers. To do this, he set up a proxy server using mitmproxy and set his phone to route all traffic through the proxy. However, Google started using HTTPS, which made intercepting traffic more challenging. To get around this, Kunze used a rooted phone and a Frida script to bypass SSL pinning and successfully intercepted the encrypted traffic. He then looked into the linking process between Chromecast and the Google Home app, and was able to replicate it to successfully link his account to the Google Home device.

Looking at the network information, Kunze found a POST request made to a specific endpoint on Google’s servers with the Buffers protocol payload, which he was able to decode using the protok tool. By modifying this request and replacing the Chromecast information with the Google Home information, he was able to link a new account to the Google Home. He then created a Python script that used the gpsoauth library and .proto file to recreate the process of linking a new account to a Google Home device without the need for an app.

The researcher found that it is easy to disconnect a nearby device from its Wi-Fi network by sending a “death” packet to the target device and putting it into “setup” mode. Google Home Mini does not support encrypted management frameworks (802.11w or WPA3), which makes it vulnerable to this type of attack. The researcher demonstrated this by using aircrack-ng to launch a death attack on their Google Home, causing it to disconnect from the network and create its own. Kunze was able to connect to the new network and use netstat to get the IP of the router (the Google Home) and successfully issue a local API request.

This is how the researcher was able to successfully link to his Google Home Mini remotely and control it. He also noted that the victim may not notice any unusual activity, as the device’s LED will turn blue, which is usually associated with firmware updates, and the microphone activation indicator will not blink during a call.

This is what it looks like when a call is made remotely –

Konza summarized a possible attack scenario as follows:

1. The attacker wants to spy on the victim. The attacker can get within wireless proximity of Google Home (but doesn’t 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 death packets to disconnect the device from its network and cause it to go into setup mode.
4. The attacker connects to the device’s installation network and requests the details of his device.
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 can now spy on the victim through their Google Home via the Internet (no need to be near the device anymore).

Konza also published Three Proof of Concepts (POCs) on GitHub Although none of them work anymore because Google has already fixed the security flaws. The database is actually used as a documentation and preservation of the examples.

Google patched the vulnerabilities in April 2021 with a patch that included a new invitation-based system for handling account links and blocked any attempts not added on the home device. The patch also made it possible to deauthenticate the device in a way that could be used to link a new account and made the local API inaccessible. In addition, Google added protection to prevent remote activation of the “conversation [phone number]”To command through a routine.

It is worth noting that these vulnerabilities existed for a significant period of time before they were discovered and addressed, as Google Home was released in 2016 and the vulnerabilities were not patched until 2021.

Smart home devices are becoming more and more common in homes and offer convenient features and functionality, but they also pose potential risks to users’ privacy and security. It is important for manufacturers to prioritize security in the development of these devices to protect user privacy and prevent potential misuse.

Kunze won a $107,500 bug award for his work.

source: Matt Konje Through: Hacker news, Creepy computer

---

For those interested in participating Debug programs And to help identify and report security vulnerabilities, Google offers a platform called Google Bug Hunter.

Learn more by clicking here.