Hacker News Reader

Comment by misnome | Hacker News Reader

> Closed (Intended Behavior)

Christ, this is depressing.

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?

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

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.

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...

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.

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.

Reply on news.ycombinator.com