Earlier this year we tested the Amazon Echo device and it’s voice assistant Alexa. In this test, we will take a closer look at its new emerging contender: Google Home.
Google Home means Chromecast
The Google Home was created by Google’s Chromecast team – therefore you can describe it as a smarter Chromecast with a speaker and a dual microphone array. This and other hardware information can be found at the very detailed Google Home teardown of iFixit.
When removing the base, a Micro-USB port can be found on the back of the device. When pressing the Mute-Button at boot time, a “bootloader mode” is being started which shows up a device “BG2CD” in the device manager of Windows, but only for about a second or two. According to a kernel.org documentation, BG2CD is the “design name” of the Marvell-SoC of the Google Home, so this boot mode can presumably be used for SoC-Updates. Also, it has USB-OTG capabilities, i.e. for the Chromecast Ethernet Adapter (although not officially). Also, four hidden debug ports can be found at the bottom of the device, with unknown / undocumented function, but presumably debugging or manufacturing purposes.
Like Amazon Alexa, Google Assistant’s intelligence comes from the cloud – only the processing of the “OK Google” keyword takes place offline. The assistant is well-integrated into the Google services, therefore can profit from Googles existing knowledge of the user, like browser, search and location history, if allowed by the owner. In difference to Alexa, Google already implemented a multiuser option and can detect different family members. (We couldn’t dive deep into this feature, because it isn’t yet available in Germany). The detection is done with a kind of voice recognition – but doesn’t seem to be out of flaws, like you can see in the following video, where a child disguises his voice and is being recognized as his mother (https://www.youtube.com/watch?v=FfxhwKl9-2w).
Checking the App
The Google Home App is being used for initial setup and for further configuration, like adding Smart Home devices.
All interesting and relevant classes are obfuscated. The shared preferences of the app are saved securely within the private app storage, although not encrypted. Despite the hurdle of source code analysis by the obfuscation, we were able to identify and test some unencrypted HTTP endpoints of the Google Home. (see: Local communication)
Online communication
Well-encrypted communication can be found, when monitoring the online communication of the Google Home. Several Google servers as well as Amazon AWS (TuneIn Radio queries) were being contacted TLS1.2-encrypted.
As you may also know from our Amazon Alexa test, we used a little scenario for simulating the usage at home:
- ~6 seconds of silence
- “Ok Google, tell me a joke” and awaiting the answer (~13 seconds)
- ~6 seconds of silence
- “Ok Google, tell me a joke” and awaiting the answer (~13 seconds)
- A normal conversation without using the “Ok Google” keyword
The figure shows the transmitted bytes (up- and download) with a resolution of 100ms. The traffic raises, when the “OK Google” keyword is spoken and ends a few moments before it’s answer ends. In moments of silence or normal conversation, no significant traffic can be observed. Therefore, we can rule out, that private conversations are uploaded to Google servers.
As voice assistants are configured to listen immediately, when the keyword is spoken, their keyword detection also allows some misspellings (“Olé Google”) – and misunderstandings, which is technically necessary to make it work properly. But, this can result in accidentally recorded conversations, which shouldn’t be uploaded to the Cloud.
Local communication
The configuration of the Google Home via the according App uses Home’s integrated HTTP-API on Port tcp/8008, similar to Google Chromecast. Because this API is being accessed without authentication or encryption, we managed to execute commands via POST requests, like the following one:
curl – H ‘Content-Type: application/json’ \
– H ‘User-Agent: com.google.android.apps.chromecast.app/1.24.37.7 (Linux; U; Android
6.0.1; Nexus 5 Build/M4B30Z)’ \
– X POST – d ‘{“name”:”NewName”}’ http: //IPofGHome:8008/setup/set_eureka_info
Which allows changing the Google Home’s display name. Some more-exciting things are also possible:
- Changing volume of alarms
- /setup/assistant/alarms/volume
- {“volume”:0.17}
- Activating Beta-Firmware access
- /setup/set_eureka_info
- {“opt_in”:{“preview_channel”:true}}
- Rebooting the Google Home
- /setup/reboot
- {“params”:”now”}
- Connecting to another WiFi network
- /setup/connect_wifi
- Request wasn’t successful (“500: Server Error”)
- Immediately deleting the WiFi access data
- /setup/forget_wifi
- {“wpa_id”:0}
We were quite surprised that these commands don’t require any authentication. A correct User-Agent string was sufficient. The request “forget_wifi” made our device unusable until a full reset to factory settings (pressing the mute button for 15 seconds) and reconfiguring it
We’ve seen many Windows Malware types which scan the network for additional infection targets. We could imagine a Windows Malware which simply throws all found Google Homes out of the WiFi network (or worse, if other API commands also work).
Privacy
Google made a very good job in their privacy overview for the Google Home, which simply explains, which data is being recorded and which data can be accessed by Google Home or the Google Assistant.
As already mentioned, it can access your browser, search and location history as well as data of other Google services like YouTube. Also, it can gather data from integrated third-party services, like Spotify.
Also, Google’s privacy policy is well-structured and versioned – you can look back all versions until 2001. It can be easily understood by 19- to 20-year-olds. (Flesch Kincaid Reading Ease)
As personal data is being transferred and stored encrypted, we would normally speak of a safe-to-use solution. In case of voice assistants, the manufacturer records sensitive, biometric data, which can be used to identify you (also used in the multi user feature), in theory also across devices and locations. The privacy concerns exist, but can’t be proved. The user should always keep in mind, that more and more parts of his life are being tracked by global players.
Conclusion
Google Home passed our Quick Check with some concerns in the local communication part. Even if we were not able to connect it to another WiFi without the owner’s knowledge (we got 500: Server Error, when trying to execute the “connect_wifi” request), we were able to delete the current WiFi Credentials and hence had to reset the device to factory defaults. Assuming that the local network is secure, free from malware or attackers and doesn’t need encryption when accessing critical services, can be very dangerous – we think that Google should resolve this issue as soon as possible.
Because voice assistants are placed in the most private area, we rate flaws more critically. Therefore, we will only award the Google Home with two out of three stars. As soon as the local API gap is fixed, the rating will also improve to three stars.
Pingback: AV-TEST awards manufacturers for Approved Smart Home Security – AV-TEST Internet of Things Security Testing Blog
Pingback: Messing with Google Home devices – Techrevelations
Pingback: Smart TV: uma porta de acesso para hackers? | ESET Portugal - blog