Smart speakers, like Google Home, have become increasingly popular in recent years for their convenience and functionality. They allow users to control their home, access information, and play music using voice commands. However, a security researcher has recently discovered that these devices may not be as secure as users might think they are. The researcher, who goes by the name Matt Kunze, published a technical write-up earlier this week detailing the vulnerabilities he discovered in the Google Home smart speaker.
The researcher began investigating the 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 the device gave the user a significant amount of control over it, including the ability to create "routines" – shortcuts for running a series of commands – and install "actions" (tiny applications).
Kunze became concerned about the potential security risks when he realized that anyone with an account linked to the device could send it commands remotely through the "routines" feature. He then decided to investigate the linking process to determine how easy it would be for an attacker to link an account and potentially gain access to the device.
To investigate further, Kunze wanted to intercept and analyze the traffic between a Google Home app and a Google Home device, as well as between the app and Google"s servers. To do this, he set up a proxy server using mitmproxy and configured his phone to route all traffic through the proxy. However, Google had started using HTTPS, which made intercepting the traffic more challenging. To bypass this, Kunze used a rooted phone and a Frida script to bypass SSL pinning and successfully intercept the encrypted traffic. He then examined the link process between a Chromecast and a Google Home app, and was able to replicate it to successfully link his account to a Google Home device.
Upon looking at the network info, Kunze found a POST request being made to a specific endpoint on Google"s servers with a Protocol Buffers payload, which he was able to decode using the protoc tool. By modifying this request and replacing the Chromecast"s information with the Google Home"s information, he was able to successfully link a new account to the Google Home. He then created a Python script that used the gpsoauth library and a .proto file to recreate the process of linking a new account to a Google Home device without the need for the app.
The researcher found that it is easy to disconnect a nearby device from its Wi-Fi network by sending a "deauth" packet to the target device and putting it into a “setup” mode. The Google Home Mini does not support encrypted management frames (802.11w or WPA3), which makes it vulnerable to this type of attack. The researcher demonstrated this by using aircrack-ng to launch a deauth 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 observed that the victim may not notice any unusual activity, as the device"s LED will turn solid blue, which is usually associated with firmware updates, and the microphone activation indicator will not pulse during a call.
Here is how it looks when a call is initiated remotely -
Kunze summarized a possible attack scenario as follows:
- Attacker wishes to spy on victim. Attacker can get within wireless proximity of the Google Home (but does NOT have the victim’s Wi-Fi password).
- Attacker discovers victim’s Google Home by listening for MAC addresses with prefixes associated with Google Inc. (e.g. E4:F0:42).
- Attacker sends deauth packets to disconnect the device from its network and make it enter setup mode.
- Attacker connects to the device’s setup network and requests its device info.
- Attacker connects to the Internet and uses the obtained device info to link their account to the victim’s device.
- Attacker can now spy on the victim through their Google Home over the Internet (no need to be within proximity of the device anymore).
Kunze also published three proof-of-concepts (POCs) on GitHub although none of them work anymore as Google has already fixed the security flaws. The repository rather serves as documentation and preservation of the examples.
Google fixed the vulnerabilities in April 2021 with a patch that included a new invite-based system for handling account links and blocked any attempts not added on the Home device. The patch also made it impossible 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 the remote initiation of the "call [phone number]" command through routines.
It is worth noting that these vulnerabilities were present for a significant amount of time before they were discovered and addressed, as Google Home was released in 2016 and the vulnerabilities were not fixed until 2021.
Smart home devices are becoming increasingly 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 users" privacy and prevent potential abuse.
Kunze was rewarded with a bug bounty of $107,500 for his work.
Source: Matt Kunze via: The Hacker News, Bleeping Computer
For those interested in participating in bug bounty programs and helping to identify and report security vulnerabilities, Google offers a platform called Google Bug Hunter.