Security Disclosure 2: vulnerabilities in custom integrations HACS, Font Awesome and others

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.

Me - I keep mine internal only

1 Like

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!

im not sure you understand what a custom component it. they effectively become part of ha.

1 Like

Yes and unfortunately there are tools available to easily scan for this.

Still Ok to take this update with Python 3.7 ?

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.

Nope. You missed the mark completely.

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.

This event has pushed me to learn more about the proxy in front of my HA server. As of now, I’m proxying through HAProxy running on a pfsense VM. I’m not doing any authenticating, but am using a firewall rule to limit access only through cloudflare. I tried to play around with requiring client certs to connect to the proxy, but couldn’t get it working with iOS. Anyone have experience with this (reverse proxies and client certificates)?

I’m thinking a client certificate requirement in front of home assistant would have prevented unauthorized access in this instance?

Im running 2021.1.5 and Nabu keeps saying I’m running 2021.1.4
I have restarted HA,rebooted HA,Restarted Supervisor,etc. Ideas?

+1 for reverse proxy authentication through nginx.

somewhere in these disclosure threads the Secrets file is mentioned. Still, as we all know, this secrets file is not secret at all, nor in any way secure.

Shouldn’t we therefor rewrite this https://www.home-assistant.io/docs/configuration/securing/#checklist? the only valid point made under the checklist is that we should regularly update our configurations.
Of course the paragraph on Remote acces is really important, if not the main point of this page.

The alternative to the secrets file mentioned in the link https://www.home-assistant.io/docs/configuration/secrets/#alternatives-to-secretsyaml will be deprecated in 2 months, leaving us with credstash but I cant recall anyone ever mentioned using this at all? Though it seems to be the only advocated technique coming close to really be secure?

Anyways, main landing page Securing could use some major rewrite.

I am not sure whether you understood my post correctly. Encrypting passwords reduces the attack surface in the network no matter where the breach is. Of course, custom components might still be able to obtain this information, but any other attacker in the whole network is not.

It is like putting your bank account pw outside your house or inside. A burglar can still read it once he has broken into, but not anyone else going just into your yard.

It also says that credstash will be removed in March. Are there any other alternatives?

I never said it wasn’t safer. I just don’t think it’s the answer, in relation to this vulnerability. Someone has suggested a good way of doing this in another thread.

I dug into adding client certificate certification when traffic hits the proxy, but it seems like all the apps I self host (home assistant, nextcloud, and bitwarden) do not support the feature right now. I got it working when accessing through a browser, but the apps do not seem to allow for presenting a client certificate.

  • The Android & iOS Apps are updated to notify the user if their Home Assistant instance is potentially insecure.

This scared my family, even though we are NOT vulnerable. Please don’t do this. Many people using the app are NOT administrators and have NO power to act, and the local administrator (me!) has already done the threat assessment.

You should still update regardless if your impacted or not. Their power to act is telling you to update which you should do.

The thing is that the warning appears once the first time you open the app (iOS, not sure about Android) even if you have already updated to 2021.1.5.