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.
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.
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.
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.
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.
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”
To be fair, it’s not like I have an issue with Home Assistant or their way of handling the issues. Those vulnerabilities have been and will always happen. I think they handled it well, though the language used could have been more refined. A technical and non technical section since this project targets a vast audience of users.
It is a common practice to disclose vulnerabilities after they have been patched and the patched software rolled out for a certain period of time. There’s the window during which ‘everyone’ gets up to date and then the issue goes out for awareness.
Usually, companies pay those people and also form some sort of an NDA contract.
As it was discovered by an ethical hacker, it’s likely it was not exploited at all unless the details somehow made it into the dark net or was discovered and misused before the report.
Should it have been discovered any other way, that’s when it would be trouble for the majority of people who are port forwarding HASS on their router. It’s so easy to discover those instances. Those who keep their instances behind reverse proxies and wildcard certificates are in a bit more luck…
The scanner scripts would need to know the full domain name of the HASS instance to get through the reverse proxy (if not using a default backend)…
It’s an additional layer of security through obscurity. Does not prevent hackers from finding you, but it requires more effort. How to find the full domain name? Hmm, certificate transparency lists, links on the internet, guess work like ha.domain.com or hass.domain.com…
Since I found out about this issue I reconfigured my reverse proxy to actually terminate SSL and log every request instead of passing through the TLS tunnel directly to HASS. I also will no longer issue a certificate with a direct host name of the instance and instead wrap it under the wildcard…
Lol, there’s a middle ground somewhere between opening all your ports out of lazyness, completely oblivious to the danger and going full offgrid in a cabin in the woods
As Tom said above, things like these are an unfortunate fact of life these days. You have to do a risk assessment for your own personal situation and work from there. Being a random collateral target of a drive-by infection versus being specifically targeted by a foreign nation-state actor, those two extremes will obviously require very different types of protection and risk management. Only you can know where you stand between those two scenarios.
You said you already reassessed your current setup and hardened your security. That’s the best approach you can take in a situation like this, if you ask me.
