Disconnect all network cables, shutdown you wireless networks, turn off your router, turn off all power relays, remove batteries from all your devices, put your phone on fire and after a few days you probably will be safe… Or maybe not… You still having doors and windows at home right?
To rule out any malicious modifications to HA while this vulnerability was active, are there any tools already built to validate homeassistant os files, directories etc?
E.g. hypothetically if someone did get in and leave something for later? Modify/add code to tunnel out etc.
(Other than reinstalling from scratch / fresh image and manually reconfiguring integrations / copying over yaml, Migrating zwave devices etc (30 devices won’t be fun…))
A script could go though the entire SD card and compare each folder / file / size / to what it should be / a clean install. Anyone done anything like this yet?
For HAOS that should be do-able, but any method that uses Docker should be (mostly) a case of checking the container hashes match what’s on the central registry. A simple reboot ensures that any live changes to a container are thrown away.
If all of those agree then the only other thing to do is to verify the OS - for HAOS the OS is replaced when you upgrade anyway so an OS upgrade is an easy step to take.
For anybody running Supervised it’ll be a little harder, but you can use tools like dpkg to verify the installed files against the package manifest, or use this approach.
The other option of course is to take a backup and restore it on a fresh install.
Any suggestions how I might get around this?
ha supervisor update
Processing… Done.Error: Update of Supervisor failed: Can’t install ghcr.io/home-assistant/amd64-hassio-supervisor:2023.03.1: 500 Server Error for http+docker://localhost/v1.41/images/create?tag=2023.03.1&fromImage=ghcr.io%2Fhome-assistant%2Famd64-hassio-supervisor&platform=linux%2Famd64: Internal Server Error (“Get “https://ghcr.io/v2/”: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)”)
My installation is currently at:
Home Assistant 2023.1.7
Supervisor 2023.01.1
Operating System 9.4
Frontend 20230110.0 - latest
From what I can tell, it isn’t a DNS problem.
Update: I was unable to apply any updates to Home Assistant in February too. So I just now restored the host to an earlier image, which reverted Home Assistant to:
Home Assistant 2022.12.9
Supervisor 2022.12.1
Operating System 9.4
Frontend 20221213.1
But attempting to update brought the same error as above, which is strange, since I’d been able to update to 2023.1.7 in January!?!
The logs for the reverted version also contained the following:
homeassistant.components.hassio.handler.HassioAPIError: ‘HomeAssistantCore.update’ blocked from execution, no host internet connection
Weird, as anything external I manually attempt to reach from the HA cli works…via IPv4.
ping ghcr.io
PING ghcr.io (140.82.113.33): 56 data bytes
64 bytes from 140.82.113.33: seq=0 ttl=47 time=38.816 ms
64 bytes from 140.82.113.33: seq=1 ttl=47 time=40.445 ms
I have IPv6 disabled in HA and I’m pretty sure it’s blocked on my network. Could that be the problem, might the updater have been restricted to IPv6 since February?
I got to core-2023.3.4 supervisor-2023.03.1 Home Assistant OS 9.5 without IPv6 being enabled on my network nor HA. So I don’t think IPv4-only is your problem.
I am running into the exact same issue and error message, here you can see more details about what is going on:
I got to core-2023.3.4 supervisor-2023.03.1 Home Assistant OS 9.5 without IPv6 being enabled on my network nor HA. So I don’t think IPv4-only is your problem.
Good to rule that out. Thanks much.
I had forgotten that in late January our internet provided changed the gateway technology we use. That changed our gateway addressing, which includes the DNS address, and I had neglected to update the static DNS address assigned to the Network Interface within Home Assistant. With that now corrected, I have Home Assistant fully up to date.
If your system’s network interface is set to static values, you might review them to see if you suffer the same issue.
Good to be open and transparent to this, and a quick response to it with fix too… Thanx!
#weallwillbehackedsometime
This issue looks to be still active or once hacked, there is malware in your supervisor/install.
It has been in play since 2022/10/27 16:39 and with my supervisor at 2023.04.0, the attacks are still happening.
I am just about to backup and blow away the VM and start from scratch with min config.
Any recommendation on what to avoid restoring? Where virus/malware will be hidden in /config??
There’s unlikely to be any malware there, but if there is it should be pretty obvious. The only things in your config folder should be YAML, JSON, the database, and the log file. Anything else is suspect (or installed by a custom component).
The alerts from your security software should be investigated to see if they’re actually anything of note, or just what happens when you’re accessible from the Internet (lots of failed exploit attempts against other software).
While technically a nabucasa connected device would expose the vulnerability, in order to connect to your instance the hacker would have to guess your unique URL. So unless nabucasa uses a very dumb algorithm for generating your unique URL (that is they are not randomly generated), the probability of someone guessing a nabucasa URL is very very very low. @frenck if you have information that indicates this isn’t correct please advise.
Read above, the list of NabuCasa domains, or anything else with an SSL certificate, is public knowledge.
So if I read this correctly there would be no issue of nabu casa exposing the individual URLs if they had uses a wildcard cert, i.e. *.ui.nabu.casa?
Turns out the random nabu casa URL was a security scam. Nabu casa should have made a clear statement that the random url provided no security. They report all URLs out to the internet so you’re basically putting you instance directly on the internet. I can’t believe I trusted nabu casa. Errrr!
What are you talking about “security scam”… Nabucasa makes no mention of a random url in the security information. Are you sure you didn’t get that info from a blog that made that assumption?
They make no mention of the fact that your URL is reported out to the internet so you’re really directly exposing your system. They use a random URL that gives the impression of security. Using nabu casa is no different than putting the https port directly on the internet from your local network. Nabu casa never make this clear. That’s a scam.
Uh, it is not the same thing at all… 
How is an incorrect assumption on your part a scam?
