
Google Home (in)Security - hyperpape
https://jerrygamblin.com/2018/10/29/google-home-insecurity/
======
pkulak
So what's the concern here; that when someone gets unfettered access to your
local network they can reboot your Google Home? Ya know what else they can do?
Play Rick Astley on your Sonos speakers while printing 1000 pages of porn from
every printer, casting Rick Astley music videos to every TV, getting Comcast
to forward you piracy warnings and deleting all your Redis tables and Elastic
Search indexes.

~~~
vvanders
In my mind it's a pretty gross violation of the principal of least
privilege[1]. All it takes is one bad IoT device on your local LAN to
exfiltrate/pivot over to the Hub. Some of the data that's dumped is things
like "noise levels" which borders on sensitive PII information. Not to mention
any vulnerabilities in these services that aren't understood yet.

For all those reasons and more the IoT stuff on my local network goes into a
VLAN that only gets to see the gateway and nothing else. No local UDP, TCP or
the like, the Ubiquiti gear I picked up a while back makes it pretty trivial
to setup.

[1]
[https://en.wikipedia.org/wiki/Principle_of_least_privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)

~~~
stephengillie
We need an internet of firewalls. I dislike tech legislation, but sometimes I
think all networked devices should be required to have an internal firewall.

~~~
georgyo
Many of these devices have to listen for something. Mdns, http, printer, etc.
Having a firewall does nothing when you have to open up the ports that are
being exploited anyway.

~~~
lrem
Well, they don't need to listen to everyone that knocks. I'm sure we would be
delighted when devices would only talk to clients with valid certificates from
the vendor, right?

Edit: disclaimer: I work for Google, but my only contact with the home
ecosystem is having a Chromecast.

~~~
TeMPOraL
Would we? The next thing that would happen is those certificates would end up
inside secure chips, and suddenly the only way to talk to an IoT device would
be through an official vendor's app, over an official vendor's bridge. No
thank you. Turning physical products into services is not what I want.

------
bradstewart
This doesn't seem like a mistake, so much as a decision to assume the LAN is
secure. It's a trade off that favors features over security. Which does seem
rather "un-Googly" though...

If it's unauthenticated, apps/devices/services can easily integrate with it.

If it is authenticated, how? Pre-shared API key? How do you initially generate
and distribute that API key? How do you access it? Now you need to encrypt
that key when you use it. TLS? Great, now you need a TLS certificate that has
to be trusted, updated, etc.

All solvable problems for sure, but at the cost of complexity, ease of
integration, etc.

~~~
harshreality
How is this difficult?

"This is the first time you are using this phone to modify the settings of
your google appliance. Please locate your google device, and press <some
button>, or tap the microphone firmly, to confirm your intent to trust this
phone."

~~~
bradstewart
It's not super difficult, particularly when the other end is a Google-provided
app on a smartphone. It gets more complicated with things like Home
Assistant[0] or other automation software.

Amazon made the decision to force all Echo integrations to go through the
internet.

[0] [https://www.home-assistant.io/](https://www.home-assistant.io/)

------
unsignedint
Google Chromecast, and Home are actually pretty horrible when it comes to
security.

For example, if you lose internet connection, they will start broadcasting
SSID. At this point, there's nothing in place to prevent someone launching
Google Home app and hijack those devices.

Even Chromecast and Hub displays codes, they are only to identify the device.
Instead of the Google Home app asking you "what are the letters shown on your
device?" it just tell you "Press OK if your device is showing ABCD" \-- that's
very dumb implementation.

I don't know why they simply couldn't stand by to wait for the network
connection to recover or require being present next to your device to press a
reset button if their Network connection really needs to be updated -- or at
_least_ used simple authentication process to provision the device

~~~
creato
> and hijack those devices.

And do what then? Serious question, I'm not a heavy user of Google
Home/Chromecast, but my impression is that even if you hijack a device this
way, the worst you can do is start streaming netflix or spotify, but with your
own account to boot (not the account owner of the device you hijacked).

~~~
dragonwriter
> And do what then?

For Assistant devices (Home, etc.) You can record (and get transcripts of) any
requests made sent a Google Account you control, which can capture personal
information.

For Cast targets, you can stream content to them (audio and possibly video,
depending on the device.)

> the worst you can do is start streaming netflix or spotify

Netflix or Spotify is probably not the worst unwanted content you could stream
into someone else's home unrequested.

~~~
magicalist
> _For Cast targets, you can stream content to them (audio and possibly video,
> depending on the device.)_

But if you're already on the wifi network, you can already stream content to
them by design. Same with the apple tv and fire tv stick.

~~~
dragonwriter
> But if you're already on the wifi network

The proposed attack is a way to take control of Home (and attach it to a new
Google Account and network) when it loses wifi connection, it neither relies
on nor provides the attacker access to the rightful owner's wifi network.

------
kornish
Evokes a great quote: "The S in IoT stands for 'security'."

------
infact19
I am 0 percent on board with home assistants and other IoT devices at this
point. You either 1) buy an expensive surveillance device from a tech giant
with an awful user privacy track record, giving them free access to your
network and conversations (and even installing a spy camera in your home for
some upcoming products, thanks but no thanks Facebook!), or 2) buy a shitty
closed-source botnet-in-a-box that was either made by a home appliance company
that has zero experience making secure software or from a startup that has
zero experience in making either home appliances or secure software.

------
amanzi
These commands don't work on my Google Home Mini device despite it having the
same open ports as the one in the article. I get a `HTTP/1.1 403 Forbidden`
response when trying to reboot it with this method.

~~~
londons_explore
Patched already perhaps?

~~~
deckar01
I suspect these ports are only supposed to be open during the initial
configuration phase. Maybe the author didn't actually finish setting up the
device or maybe Google forgot to disable the configuration ports after setup.

------
amanzi
If a bad actor get access to my LAN, rebooting my Google Home device is the
least of my concerns.

> "I am genuinely shocked by how poor the overall security of these devices
> are"

If there's a remote access exploit in the wild, then I'm going to be worried.

~~~
detaro
This looks like you could potentially hit from the browser with a DNS
rebinding attack, just by visiting a website. (Although I'm not sure how far
modern browsers defend against those by themselves)

~~~
hyperpape
I don’t think they do protect themselves
[https://twitter.com/bcrypt/status/955621661126008832](https://twitter.com/bcrypt/status/955621661126008832)

------
millstone
I'm in the "never permit these devil devices in my home" camp. A common
rebuttal is "your phone is always listening, how is an Echo / Google Home /
etc different?"

Well this answers that question: security! If my phone could be remotely
rebooted by someone on the same Wifi network, it would be considered an
enormous vulnerability. But in this thread we see lots of apologetics: "Well,
the LAN is assumed secure..."

This reaffirms my decision. Offline-only, or no thanks!

~~~
ehsankia
The Chromecast model is intentionally designed so that anyone on your local
network can play anything they want on your Chromecast, including full blast
volume porn. Considering that, how is being able to reboot your Chromecast any
worse?

The comparison to your phone doesn't hold. For one, your phone connects to all
sorts of networks, whereas these devices are on local home network only.
Second, Chromecasts are inherently shared and communal devices, whereas phones
are personal.

------
michaelmior
Of course this requires being authenticated to whatever network the Home
device is connected to.

------
eugenekolo2
~Doesn't seem to work on my Google Home Speaker (non-hub) as of 8:40PM EST.
Tried the nmap restart payload. `nmap --open -p 8008 192.168.1.0/24 | awk '/is
up/ {print up}; {gsub (/\\(|\\)/,""); up = $NF}' | xargs -I % curl -Lv -H
Content-Type:application/json --data-raw '{"params":"now"}'
[http://%:8008/setup/reboot`~](http://%:8008/setup/reboot`~)

Works after I changed to the right ip range.

~~~
helper
I tried it today with my speaker and it worked.

~~~
eugenekolo2
Yeah, my bad, my networks not 192.168.1.x

------
martimarkov
I think only 2-3 endpoints should be protected. The others are there for
information and they do provide some leakage but you already have most of that
data anyway when you auth over the WiFi.

------
harshreality
Why doesn't everything like that (affecting operation of the google appliance)
require a preshared secret that's negotiated once per remote device via:

\- pressing a button or some other physical presence confirmation on the
google device when a remote network device tries to gain credentials (Best!)

\- NFC (good because of range limitations, but annoying because of range
limitations)

\- some kind of audio handshake (hackable from longer distances maybe
extending beyond property boundaries, but so is bluetooth, and maybe with
multiple mics a device could detect a higher-powered long-range hack attempt
and filter it?) This might be the best option other than a physical button-
press. If the confirmation signal is to hit the mic gently, can you even mimic
that remotely through glass or a wall without doing something that would
possibly deafen any bystanders? Seems a _reasonable_ good compromise between
ease of use and range limitation.

\- bluetooth, especially if power can be programmatically decreased to limit
range to short-distance line-of-sight (obviously the normal bt range is a
problem, but it's better than nothing)

This is a solved problem, is it not? You only have to do that once, per remote
device that needs to use the API. What's the problem with requiring a physical
button press to trust a new device that's attempting to do something?

~~~
mrep
All those would have limitations due to inter-vendor incompatibility. I think
we need someone to develop a home IOT security standard protocol for how to
handle this.

~~~
harshreality
The app is specifically aware of the IOT device's API in order to use it at
all. Why wouldn't it be aware of the IOT device's method for presence +
intention verification?

I left out another option for adding additional authorizations (beyond the
initial setup), which should work for "important" IOT devices, like google
home or amazon echo, that are already associated with an account someone is
using and monitoring:

\- Send a confirmation prompt to the primary Google/Amazon account holder: "Do
the "do you authorize <device>/<app> to access the API on your Google/Amazon X
device?"

Standardization would be great, but implementing one or two more API calls to
deal with first-use verification of a remote app doesn't seem like a big deal
when the app is going to be doing lots of other stuff with that specific
device's API.

------
jarofgreen
> I usually would have worked directly with Google to report these issues if
> they had not previously disclosed, but due to the sheer amount of prior work
> online and committed code in their own codebase, it is obvious they know.

Can anyone explain this? Is he saying others have already reported this and
Google don't care?

------
tempodox
You might be interested in this keynote by James Mickens:

[https://www.youtube.com/watch?v=ajGX7odA87k](https://www.youtube.com/watch?v=ajGX7odA87k)

titled “Why Do Keynote Speakers Keep Suggesting That Improving Security Is
Possible?”.

------
Animats
What does it take to show that this is totally unacceptable? An overlay for
Google maps which shows who's not at home and has lots of valuable stuff,
along with an app to disable the alarm?

~~~
TeMPOraL
Did the Strava map debacle hurt the company? Doesn't look like it. So I doubt
a similar map for Google would work either.

------
jlward4th
Hopefully it also has the CORS headers for cross-origin access. ;)

------
jiveturkey
would this pass muster under the new california iot security law?

i think so, and the author should be ashamed.

------
con023
but where is the security issue? just reboot?

~~~
df24g3t36
Availability is an important part of security, as much as Confidentiality and
Integrity. Being able to reboot the device unauthenticated from the local
network is a security issue, yes.

------
orcs
Wish I was clever enough to figure this stuff out.

~~~
voltagex_
Start by running a packet capture on your home network -
[https://www.wireshark.org/](https://www.wireshark.org/)

------
gitgud
It worries me that Google - a _Trillion_ dollar company - can make these
security mistakes so easily exploitable.

My faith in these _smart_ IoT devices is completely diminished...

~~~
black6
IoT -- where the S stands for Security!

------
O2F2
In my very personal opinion, anyone who willingly decorates their home with
networked IoT devices, especially those talking to a external service, has
already lost. With the increasing number of gizmos it's more or less
inevitable that one of them (or rather all of them) ships with a gross, easy
to exploit (an definitely wormable, because you know it'll be) oversight
compromising your network because you're one of a million people getting owned
by a bored skid. You want less timeboms in your home, not more. It's silly.
Scale back, stop trying to mitigate around it and just don't buy this crap.
You wouldn't keep a hand grenade with a toothpick for a safety pin on your
desk because it'll be fine as long as everyone is really careful with it. But
like I said, that's just the very angry voice in my head shouting into the
void.

~~~
shittyadmin
Isolation is key if you use any device like this. Separate VLAN for them means
stuff like this won't even work and even if they get hacked, they'll have no
special access into your network.

