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

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.

4 Likes

If I did not use any of the integrations than am I safe from this attack? I still plan on changing all my passwords today just to be safe

I can do the following in an infinite loop without ever having to authenticate:

  1. Pick up a device or browser that has previously logged into my HA instance
  2. Navigate Configuration -> Users -> {me} -> Change Password
  3. Change password
  4. 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.

  • Benjamin
1 Like

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.

What I don’t understand is why it was fully disclosed to the public before it was checked to be fixed, ideally by the security researcher.

I discovered the update incidentally when surfing the Supervisor.

While it is shown there, the binary_sensor.updater still reports

release_notes: 'https://www.home-assistant.io/latest-release-notes/'
newest_version: 2021.1.4

As we all learned how (time) critical updates are and my notification automations rely on this sensor amongst others, I was wondering

  1. what triggers the binary_sensor.updater sensor to become aware of a newer version
  2. 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
  3. 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” :slight_smile:
grafik

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?

Kudos again devs!

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…

2 Likes

I’d like to know the same.

Thank you for the immediate disclosure and patch. You’re handling this exactly the right way.

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!

1 Like

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.

you may need to update again, this is a new vulnerability

Well done - a very clear, transparent and inclusive security response - thank you.

First, thank you for the prompt response,

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.

Maybe I’m missing a trick? (it is late here…)
When I pull the latest version for docker, I seem to be getting 2021.1.4 not 2021.1.5…

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.

Anyone that has updated to 2021.1.5 has these problems?