After changing all passwords I’m getting a “login attempt failed” notification every minute.
As I use nginx add-on, HA just shows the nginx container ip address, so I can’t know which device/service is is trying to connect to my HA and failing. I couldn’t find how to access the nginx full logs.
The Alexa integration is working fine, both my android apps are working fine. I don’t know how to debug where this connection is coming from.
Does someone has an idea how to proceed to solve this problem?
I just created a nginx_proxy_default.conf file in the /share directory and inserted the configuration you told me, now I can see the failed connection is comming from AWS.
I would like to thank the HA team and Nabu Casa for the swift response! This is a free open-source project and we all appreciate your time and effort. Maybe, security was not the main focus so far in the development and these incidents may get them to a higher priority.
I was always wondering why we have to store passwords and credentials in plain text in a file somewhere in the network. I think these issues show that HA needs an integrated encrypted password and credential storage where all the passwords can be safely stored and integrations and addons can access them via an API call with rights that need to be granted by the user.
Is something like this coming or planned in the near future? I mean the security breach could be non-HA related but these passwords still hang around in the network.
Hi,
Thanks team for all this security updates.
This vulnerability show that internal Encrypted Vault to share different password of addons custom integration or other is now mandatory. Plan text password in yaml files is now not possible for a wonderfull product like HomeAssitant
I read the answer, but it is not fully convincing. Why is it too hard to ask for a password (optionally if the user has configured it in HA) during startup time to get the vault access? This is similar to OS passwords, UEFI passwords, etc. Once logged it, sure HA is then able to read all passwords in the vault, but it should come with a rights management such that the admin can decide which (custom-)integration has access to which pw.
Moreover, the larger fear is that anywhere in the network could be a security breach and access your secrets.yaml file vs. only HA must be breached with a vault. Just this difference is already huge. Of course, this could always be made optional if there is no need for these security measures.
Because, any reboot/restart due to power failure, software glitch, etc would keep HA from starting, which could be an issue if you aren’t home when this happens
Totally understand that. My point is just that everyone should (be able) to decide on his/her own whether the inconvience of a non-booting HA when not at home is worse than a compromised Google/Amazon/Whatever account or vice versa.
Yes it is always safer to not have something exposed to the internet, in this case these vulnerabilities would probably not be a concern (as I understand them) they don’t seem to be related to malicious Add-ins reading data and intentionally sending it out.
If you do need it exposed, protect it with something in front (like a VPN) or look at the nabu casa stuff which I believe makes an outbound connection for its stuff.
I do not understand the nature of the vulnerability, what information would a “hacker” need to be able to exploit this?
Do the person need to know where my instance is and that I use HACS or is it possible to find that out by doing some check in the HACS outgoing traffic?
I have anyway changed everything and done some much needed security overhaul of my instance.
Thanks for your efforts!
I’m in the process of changing secrets and I’ve come across my Z-Wave network key. I am assuming if I were to change this, any secure Z-Wave devices would cease to function on the network; is that correct? Would I just have to re-include them? Is there a better way to go about it?
No, this is an outbound stealth attack that you invite in by installing 3rd party custom components (Using HACS or manually). This vulnerability has nothing to do with an external attack.
As I understand it it is (or was) possible for a custom_component to allow a URL request over the network to attack your system using a directory traversal.
So the threat does not necessarily depend on an evil custom_component trying to steal your data. A perfectly simple and innocent programming error can allow someone with nous, and access to your HA, to steal your data.
Of course that could be an evil custom component author, or it could simply be a black hat with knowledge that there may be a number of vulnerable systems out there and a penchant for writing bots to search the internet for unpatched HA instances.