Nice, i would love to see that mobile-phone or travel-laptop
Ultimately it depends on whether it is possible to use the Supervisor API to modify the Supervisor itself (I don’t know if that’s possible with the access this bug grants). Or if there is a way for an addon container to execute any code on the host OS with root priviledges, over a kernel call for example. Docker is containerization, not full virtualization. So if any of this is possible, it’s game over. The malware can then simply patch the official Docker images before installing them. But even that isn’t necessary to gain persistent access. They have access to your local network, they can install a backdoor into any other connected device, the access credentials are conveniently available.
Basically, as far as I see it, if someone gains access to your local network, consider yourself compromised.
1 Like
Maybe I missed it in the 238 replies. Has anyone from HA given a clear response as to what we should be doing other than updating to Supervisor 2023.03.1 or later?
1 Like
Yes.
It seems we have a wealth of knowledge on this forum relating to cyber security and the intricacies of how HA works beneath the hood, which is a great asset. For me personally, and I’m sure many others who don’t work in cyber security or have any depth of knowledge in this field, I would love to see a guide on HA Security best practices.
If you are running HA in any shape or form, it goes without saying that you are reasonably tech savvy, but if you are only able to run HA by following how-to guides for integrations and asking on the forum if you get stuck, then you may be running things in a much less secure way, with a flat network, no IoT vlan etc without the ability at a firewall/router level to lock things down as you would like, or know how to.
Maybe a guide with different sections/levels of security steps aimed at basic/intermediate/advanced users depending how far you want or are able to go? Not just relating to this patched vulnerability, but the HA environment overall.
1 Like
Some valid points.
HA’s own docs is somewhat thin on this front (which anybody can contribute to, of course).
Luckily, this is open source with a large community, so anybody can take initiative. You don’t even need to be an expert — just have the willingness and the savvy to know how to pull people together.
The forum has a section for community guides. Here is such a person as an admitted non-expert that took initiative.
Back to the HA docs, I kind of get why it’s thin, because there are so many options, starting just with the various installation methods and ways to serve your HA on the internet. It will be tricky to convey general best practices and separate it from specific implementation details (e.g. how to do x on router y).
Plus, it’s quite a technical domain. There are many concepts that even if it’s not that hard to understand, it can be quite tricky to implement. Some of it is also just general network security, independent of the software run. The skill levels around here vary tremendously. How to cater for all of that is hard. (I don’t consider myself an expert in security, but have good enough working knowledge when it comes to designing software.)
My last note is that it is not crucial to have your HA on the internet. Of course, it’s convenient and useful for some features and I do that myself, mostly for location tracking, but it’s typically not critical. Make a distinction between an HA that relies on the internet for information (e.g. getting the weather) from having it exposed. The former of course also has some security risks associated with it.
1 Like
couldn’t agree more., thank you.
this might be the best starting point, as the ultimate and succinct distinction?
talking current security vulnerability, are we touched in the ‘exposed’ area only, or also in the ‘information’.
Or, are we now touched in both, as the ‘exposed’ vulnerability might now also have compromised the ‘information’ aspect.
Exposed means change credentials on Nabu Casa (and local add-ons)
Information means change credentials for all other services too…
or is this way too simple
mind you, I purposely made it simple, because complex means people will stop taking precautions… or simply shrug
That’s in general something I’m missing in the “outside connection” options of HA. I’d LOVE to have an easy “read only” way of exposing our HA instance to the outside, but wouldn’t need/want to add new integrations, access the underlying db, etcetc.
At the moment I’m using the telegram bot for a very limited feature set compared to the HA app, but there I at least don’t have to open anything in our router, and even if someone hacks my bot (or telegram as a whole “turns evil”), the maximum damage would be someone seeing the apartment stats and switch on the heating too soon :-D, without the chance to dig into the underlying system or database, or to add new automations or integrations, or to grab a backup while being at it.
1 Like
Email Snapshots , have a dedicated email-account for this purpose on your Phone/Pad, it’s as “read-only” as can be, you can even “highlight” snapshots/emails that are received do to “extremas” changes in your environment
Well that depends a lot on how people use HA. For me, outside access is absolutely crucial. I use HA as a glorified remote control and remote monitoring tool, more than an automation platform (I have very few automations compared to most people). Without external access HA would be next to useless for me.
I do agree that there’s no easy one size fits all for hardening an external HA access though.
Do you use iOS? I can’t see any setting in the iOS app to support mTLS.
Currently using WireGuard to access hass etc.
Interesting points by both of you. I think these quotes above are related, so I’ll comment on it together.
To be compromised this way (i.e. not an exposed instance, but you’re pulling data from the internet), one must remember that there is still software processing any request, and that software can be tricked into doing things it wasn’t intended to do. The simplest (known) examples I can think of is e.g. PDF files of an unknown origin, but even image and video files, by exploiting bugs in the code that decodes (reconstructs by processing) the data. Similarly with e.g. trojans that enter by someone opening files in a malicious email.
As for sending Telegram notifications, I’d doubt it, unless one is able to receive messages (with malicious content).
But, to keep it simple: Either an attacker tries to punch a hole through the wall from the outside (cracking a password, making a request to an API with some data and make it crash in a particular way, etc.), or you get something/someone on the inside in a legit way, and then unlock the door from the inside (or punch a hole, to keep with the idiom). I didn’t want people to think just because their HA instance isn’t remotely accessible (e.g. by the companion app) that they’re safe. If your HA accesses internet services, you’re still technically open in some way. So, basically I’m thinking there are 3 categories: Remote access, accessing cloud services and fully local (on an isolated network at home, not at all connected to the internet). Everyone, just note I’m not referring here to this specific vulnerability. This is general commentary.
But it does make me think of something else now, which is how software can e.g. be tricked to download uploads not from a trusted source, but from a malicious source (easily doable if you have access to some local DNS services, like editing someone’s hosts file). There’s been some Windows vulnerabilities like that. As for HA, there’s really no signing or any form of verification. We all basically trust PyPi (the Python package repository) and GitHub (which is probably fair), but it’s good to understand that even then it is technically possible to put a package on PyPi that is malicious, if one can get access to the account for a package which publishes the package. There’s been some hacks like this in recent years via pip (the tool to manage packages on Python).
Sure, I didn’t mean to dismiss such cases. For me, it’s also critical to have remote access, even though dashboards and remote control for me are secondary things. I was just thinking that there are probably people out there running HA not even realising this, given what they’re doing (turning some lights on and such), or that if remote access is simply a nice to have and you’re worried about security, you could consider not exposing it.
2 Likes
Oh yeah, absolutely.
Hi
Where do you find documentation about that?
How could I go about the minimal exposure to run Google voice assistant and nothing else?
Thx
You don’t, it’s not supported/encouraged by the devs.
You could however have a look at this post and add /api/google_assistant to the allowed URLs. You need it to be fully open to set it up, and then you can lock it down.
I worked this out by simply checking the proxy logs to see what was being blocked and then selectively opening things up.
(I’ll see about writing this up on my blog, you’re not the first person to ask).
Well, then I can just keep using the telegram bot setup that I have now.
The HA app already today supports defining 2 different URLs, one for at-home-use, one for remote use. Having an access rights management system would be awesome, that would allow restricting usage to certain scenarios (read only, switch existing controls, trigger existing automations, …), with these restrictions only being able to be changed via local control, and then to keep using the normal app when not at home, but with e.g. a dedicated reduced dashboard for that.
I’m unfortunately not enough of a developer to actually implement something like it, my experience ends at the concept stage :-/
This is what I thought, if the attacker was in the network, they probably have gotten what they wanted already - changing passwords may or may not help - depending on the kind of backdoor they have left behind…
Which is why the thought of mitigating the issue by shutting my entire network down and giving up on IT came from… at least if bugs like this keep getting discovered
Another head scratcher I read about lately was the complete Secure Boot bypass vulnerability… you just can’t be secure nowadays.
Ohh they will, maybe not “bug like this” but bugs and vulnerabilities
Actually i still doesn’t know, haven’t seen a “detailed” description where/how this “bug” worked, curious as i am, i would have loved that Devs described in more details, “where, what and how” , i mean they could easy “close the gate” when it was “discovered” , so it should be pretty easy to explain in “plain common english” , instead of avoiding with “platitudes”