This is a great callout, @gubiq . Thank you.
This is effectively proof that there is a public directory of all Nabu Casa Cloud-proxied HA instances. (I confirmed this by locating one of my own HA instances in the list. An instance I am 100% confident the URL hasn’t been crawled or leaked elsewhere.)
There are many APT groups (Nation-states and NGOs alike) who have been known to exploit zero days, establish backdoors, and then do nothing with them until they decide they “need” them. It’s the “hack everything” approach.
I’d wager that many HA users are in tech fields, and these APT groups may consider us as valuable targets, to serve for potential pivots into more sensitive (e.g. Corporate) networks.
(Of recent note: The recent lastpass breach was via a superadmin’s home Plex server. His personal devices were targeted by the attackers to facilitate an eventual pivot into LastPass.)
I say this next bit as someone who’s also been in cybersecurity for a decade+, with the majority of that time in a Detection & Response specialty. Diving through logs and performing post-compromise forensics is my day-to-day bread-and-butter. I’m also very familiar with responding to “vulncidents”, where no active exploitation has been observed, but the ease of RCE and the potential impact/risk associated is significant enough to warrant treating it like there may be abuse of the vuln in the wild:
Given the public directory @gubiq pointed out and this context that compromising personal servers is an emerging TTP, I think that it is critical we get some more technical details on the vulnerability, soon, from a “where to start doing forensics” perspective.
If it was exploitable via the Nabu Casa “tunnel”, we need to know how it may have been exploited, and how that may have appeared in supervisor logs.
It doesn’t matter if Nabu Casa Cloud tunnels are E2E encrypted if the adversary can be one of the endpoints and exploit the vuln. AIUI, this isn’t a MitM situation, so E2EE does nothing. (As mentioned above, client certificates could have been a layer of defense here, since they would effectively prevent the adversary from “being” one of the endpoints allowed to talk to HA.)
This is the kind of thing where if anyone using HA can find evidence of exploitation on their instance, then we need to start changing how everyone is responding to this. (Not trying to stir up fear or panic here. Just trying to indicate that if we find evidence of even ONE case where this has been exploited in-the-wild, then this shouldn’t just be considered a vulnerability anymore; there’s potentially an attack campaign that’s gone undetected, and that campaign could have potentially just gone through the public directory of HA instances and compromised them all.)
We can’t even start digging into this and gaining confidence that there’s not exploitation ITW until we know where to start looking.
I very much appreciate the Nabu Casa team’s approach on patching this vuln and disclosing it like this. That’s a mark of a team that takes their product seriously and respects their users.
Given the no-auth RCE and open directory of vulnerable targets though, I think the very respectable thing to do is to provide the guidance users need to determine if their instances may have been exploited.
I’m very interested to see how this vuln impacts Nabu Casa strategy and security going forward.
Just a good product, those things happen, everytime, everywhere. We just should mitigate the impact.