Is there any way to see a diff between the last affected version and the fixed version?
I assume that they didn't want to call attention to the fix before users had time to update. (Don't want to create a race between attackers and defenders)
But now that the this vulnerability is being announced, how do I find out what code or API endpoint was vulnerable?
EDIT: I mean, just the diff between the offending lines of code and the corrected ones. I assume this vulnerability isn't obvious. It hung around for 6 years. And the commit message probably didn't point it out explicitly, because they didn't want to disclose prior to building the release.
If I just diff everything that changed, I'll probably not be able to point and say, "Oh yeah, that line is bad"
They might not want to draw too much attention to it even now. Otherwise people might know what kind of hints to look for in the future when security issues are being silently fixed. Possibly.
No need to be secretive about it. Updates have been automatically pushed + if someone wanted to see how it was fixed in order to exploit it, they'll be able to browse through the commits just like I did, and probably find it even easier as I'm no pentester, just a casual programmer.
Haven’t read all the code, but If it’s defense in depth, then it seems fine. If it’s the sole protection towards SQL injections, then it seems quite sketchy.
> The issue allowed an attacker to remotely bypass authentication and interact directly with the Supervisor API. This gives an attacker access to install Home Assistant updates and manage add-ons and backups. Our analysis shows that this issue has been in Home Assistant since the introduction of the Supervisor in 2017.
Wouldn’t it have to be an exposed supervisor port to the internet? It’s not enough to just be running supervisor and having home assistant exposed, right?
I don't believe so – from a quick glance it seems that supervisor requests are proxied through the normal HA port, and the supervisor doesn't have it's own port except for the Observer (which seems to be a simple read-only thing).
HA provided a fix and broadcast the security issue reasonably effectively. Here we are discussing on HN. Good.
The vulnerability boils down to having a port open to HA (direct or proxy) exposed to the internet, or if your LAN is already compromised.
Many HA users will make the upgrade. Some HA users will not upgrade. Perhaps those are locked into a specific version, maybe because of the various integrations that cause issues when upgrading, etc.
It's interesting now the trade-off between "local" and "cloud". Home automation generally has this tension right now. Users want access to their "local" HA instance from a coffee shop, say, but don't want to deal with privacy issues and security breaches of "cloud".
> Users want access to their "local" HA instance from a coffee shop, say, but don't want to deal with privacy issues and security breaches of "cloud".
My personal solution for HTTP stuff that should be private but I want to access from anywhere is to add another independent authentication layer.
I've so far settled on SSO using oauth2-proxy[1] out of convenience, but probably even basic http auth is enough.
That means that even if the running service authentication is broken, or like in this case, bypassed, it will still be caught by the first layer of authentication. See my HA instance[2] for an example.
For home assistant the tradeoff is that the native app doesn't work, but I'm sure there's a smart way to whitelist requests just for my device, I just haven't gotten around to it since the web page has been sufficient so far.
An alternative solution is to connect through Wireguard. On Android(not sure about iOS) you can force certain applications to use the VPN connection. WG uses UDP to establish connection so the exposure is minimal.
I haven't tried Wireguard so far, but from past experiences VPNs usually make mobile devices use more battery, I assume because they keep the radio on more than required (keepalive? just having to process VPN broadcast traffic?) and can't sleep so much.
Plus, personally I'm trying to reduce the amount of "trusted just because it's on the LAN" stuff and go more for a "zero-trust" approach as much as possible.
WG can live without keepalives(though it can use them), there is no real "session" concept. A peer will just connect back when the traffic starts flowing.
I keep an eye out on my battery usage and never noticed it being in the list.
On the zero-trust front - it's not really meant to completely replace authentication but it does help with minimizing attack surface. It does help with encrypting traffic, especially for stuff that does not talk https.
Yeah, having worked with an OpenVPN setup in the past - wireguard is definitely a breath of fresh air. It can be a little bit tough to setup depending on the rest of the network stack(openrc/network manager/systemd/systemd-network, etc), but it's very flexible.
Wg-quick (typically comes as part of wireguard-tools on distros) is extremely handy for the initial testing.
A big problem with VPNs on mobile devices is that you can only have one running at a time. A completely arbitrary limitation as far as I know, but I haven't found any way around it on Android.
Worse yet, some network filtering solutions also use the VPN feature.
One (maybe a bit involved) way around it is to route the packets on "server" if rolling your own VPN and setup the filtering there. It does defeat the purpose of the local apps though.
I would love to use my auth proxy with Home Assistant without having it break the Home Assistant app. Unfortunately it can't be done (without also whitelisting the whole API path in the process).
(Yes I know about WG but VPN just isn't an option for me)
I suppose this validates my strategy of exposing as little attack surface as possible. One SSH port with password auth disabled, one HTTPS port that greets you with an authentication request.
> In case one is not able to upgrade the Home Assistant Supervisor or the Home Assistant Core application at this time, it is advised to not expose your Home Assistant instance to the internet.
I would advise anyone to not expose things meant for your local network to the internet unprotected, ever.
27 comments
[ 3.1 ms ] story [ 67.6 ms ] threadI assume that they didn't want to call attention to the fix before users had time to update. (Don't want to create a race between attackers and defenders)
But now that the this vulnerability is being announced, how do I find out what code or API endpoint was vulnerable?
EDIT: I mean, just the diff between the offending lines of code and the corrected ones. I assume this vulnerability isn't obvious. It hung around for 6 years. And the commit message probably didn't point it out explicitly, because they didn't want to disclose prior to building the release.
If I just diff everything that changed, I'll probably not be able to point and say, "Oh yeah, that line is bad"
There is bindiff, or you can use the Diaphora plugin for IDA Pro, or you can use Ghidra diff correlators.
- https://github.com/home-assistant/supervisor/commit/2ae2d0e1... ("Performance tweaks middleware" but doesn't seem to be about performance but about auth)
- https://github.com/home-assistant/supervisor/commit/3d74e07c... ("Backport core api filter" but doing request filtering based on "potential harmful query string")
No need to be secretive about it. Updates have been automatically pushed + if someone wanted to see how it was fixed in order to exploit it, they'll be able to browse through the commits just like I did, and probably find it even easier as I'm no pentester, just a casual programmer.
Oh dear. This is awful for the same reason that https://thedailywtf.com/articles/Injection_Rejection is.
Holy shit.
This is one of the reasons I’ve never used port forwarding for external access to anything run locally.
The vulnerability is still bad, but at least only accessible to my home network.
> We don’t know. We have not heard any reports of people being hacked.
Zero-effort-lame. At least provide hints for what to look for, e.g. Home Assistant-specific logs (journalctl, HTTP access logs etc.)
The vulnerability boils down to having a port open to HA (direct or proxy) exposed to the internet, or if your LAN is already compromised.
Many HA users will make the upgrade. Some HA users will not upgrade. Perhaps those are locked into a specific version, maybe because of the various integrations that cause issues when upgrading, etc.
It's interesting now the trade-off between "local" and "cloud". Home automation generally has this tension right now. Users want access to their "local" HA instance from a coffee shop, say, but don't want to deal with privacy issues and security breaches of "cloud".
My personal solution for HTTP stuff that should be private but I want to access from anywhere is to add another independent authentication layer.
I've so far settled on SSO using oauth2-proxy[1] out of convenience, but probably even basic http auth is enough.
That means that even if the running service authentication is broken, or like in this case, bypassed, it will still be caught by the first layer of authentication. See my HA instance[2] for an example.
For home assistant the tradeoff is that the native app doesn't work, but I'm sure there's a smart way to whitelist requests just for my device, I just haven't gotten around to it since the web page has been sufficient so far.
[1] https://github.com/oauth2-proxy/oauth2-proxy
[2] https://ha.emilburzo.com/
Plus, personally I'm trying to reduce the amount of "trusted just because it's on the LAN" stuff and go more for a "zero-trust" approach as much as possible.
I keep an eye out on my battery usage and never noticed it being in the list.
On the zero-trust front - it's not really meant to completely replace authentication but it does help with minimizing attack surface. It does help with encrypting traffic, especially for stuff that does not talk https.
Wg-quick (typically comes as part of wireguard-tools on distros) is extremely handy for the initial testing.
Worse yet, some network filtering solutions also use the VPN feature.
One (maybe a bit involved) way around it is to route the packets on "server" if rolling your own VPN and setup the filtering there. It does defeat the purpose of the local apps though.
(Yes I know about WG but VPN just isn't an option for me)
> In case one is not able to upgrade the Home Assistant Supervisor or the Home Assistant Core application at this time, it is advised to not expose your Home Assistant instance to the internet.
I would advise anyone to not expose things meant for your local network to the internet unprotected, ever.
I tunnel from my Android device using an SSH client app. The only port open to HA is localhost on the client.