5 ms·

Disclosure: Supervisor security vulnerability

62 points by lathiat 4y ago

function_seven 4y ago
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"
- helloooooooo 4y ago
  By taking a patched binary and unpatched binary and running them through a diffing tool. There is bindiff, or you can use the Diaphora plugin for IDA Pro, or you can use Ghidra diff correlators.
  - tonny747 4y ago
    This is open source, so you can just do a diff between version tags in git or github under releases page.
- codetrotter 4y ago
  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.
- capableweb 4y ago
  I'm guessing these two commits (one or both) are related to the CVEs: - https://github.com/home-assistant/supervisor/commit/2ae2d0e1070067b2b47bdfecfb44eca697b964fd 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/3d74e07c5e977468611e26a64ad7926a5240e21b 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.
  - function_seven 4y ago
    Thank you! This is exactly what I was looking for. That second link seems pretty obvious.
  - josephcsible 4y ago
    https://github.com/home-assistant/supervisor/commit/3d74e07c5e977468611e26a64ad7926a5240e21b#diff-b87a8d41af603d8f42fbd98aba995716a072ae19d0201db5d91388f53463f7a6R116-R135 https://github.com/home-assistant/supervisor/commit/3d74e07c... Oh dear. This is awful for the same reason that https://thedailywtf.com/articles/Injection_Rejection https://thedailywtf.com/articles/Injection_Rejection is.
    - ratorx 4y ago
      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.
ThePowerOfFuet 4y ago
> 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. Holy shit.
- haswell 4y ago
  This would primarily be a concern if someone decided to expose the machine running HA to the Internet. 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.
  - JJJollyjim 4y ago
    Shodan lists 125,000 HA installs exposed to the internet (though I don't know how accurate that statistic is, nor what fraction have a Supervisor) https://www.shodan.io/search?query=product%3A"Home+Assistant" https://www.shodan.io/search?query=product%3A"Home+Assistant...
    - upon_drumhead 4y ago
      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?
      - JJJollyjim 4y ago
        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).
Eduard 4y ago
> Has this vulnerability been abused? > 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.)
idatum 4y ago
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".
- emilburzo 4y ago
  > 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 https://github.com/oauth2-proxy/oauth2-proxy [2] https://ha.emilburzo.com/ https://ha.emilburzo.com/
  - VTimofeenko 4y ago
    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.
    - emilburzo 4y ago
      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.
solarkraft 4y ago
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.
- aaomidi 4y ago
  Honestly this is why I use tailscale with everything. I don’t trust these implementations anymore. Tailscale all the things!
- idatum 4y ago
  An SSH tunnel is my strategy as well. The only internet port I have open is an OpenBSD sshd with a low privilege chroot'd user, SSH key auth only. I tunnel from my Android device using an SSH client app. The only port open to HA is localhost on the client.

62 points by lathiat 4y ago

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"

helloooooooo 4y ago
By taking a patched binary and unpatched binary and running them through a diffing tool. There is bindiff, or you can use the Diaphora plugin for IDA Pro, or you can use Ghidra diff correlators.
- tonny747 4y ago
  This is open source, so you can just do a diff between version tags in git or github under releases page.
codetrotter 4y ago
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.
capableweb 4y ago
I'm guessing these two commits (one or both) are related to the CVEs: - https://github.com/home-assistant/supervisor/commit/2ae2d0e1070067b2b47bdfecfb44eca697b964fd 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/3d74e07c5e977468611e26a64ad7926a5240e21b 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.
- function_seven 4y ago
  Thank you! This is exactly what I was looking for. That second link seems pretty obvious.
- josephcsible 4y ago
  https://github.com/home-assistant/supervisor/commit/3d74e07c5e977468611e26a64ad7926a5240e21b#diff-b87a8d41af603d8f42fbd98aba995716a072ae19d0201db5d91388f53463f7a6R116-R135 https://github.com/home-assistant/supervisor/commit/3d74e07c... Oh dear. This is awful for the same reason that https://thedailywtf.com/articles/Injection_Rejection https://thedailywtf.com/articles/Injection_Rejection is.
  - ratorx 4y ago
    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.

ThePowerOfFuet 4y ago

> 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. Holy shit.

haswell 4y ago
This would primarily be a concern if someone decided to expose the machine running HA to the Internet. 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.
- JJJollyjim 4y ago
  Shodan lists 125,000 HA installs exposed to the internet (though I don't know how accurate that statistic is, nor what fraction have a Supervisor) https://www.shodan.io/search?query=product%3A"Home+Assistant" https://www.shodan.io/search?query=product%3A"Home+Assistant...
  - upon_drumhead 4y ago
    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?
    - JJJollyjim 4y ago
      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).

Eduard 4y ago

> Has this vulnerability been abused? > 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.)

idatum 4y ago

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".

emilburzo 4y ago
> 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 https://github.com/oauth2-proxy/oauth2-proxy [2] https://ha.emilburzo.com/ https://ha.emilburzo.com/
- VTimofeenko 4y ago
  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.
  - emilburzo 4y ago
    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.

solarkraft 4y ago

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.

aaomidi 4y ago
Honestly this is why I use tailscale with everything. I don’t trust these implementations anymore. Tailscale all the things!
idatum 4y ago
An SSH tunnel is my strategy as well. The only internet port I have open is an OpenBSD sshd with a low privilege chroot'd user, SSH key auth only. I tunnel from my Android device using an SSH client app. The only port open to HA is localhost on the client.