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.
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.
it doesn't just take an iot device. every of app on your phone or pc or appletv or tablet could be hacking stuff on your local network and many of those apps have vulnerabilities which can be exploited to gain access. See Call of Duty network bug as just one example. A PS4 game recently had a similar issue
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.
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.
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.
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.
This reminds me of a product idea I had a while back - a sandboxed wifi router that plugs in to your existing router. When you setup your IoT devices, you point them to the sandbox. I figure this already exists, and nobody cares.
Guest WiFi usually uses a captive portal, I think. I don't think that would work with something like Google Home, which expects to have internet access right away AFAIK
A much better LAN firewall will be needed, can also mean you can easily get rid of 1 to many NAT with IPv6. It would have to be self learning for any hope of adoption by the mass market
This is all because of the current madness to have all devices connected each other. Completely connected "smart" things and network isolation/security: choose one.
If the devices I care about are secure (laptop, phone etc) then I shouldn't have to care about other devices, whether they're on my home network or not.
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?
> 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.
Yes, the network itself primarily and the way devices connect over it. Perhaps we'd need to start over?
When I'm at work people get shouty if you just bring a laptop in and plug it into the network. "If they find out you'll get in trouble". Why wouldn't they find out? And why aren't devices whitelisted so you simply connect without prior approval?
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.
May I ask what your setup is like? I have an Ubiquiti ER-POE and a Unifi AP. Is it straightforward to assign different SSIDs on the AP to different networks, or do you also need one of the unifi security gateways?
It's not what the concern is here, it's that this is becoming the norm for all IoT devices, and it is inevitable that in time said devices with comparable security will have access to more privileged, sensitive information.
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.
> 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.
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….
I have occasionally had people in my complex accidentally print on my HP printer. It seems there's some wireless printing feature that is enabled by default and can be authenticated without needing physical access. The state of security for home networking devices could certainly be better.
You forgot one though, they might also be able to delete your MongoDB collections :)
It is definitely not a WiFi printer. It is (was) connected to my machine via USB and it definitely didn't have my WiFi credentials. I would investigate further, but I've not had the printer plugged in for a while now.
They have a feature where it spins up it's own access point so that phones and the such can connect and print directly, so your wifi credentials wouldn't be required.
Yeah, that's exactly what I'm guessing is happening. That said, I don't really know how to disable it. I may be a software engineer, but printers are another realm for me, a dark one with a weird Turing complete programming language at the core and numerous protocols ranging from moderately confusing to batshit insane to interface with these pieces of crap.
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 bet it's crap enough to have the Administration settings available on that wifi network it creates, either totally open or probably some default password.
I would certainly be having a good look at those settings if that thing was connected to my network.
AppleTV has a similar "feature." Drove me nuts trying to find what was leaking in/out of my firewall - turns out that crap wasn't even going through it.
Speaking of rebooting vulnerabilities, I'm reminded of the CSRF vulnerability in the popular Motorola SB6141 modem. Not only can, say, a embedded resource in a forum reboot your modem, it can also request reprovisioning, which can take you offline for up to half an hour. It's been fixed, at least by my local TWC, but I wonder if all ISPs have rolled out the firmware update.
For the record, a popular ISP in my country designed its own router, which uses shell commands to compute the password hash, without even attempting to sanitize input[1].
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.
I'm inclined to agree with you. Home security is not on the same level as enterprise security. What do people expect? That you're going to have IAM so that only you can reboot your router remotely and not your kids or your dinner guests? I mean, it's not like Google couldn't do it, it's just horrendously expensive for little benefit. And then we'll get people griping that Google forces you and your kids to all get Google accounts just to use your home network.
Security if these devices is very important. If even vendors like Google leave things this open, the risk is very real that these devices will be hacked and harnessed by criminals to make DDoS attacks, to use as proxies for criminal activity, to mine cryptocurrency using your electricity, to listen to and record activity in your home, to serve as jumping points to access your private data stored on open shared storage, or to steal your credentials to your bank. If we don’t push back against runaway lazy IoT security all of this will become commonplace very soon, and your lack of care about security in trivially pointless devices like Google Home will be horrendously expensive to you for very little benefit.
I actually get this perspective, as the endpoints listed here aren’t super sensitive (notifications do seem worth protecting). However, I’d still prefer to see security by default. With the current scenario, we have to track whether new, more sensitive features are introduced and whether or not they’ll introduce more security.
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.
In 2002 or so I had a dream. I was touring the new, modern, internet-connected home. Decor could be changed with the touch of a button because most of the home's surfaces (walls, cupboard fronts, etc.) were OLED displays that could display any texture or color of the user's choosing.
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.
I have had a similar dream before, but with a couple of key differences:
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.
My Redis and ES boxes have ufw on them and are on their own VLAN and need passwords etc. The Sonos are on another VLAN (SEWER - 802.1q tag 13) I don't have access to any RA music t home. I was traumatised enough by the eighties thank you 8)
This is not an argument for adding a Google Hub to the mix. It's an argument for not having devices on your network that will accept unauthenticated commands from any other device. Would you have your laptop or desktop computer on your home network allow unauthenticated telnet instead of SSH?
Ah the old saw, just don't let the bad guys on your network, or execute code on your computer, or visit their websites, or be in contact with them in any way.
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?
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.
At the end of the day this is a cast device which will advertise it's presence to the whole network white active and allow anyone to send media to it (and mirror screen to Chromecasts, which have the same API exposed as the author says).
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."
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.
> It's a trade off that favors features over security.
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.
my understanding from a very good source is that the team that created Home is indeed not googley, not security focused, and in general not the best of the best. an enormous amount of money was spent to develop it and (being in an ultra competitive field) is a big money loser. the original reason for it was to be an iot hub, which still has not really been realized.
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
You're hijacking them, but only if you get them on your own WiFi. And then they can't do anything to devices on my Wifi any more. They don't use my bandwidth, they can't control my devices, they're not connected to my account...
So yes, you could make them play loud music, or make me miss my alarms.
> So yes, you could make them play loud music, or make me miss my alarms.
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.
> 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.
Well, you can ask more specific questions, not just "what's my schedule" -- it is true but mileages may vary how much of information you can get out of hijacking. Since all the words followed by "Ok Google" will be captured and saved to attackers' Google account.
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).
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.
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.
I think you're confusing Chromecast and Google Home. The article you linked is about Chromecast. They don't behave the same way. If you lose access to the original network, a Google Home device needs a factory reset via a button.
That's not how it works, at least for ones I have. The moment they lose connection, it will start broadcasting SSID with device name with ".b" added. It will accept configuration from Google Home app. That behavior is common between a set of Chromecasts and Google Homes as far as I can see.
You can stream many types of content on a Chromecast (porn from a Chrome tab for instance, or your Android screen), and you don't need a Google account.
The hijack described takes them off the local network, but IIRC Home will only control devices on the same network, unless you—after you hijack it—you have access to connect it to some other service that controls the device, which requires already having the control you want to use the hijacked device for.
I discovered this a couple weeks ago and reported it to Google. Filed WONTFIX. A blog post is coming.
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.
Also, it's not apparent it does it until it loses internet access. There is no warning or disclosure indication. It doesn't do it in normal operation; only when it loses internet connectivity, so there's nothing to indicate to even a savvy user that it will rat you out.
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.
Yeah, I'm not sure what flow lets you bypass that that GP is refering to. My impression was there aren't any, you always need to be able to see the screen to get the PIN code, and presumably there's rate limiting on trying codes.
I'm referring to that four letter code. Google Home app does not even request user to input that.
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.)
Chromecast displays a pin on the display it's attached to and requires that pin to pair to a new account. I'm unsure what (if anything) Google home does (I remember "your home device played a sound", I don't remember if there was anything else.
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.
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.
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.
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)
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!
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.
~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`~
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.
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?
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.
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.
> 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?
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?
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.
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.
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.
