Unfortunately these things happen. I would however like to take this opportunity to once again start the discussion about supporting reverse proxy authentication through nginx.
There have been many discussions on GitHub about this and the current status is that the development team does not feel they have to support nginx because a safe method of remote authentication is provided through nabu casa.
I disagree. A second layer of authentication could have prevented our instances from being exposed.
Home assistant is the only one of many applications I host that does not reside behind my nginx authentication wall. I have never felt comfortable about this and this feeling has only become worse now.
Please reconsider implementing support for nginx.
Edit: for clarification, nginx is supported but everything breaks when you add http Auth or x509 certificates.
Continue navigating my HA system as normal on that device and all other devices/browsers
Shouldn’t I have to authenticate before 3 and again before 4? Is there a way to set things up so that either of those would be required? Without it, anyone who gained access to my system still has it even though I have a new password.
EDIT: I found the login session/refresh tokens under the profile for my user, and they can be deleted one-by-one. I presume this will fix the login before 4 if I delete all tokens.
Ah, those system accounts. Honestly, I figured since they were system generated accounts the system would take care of them. It is a good question, now you’ve got me curious now also. Thanks for clarifying.
As we all learned how (time) critical updates are and my notification automations rely on this sensor amongst others, I was wondering
what triggers the binary_sensor.updater sensor to become aware of a newer version
what the “security update” notification/information introduced recently would look like and if it should´ve been triggered for 2021.1.4 users when 2021.1.5 became available
on a long-term if there´re plans to provide update notifications by default (ship with HA Core)
I spent many hours to create such on my own… because “security is number 1 priority”
For screenshots and update notifications for other components I can recommend having a look at @CentralCommand´s great work in this topic:
Paulus, very well handled a difficult situation. As others have commented, this type of thing happens but it is the response to the issue that is even more important. Thank you to you, the core team and the wider “senior” community members who I am sure are putting in hours way over and above you expected.
This has happened many services before and will again unfortunately. Your response to the issues has been an example to how others (and in many many cases much, much bigger organisations) should act in these situations
I got this security bulletin and updated to latest version a couple of days ago.
Working fine until now it kicked my out my app. After digging further, turns out the Nuba Casa account just pushed the update to me and killed the token as it didn’t recognise my update.
Signed out and back it, agreed the terms on NubaCasa and working again?
Thanks for the transparency on this. I’m wondering if we should build an internal encrypted secrets section/vault that we could reference in our configurations…
Signed up for Nabu Casa today (has been on my todo list for awhile) got an email alert with the security vulnerability same day and the instance was disconnected from the cloud due to the vulnerability. Pretty awesome - thanks HA devs, continuing to be all over it with this amazing platform!
From a general perspective: yes, opening up HA to the internet e. g. by port forwardings and DynDNS greats a massively larger attack surface. That doesn´t mean the risk is guaranteed to be higher, but only remotely accessing HA by VPN hides it from the internet pretty much. Anyway,
updates
wise choice of installed components
enabled 2FA
rarely usage of long term access tokens
enabling Fail2Ban (http component)
…
are important anyway, doesn´t matter if HA is exposed to the internet or not.
But the core question is related to the attack channel and I´d also like to know if it affects every HA instance or only the ones sitting on the internet.
I’ve already removed/changed everything in my config/secrets files, but this episode has made me realize that I have no idea how to effectively secure other integrations that connect to HA via api using the UI after a breach. For example, for my ecobee integration, do I need to delete it and start completely from scratch to obtain a new api key from ecobee? Is there a simpler way to do that from within HA? If so, would that be sufficient or do I need to also change my password on ecobee.com?
I know the standard better-safe-than-sorry advice is “reset everything,” but I would appreciate some advice on how to deal with these kinds of integrations.
Just cleaned out my google developer api credentials and started over. Something I haven’t seen mentioned anywhere else: I had a few ssh command line sensors pulling temperatures off of my two main proxmox hosts (one of which runs my pfsense vm)…and those keys were in /config/.ssh! ugghhhhh
No more ssh sensors for me. I’m pulling my google calendar integration too. It’s just too risky.
