Wiretapping Google smart speakers | Hacker News Reader

Wiretapping Google smart speakers

downrightnifty.me

268 pointsNotPractical24 comments

Note also that if the devices are deauthed from their wi-fi and cannot reassociate, they will turn into APs themselves with the name "<device name>.m" without a password.

I reported this to Google and they said it's not a bug but is working as intended. I asked them "What if the device name is 'Project Dragonfly v2 Conference Room'?" They said it's still not a bug.

This of course leaks the device name to the public (via wi-fi beacon packets) along with allowing anyone in range to access the APIs on the device.

> I asked them "What if the device name is 'Project Dragonfly v2 Conference Room'?"

> This of course leaks the device name to the public

Leaking the sound from that room is potentially serious, but I thought the whole point of project codenames was that it's fine when the codename inevitably leaks to the public.

In some cases even the codewords themselves are classified.

Easy solution: use a non-sensitive codename to refer to the classified codename. :D

Hehe. Codenames all the way down :)

Project Dragonfly was claimed, by Google, to be cancelled. If there exists a "Project Dragonfly v2", with a conference room, that's headline news.

Very nice write-up and creative exploits.

> That got me thinking, maybe I could provide a scan configuration that instructs the Google Home to scan for itself

This was my favorite bit of creativity. Great work!

Other devices mitigate this attack vector by at least requiring physical access to the device or it's packaging (they require authorization with the serial number or some other secret on the device, or pressing a button on the device)

This is basically worst case scenario. Something lots of people have predicted for the last 10+ years.

Kudos to the person that found the bug.

Kudos to Google for not being the slimy people we expect them to be and actually paid some money.

An exploit like this is worth millions on the black market. The mere chance that a target has a Google smart speaker in their home that can be exploited with this is worth millions. Not every target needs a Google smart speaker for it to be valuable. Only one makes it worth millions, because that target is probably important.

It's not the worst case. You still need access to the local network the device is on as far as I can tell. Hopefully you can't do it from a web page...

No you just need to be close enough to access Wi-Fi from the device. Driving by in a car would do

> wireless proximity of the Google Home (but does NOT have the victim’s Wi-Fi password)

Given this, I don’t fully understand the below:

> listening for MAC addresses with prefixes associated with Google

How do you scan MACs without being on the network? Is it like Bluetooth, where everything is constantly broadcasting?

> Attacker sends deauth packets to disconnect the device from its network

How does one send packets to 192.168.X.Y without being on that network already?

« WPA2 provides strong encryption for data frames (as long as you choose a good password). However, “management” frames, like deauthentication frames (which tell clients to disconnect) are not encrypted. 802.11w and WPA3 support encrypted management frames, but the Google Home Mini doesn’t support either of these. »

> How do you scan MACs without being on the network? Is it like Bluetooth, where everything is constantly broadcasting?

It's actually the opposite—WiFi broadcasts MAC addresses in the clear (although likely a random one per-network on modern devices) even with WPA, while BLE can use an Identity Resolving Key when it's not in active discovery mode. This way, a Random Resolvable Private Address can be created that only the paired device can decrypt and find the actual MAC address.

> How does one send packets to 192.168.X.Y without being on that network already?

It's not sending IP packets; the attacker figures out the wi-fi MAC of the client they want to deauth, then spoofs that MAC in 802.11 "deauth" frames sent to the access point. The access point then complies by cleaning up whatever data structures it's using to keep track of the client, and when it receives the next packets from the client, it doesn't know who it's talking to anymore.

The attacker doesn't need to authenticate to the wifi network to send these frames. At the most they might need root/admin on their machine because you have to send custom packets and that's generally restricted, but as the original article said, there are custom boards that are designed just for deauthing attacks.

Great writeup!

> Closed (Intended Behavior)

Christ, this is depressing.

Clearly given it was reopened after providing more details this was a misunderstanding or triage mistake. Given the volume of reports this must happen all the time, and was resolved here as expected.

Well, I read through most of the article, and felt like "well, this is work as intended". Except the "consider localhost for debugging" part, I don't see any bug anywhere, only UX choices.

In my understanding of TFA, every "trick" until "I can make silent calls" were explicitly made available by Google on purpose and could have been done without reverse engineering by using the standard smartphone Google app (except for wifi deauth -- but the resulting behavior of instantly making an AP is wanted by Google. I personally would have made this happen only on startup, not even for security reasons)

And well, that's the scary part I guess: that this system is so big, that Google can't control all the ins and outs of the various UX choices.

One thing I don't understand, is that Chromecast were historically famous for pairing over ultrasound, guaranteeing physical presence. And to this day, ultrasound support is still a hard requirement for all Google/Android devices for that feature. Has this been completely abandoned? Don't Chromecast <=> Google Home team discuss?

Question - could you just send ultrasound though the walls just like the wifi signals in this example? I guess I'm not sure how much more limited ultrasound would be in this case.

No. Ultrasound will not make it to the other side of a wall, especially not an outside wall.

Infrasound could, but the speakers might not be big enough, unless you use the amplitude trick.

It doesn't go through walls, so they are pretty much the right tools for the job. They are known vulnerable to lasers, but well microphones themselves are, so...

Hi - author of the article here. I actually did try to accomplish this attack without reverse engineering but it wasn't possible. The Google Home app would not allow you to connect to a device through its setup mode AP if you weren't using an account that was previously linked to the device (while it was online). You'd get this error if you tried: https://i.imgur.com/ipC3OhE.png

Behind the scenes you see (via MITM) that it tries to connect, but the device rejects the request because it doesn't have the local auth token (which can only be retrieved using a linked account).

This is a good design: the device owner (or any other previously linked users) are allowed to reconfigure the device while it's in setup mode if this is ever needed, but unauthenticated users cannot. And if the device owner loses access to their account somehow, they can use the factory reset button on the bottom of the device to set it up with a new account. (Unfortunately, it was broken, as I described.)

So I think the main "bug" here was the exposure of the "cloud_device_id" and other sensitive device information required to link an account in setup mode, even though it's not used by the Home app to reconnect a device to Wi-Fi. My suggested fix was simply to stop returning this info in setup mode. Last I checked this behavior hasn't changed though so I guess it was easier to make changes on the server side to fix the issue.

Btw, they later updated the Home app's UI to provide a more descriptive error message than just "could not communicate": https://i.imgur.com/ISWk4Bj.png

Reply on news.ycombinator.com