Google Home (in)Security
jerrygamblin.com
jerrygamblin.com
This is _clearly_ the user's fault yes.
You forgot one though, they might also be able to delete your MongoDB collections :)
OK, so printers aren't that mysterious. I can operate a CUPS server and whatnot. But I just can't muster enough concern to figure out how to access the network settings on my printer, and I'd be willing to wager I either need to boot into Windows, connect it to LAN, or both, to actually do this.
I would certainly be having a good look at those settings if that thing was connected to my network.
As I was touring this home of the future, there was a hack of the smarthome servers. And then it appeared--goatse. Goatse everywhere. On every wall, every cupboard front, every countertop, scaled to cover the entire surface, was goatse. It was horrible.
So much for the home of the future. Now you know why I distrust smarthome technology.
Given that most houses in most Western capital cities now cost millions and given that you can buy LCD panels for approximately the same price as bricks (for the same wall area) I do wonder why millionaires still stick with bricks. You could build a steel framed building and make all the walls, floors and ceilings from LCD panels saving yourself from having to have lights, pictures and regular TVs. With a few solar panels on the roof the electricity bill should be affordable too.
My imagination for this extended to having live scenes from the seaside to have an immersive view of sunnier climes. Your imagination went to goatse though, maybe your fears and browsing habits informed your dreams differently to mine.
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
I'm in no way a security/network export and I'm sure the people who came up with the current specs were smart people doing their best but it always seems a bit shit to me. I can send death packets to any device even if I'm not attached to the network and they're just honoured? Really? Was all this stuff created in a time when nobody actually considered bad people?
Yes. The Internet was designed in times where the primary worries were a) nuclear attacks causing major disruptions in the infrastructure, and b) pranksters. You can see that in the design of protocols, which assume all actors are participating in good faith. A lot of pieces of the Internet we still use were created for research community, where the default assumption was that everyone is acting benevolent (and if someone wasn't, they could be found and punished quickly through out-of-band means). I don't think anyone back then could ever imagine the amount of clueless, careless and evil people the commercialization of the Internet would bring to the network.
Tangentially, this is also why we're stuck with programming in environments subpar compared to what we had in the 70s. The level of control people had over their OS and software also implied total lack of security.
Sure, IoT devices are created today. But they follow defaults (which are insecure), because IoT vendors are cheap.
Maybe. But if we do, I'd love if there were allowances in the new design for creating isles where everything flies, and security is very low. I have two reasons for that:
One, security is - to some extent - mutually exclusive with capabilities. When everything is sandboxed and end-to-end encrypted, I can't inspect what a piece of software is doing, and I can't write code to make that piece of software do what I want. This flexibility is needed to make one's workflow efficient, and one's problems solvable (at least without waiting for someone else to solve them).
Two, hardening security has the distinct tendency for enabling vendor overreach and lock-in. The same techniques that secure your data from evil third parties can be used to secure "your" programs from you.
Edit: disclaimer: I work for Google, but my only contact with the home ecosystem is having a Chromecast.
I guess basic rules could be setup, but would there be a higher level way for that kind of orchestration
Incidentally it's concerns such as those raised in the article that drove my decision to use zigbee or z-wave devices for my HA setup where possible.
Not if the other devices on your network don't accept unauthenticated commands from anywhere. Which would seem like a pretty basic security feature.
As far as the local network, I think it can be assumed it’s insecure if you’re using any IoT devices. If not, then you might be able to trust it.
https://www.securityforrealpeople.com/2016/04/arris-motorola...
If you have access to the login page (and until recently, it was also available via WAN) you could do all fancy tricks by putting the right commands in the password field, including bricking the equipment itself.
[1] https://github.com/Nimayer/fastgate-toolkit/wiki/Get-a-root-...
People tried to contact the ISP and got no response back, of course.
The principle of least privilege, as a sibling pointed out, is important here because it sets the expectations of what a secure IoT device looks like. If we don't nip it in the bud now, this sort of lax security will become prolific even when more important information is at stake.
Google should be leading the pack on 'the right way' to do security on IoT. They know better.
If they can do that (minus the piracy warnings) without further interaction/firewalls being turned off, that’s an indication of more problems, not an indication that whatever the article is about isn’t a problem. You act like people getting on an average home network is unthinkable, but it happens all the time with visitors, weak passwords, broken wireless protocols….
No, because Windows domain group membership is required (your uninformed amateur setup might be different).
> deleting all your Redis tables and Elastic Search indexes
Don't you think that development tools that are used by (supposed) professionals have different requirements regarding out-of-the-box default behavior than a consumer product?
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.
Of course, the fact that you can't lock down Chromecast on a local network is a feature that could be very useful.
"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."
Amazon made the decision to force all Echo integrations to go through the internet.
I'd say it's moreso a trade off that favors "getting it out the door quickly" over security. It's reasonable that, if you want your app to integrate with a Google Home, you should expect it to be authenticated. Plus, the fact that this API is undocumented seems indicative that 3rd-party integration wasn't the purpose.
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
So yes, you could make them play loud music, or make me miss my alarms.
What other harm can you do? Genuine question.
Isn't that bad enough? I would be fairly pissed if someone do that. If someone hijack my device in the middle of night and start streaming loud music, I would be pretty pissed.
Maybe not so much for alarms, though (As current design, if network goes out, alarm won't sound, so better to have backup anyways.)
I'm mainly questioning Google's decision of why they designed the device to scream out loud "hey I'm here, and I can be hijacked!" while sporadic outage of the internet is not that uncommon in residential setting where it is mainly targeted for.
And remember, those devices (especially Google Home) are capable, and often used to capture more than a directive of streaming media. Asking for your schedule, making a phone call, etc.
But that's not super exploitable even with a hijack. You can know I asked for my schedule if you took control of my device, and feed me a fake one, but the work to make that useful rather than just a dead giveaway that something is wrong is non-trivial, and involves getting a bunch of personal info more worrying than the hack itself.
And you can know I tried to call a particular named contact, but again doing much with that is non-trivial.
Regardless of impact this problem may exhibit, my point still stands that it shouldn't be hijackable, let alone at this ease.
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).
But the hijack proposed detaches the Home from the Google Account with which those integrations would be attached.
The attacker could expose his own lights to the victim, but not the other way around.
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.
In this mode, essentially Google Home becomes an access point without internet access and Google Home app can be used to configure new network.
[0]: https://9to5google.com/2014/07/21/chromecast-vulnerability-t...
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.
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.
This screen only protect you from entering wi-fi details to third party that's potentially malicious.
However, since the implementation does not ask users to input that code into Google Home app, it won't protect someone other than you (as long as they are in wi-fi coverage of the device) to configure or hijack your device. (and Google Chrome/Home drops down to this "waiting for configuration" state every time internet connection becomes unavailable.)
Latter is the issue I have raised.
for i in {1..255}; do curl -Lv -H Content-Type:application/json --data-raw '{ "wpa_id": 0 }' http://192.168.1.$1:8008/setup/forget_wifi; done
Forget hijacking. The issue is that it broadcasts the room name in beacon packets. Imagine things like Project Dragonfly Deployment Conference Room or <unique first name> Bedroom.
There are lots of reasons one doesn’t want these broadcast unencrypted into the street for wardrivers.
"If you don't want people to read your email, just don't email anything you don't want printed in the newspaper."
Perhaps you don't understand the meaning of the word leak.
I of course went through and renamed my rooms to remove anything I don't want associated with my latitude/longitude for permanent record by wardrivers, but that's not the point.
> "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.
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!
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.
Works after I changed to the right ip range.
- 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?
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.
Can anyone explain this? Is he saying others have already reported this and Google don't care?
https://www.youtube.com/watch?v=ajGX7odA87k
titled “Why Do Keynote Speakers Keep Suggesting That Improving Security Is Possible?”.
i think so, and the author should be ashamed.
My faith in these smart IoT devices is completely diminished...