Was it possible to access/retrieve configuration information such as keys and tokens from our configuration through this API vulnerability? Should we change these?
Some questions :
“manage add-ons and backups”. Were the attackers able to download backups?
Were the attackers able to affect my supervisor if they knew my NabuCasa URL?
Is there any way to check if these SuperVisor API calls were made to my instance?
Can you please provide some additional information regarding this vulnerability, as neither the associated GitHub nor the Mitre CVE pages seem to have the details of the potential attack vector, which are necessary to perform forensic analysis on whether one’s instance has been exploited?
I think this would also help to dispel confusion seen in this thread.
Looking at the API reference, seems like they would be able to download a full backup if they had access.
I’ve changed my DuckDNS token, took 1 minute (login to DuckDNS, click on the ||| symbol next to name, recreate token, copy token to DuckDNS config on HA and restart it).
This disclosure is really lacking enough details to allow non-technical users to understand the scope of the vulnerability.
Based on my understanding, the supervisor API not accessible through the standard HA core ingress.
This seems confirmed here: Supervisor External API Access - #2 by CentralCommand
If the above is the case, I’d reword the statement to avoid spreading panic throughout the community as it is a serious one, with the supervisor API giving an attacker opportunities to compromise the entire HA instance and credentials to everything it was integrated with and if so, I (and pretty much everyone here) would like to know so that we can act.
HAS THIS VULNERABILITY BEEN ABUSED? is ridiculous, please provide more details to allow users to determine if they could have been compromised - even if it’s just a hint to review logs of ingress controllers for access to a specific path like
/api/supervisor or something…
I am using Nabu Casa. Still affected by this?
Quick question: Shouldn’t the warning message automatically disappear after the update? I have now made the update 2023.03.1, but the repair/warning message still appears. Even after a reboot of the host.
Home Assistant 2023.3.1
Operating System 9.5
So we should uninstall wireguard and reinstall because if backups are on the lose so would wireguard config/clients files?
Agreed. See my comment above. The referenced CVE number on the Mitre site is showing as reserved and as of writing of this message, doesn’t yet contain the necessary details.
Only if you click “Ignore” in the lower left corner of the pop-up window.
OK thanks. In fact, this should happen automatically.
To be fair, the rapid fix and transparent, public disclosure for this defect is exactly why I use Home Assistant and am far more comfortable exposing it to the internet than I would be about pretty much any other internet-connected device that I have in my infrastructure.
All software has defects, some of those defects will impact security, and a few will be serious. I don’t judge software by whether or not it has defects, but by how those defects are handled when they are found.
Thanks guys, 10/10 here.
@frenck To mitigate such issues in the first place - Support for client certificates would be awesome. Only reason holding back this is the lack of support in the android app. Is something like that being planned? Similar technology is used by the DavX5 App (also open-source), which might be a good example to implement something.
This would mean that only trusted devices, having such a client certificate would have access to the HA instance.
The server instance would not require direct support as the validation and check of the certificate can be achived via a web server like nginx or apache in front of it.
I must admit I’m pretty disappointed, the community has been asking for Open letter for improving Home Assistant's Authentication system (OIDC, SSO) - #40 by pjcarly for a long time. This would allow people to put solutions like oauth proxy in front of HA, completely sealing it out from anonymous access but the maintainers don’t want to deal with it - they’d rather rely on their own auth provider implementation which is, in my opinion, not the way forward opening doors to issues like this.
I appreciate the update, how promptly the information was released once the patch was available.
I received the 2023.03.1 patch last night and the post this morning.
For those who are still wondering (English is not my first language)
Do I run
- Home Assistant OS, or
- Home Assistant Supervised?
Can I reach my Home Assistant from the Internet without a VPN?
If yes, I was effected.
(This can can quite nuanced how connectivity is established.)
Am I at least on Supervisor 2023.03.1(seen on the Settings → About page)?
If yes, the vulnerability is patched.
(I do not believe at time of writing there is a later version than 2023.03.1, but marking it as “at least” for future.)
Correct me if I am wrong.
Am I the only one who finds this a bit scary? Should I?
“Our analysis shows that this issue has been in Home Assistant since the introduction of the Supervisor in 2017.”
I disagree, but that is just my opinion. The “Ignore” is not the best word, should be “Acknowledged”, but updates of this caliber in my opinion should stay up until explicitly acknowledged.
Maybe a config option to auto-acknowledge critical updates?
seeing this in the repairs section
and Id hate to click Ignore (NEGEER) here. My system had already been updated, so shouldn’t there at least be a Fix button, or, preferably even, ‘your system has already been fixed’ ?
Ignore seems the wrong choice of words
Yes and No. There can always be vulnerabilities without anyone knowing untill someone finds out. If you lookup windows vulnerabilities you get a whole lists of issues that lived longer than 9 years. Some vulnerabilities are not so much of checking if someone is logged on or not. Some vulnerabilities go way deaper… I would say lookup Meltdown & Spectre https://meltdownattack.com/.
So yeah always be sceptical and stay up-to-date with the latest version
Why does need supervisor API be exposed externally?