Disclosure: security vulnerabilities in custom integrations HACS, Dwains Dashboard, Font Awesome and others

Blog
63

This might be hard to hear for you too but the us and them distinction bothers me. In the (F)OSS world there’s just us — you are part of this community even though there are various levels of skills involved. Even the researcher that did us this huge favour I’d now consider part of this tremendous community. Contrast this with paid-for, commercial software where it’s perhaps more reasonable to make demands.

This is why I think your remarks come across as harsh.

One could ask, now assuming that you take responsibility as being part of this community, why you didn’t make these remarks on the original post on the 14th? That would’ve helped other people already then. If I think like this I should even blame myself because as a software engineer I understand the potential risks of an exposed system and could’ve said something earlier. It’s not so easy now, is it? That kind of reasoning or blaming really isn’t done in a constructive way when viewed like this.

I believe a constructive piece of advice would’ve been something like this: “Assume the worst since your whole system might’ve been exposed or compromised. It is a best practice to change all credentials (i.e. passwords, tokens, etc.).”

3 Likes
64

Thanks for the great effort to get this sorted.
Only remark I can make is that an advice to change all credentials after updating would have been the best way.

Nonetheless I’m grateful for the way things got handled. Keep up the good work!

65

I didn’t miss the point at all. In order to tell you to change your credentials, they also would have also been telling the world that hundreds, if not thousands of Home Assistant instances were vulnerable to credential theft.

If the advice on the 14th was followed then instances were no longer compromised. Credentials could have already been harvested, but that also could have been done months prior. Waiting an additional week in the grand scheme of things was the lesser of two evils.

What they will learn from this is you can’t please everyone, but I’m sure they knew that already. I’m hoping any future security breaches are handled in exactly the same way.

Thankfully I wasn’t impacted by this, and maybe that affects my view, but this looks textbook to me. These situations are often handled so badly, but I just think there’s been great advice and honesty though out.

I hope you weren’t affected either @daphatty.

3 Likes
66

So, the persons able to access our info were the CC developers/creators or anybody with malicious intentions? (sorry if its been answered, i read all the topic and didnt find the answer).

1 Like
67

Ok. I’ve changed everything of value that was visible in the config folder, namely secret.yaml and .storage\core.config_entries (where HA saves UI added integration passwords in plain text!?!)

Do I need to change things saved in ssl and addons folder? Were they vulnerable?

What level of directory were accessible in this directory traversal attack?

68

For the less techie users, like myself could we get a guide of what to do here? I am still unclear, some examples
I have the HA app installed on ios - do I need to take action - how / what?
Integrations like Hue, Owntracks - I need to change password? Then how to update password in HA?
I have an add on that backs up config to Google Drive - is this impacted?
No complaints here, respect to all - but would value a bit more info as above.

69

I think this has been handled amazingly, great job to all involved in the response and mitigation!
I do see both side, re: @daphatty’s suggestion to have advised us in the first post to update credentials, but I also see that doing so would have attracted a lot of attention from black hats who would then hammer a lot of effort into trying to find and exploit the vulnerability.
And of course, with that rush of attention, it increases the odds that someone who is, let’s say, a tad unscrupulous, may not just find and attempt to exploit it, but even worse, may find another unknown vulnerability, and then exploit the hell out of it thinking there is already a closing window of time that it is useful before everyone is updated.

So giving us a gap in time between “there is a security vulnerability, here is an update that fixes it” and “this is the severity of the vulnerability now that there has been time to get the update out” was the best course of action, to play it safe.

Most of the time when it comes to disclosures from software/services providers, we don’t get the initial “please update for a vulnerability patch”, it’s just “security and reliability improvements” in the changelog at most, and it’s months or longer until we are told “oh by the way, check for suspicious behaviour and change your passwords”, so the level of proactive steps here has been amazing.

I like the idea of a opt-in for vulnerability updates, as a way to get the word out to users more directly. If I may make a suggestion, @frenck, if this includes the option to have any repeated update applied, could that be rolled out with the ability to have a complete snapshot taken prior to the update and uploaded to either external storage if available, or a predefined SMB share? I know it may sound a little paranoid, but if say the power cuts while the update is running and a file system gets corrupted, having that process there will be worth it even just to save one installation :blush:

Again, fantastic job by all involved. I’ve kind of always wondered how Nabu Casa would respond to finding a vulnerability like this, and honestly didn’t have high hopes just due to the distributed nature of the project, but this little run in has given me an enormous boost in faith for y’all. Starting to consider a subscription, even though I have no plans to enable remote access :3

70

Well now that I look at it the new one actually seem to support all my products, so hurray! From the look of it I think it’s the nest security stuff that isn’t supported. The pain in the ass part then is migrating to google and setting up the developer stuff. It’s just aggravating that I have to completely redo something that already works cause I can’t change the client Id or secret anymore

71

Ok. Noob here. So what do I have to do now? Change my login data (name, passwort), change my secerts.yaml, reconnect with all the integrations too? ( hue, synology etc).

Also do I have to delete HACS and every custom card for lovelace that I installed through it?

Sorry, Im confused now.

72

From my interpretation (would love if @Frenk or someone could post a more exhaustive list of things to check/change), this is what I’m changing:

  1. EDIT: Full system snapshot.
  2. Change Home Assistant passwords for each user
  3. Revoke and recreate any Long Lived Access Tokens for each user (tokens were in .storage)
  4. Reset 2FA (TOTP) for each user (keys were in .storage)
  5. Revoke and reissue SSL cert for my domain (/ssl accessible within docker container)
  6. Change all credentials stored in configuration.yaml secrets.yaml and esphome/secrets.yaml and update credentials on any device connecting to MQTT broker.
  7. Reconnect any integrations that use a password or token invalidated by #5 (e.g. for me requires updating all ESPHome devices to use new passwords then reconfiguring in Home Assistant to use new API password, but it wouldn’t need to update Harmony Hub since that just uses an IP address).

Anything missing?

Just make sure you have updated to the latest versions of Home Assistant, HACS, and any integrations you have installed through HACS (or by copying to the config/custom_components/ folder).

5 Likes
73

Fortunately I actively block any traffic from outside my network to my HA system, but the response to this issue is exemplary! Not just by HA, but the authors that patched their code are also fantastic!

I didn’t need another reason to like HA, but got one anyway.

1 Like
74

ok, so if the HA instance was not accessible from Internet but only via local LAN, there was no risk to have been exposed?
in such case, I understand that updating is still a required good practice.
I only want to be sure that the affected integration were not malicious, so they are are not performing outbound connections to Internet exfiltrating sensitive data.
Is that correct?

75

You would still be at risk locally. Whether that’s a big risk is a thing only you can decide. My own setup means that I’m comfortable that my own risk is low, despite being somewhat remotely accessible. I however also have a proxy server that has logs, so I can check to see if anybody tried anything for as far back as my logs go (months, many many months).

Of course, I’ve still updated, because it’s the right thing to do.

The problem isn’t that the integrations were malicious, it’s that they had a vulnerability that malicious people could use to steal data. Well, this time anyway :stuck_out_tongue: The risk with any custom component, third party add-on, etc, is that they could do malicious things.

1 Like
76

Ok thanks. For now I consider the risks on my locally quite low as well. So not haven HA remote accessible at all, and assuming the custom integration not intentionally malicious, for this round I decide to upgrade as this is goon in any case, but avoiding to start parsing log in the search of malicious events…

77

Not disclosing vulnerabilities to the public until they have been patched is standard practice within the software industry. This limits the number of breaches as once the information is public all the script kiddies start trying it out and the resulting damage is far worse.

3 Likes
78

Does this recent security update solve the security concern presented in this discussion

Any idea?

79

Three year old thread resurrection :tada:

That thread dates from when having security was optional. It hasn’t been relevant for a long long long time now. You’ve not been able to disable security for a couple of years now.

80

Hi, did you fix CVE-2021-3152?
If so. in what commit?

Thanks in advance!

81

Very briefly looked at the commit and source code. Looks like someone could make a get request with escape characters plopped into it. Likely allowing them to run a command on the host.

Commit:

Source:
homeassistant.util.sanitize_path

82

I installed a custom component that Is not shown inside the UI integrations. How to know if this is one of the affected?