Looks like users are disclosed as well simply if the client is on any private address range and HA is on any other private address range.
Even when passing the X-Forwarded-For header to HA behind a proxy (which Caddy does by default) the users are listed.
If I navigate to the HA webpage without any cookies from a class C private subnet on my LAN to the other class C private subnet where HA is, the users are listed. I don’t have any trusted networks set.
There’s a Github issue already to manually disable this new feature.
Well the Github issue was closed since it’s “not an issue”, not really true in this case imo.
This is a serious security flaw that should not even be considered to be auto opt-in, let alone to not have a way to disable it.
I for sure was not waiting for this “feature”
Can’t believe that such a clear security problem is being dismissed. Imagine an attacker navigating to your HA instance and getting a nice listing of all the users.
This is not a feature request. This is a MAJOR security issue. That this flagrant flaw in security is “only” in the internal network is not up for debate. Internal network security issues are well-known to be the most exploited and underestimated issues. UNBELIEVABLE we have to put up with this mandatory security reduction. And even more blatant is the fact that this is packaged as a “beautiful new login page”.
The login page should be even more anonymized that the fact that it is a home-assistant page is not even visible.
By the way, here’s the branch that introduced the new login screen. It was merged on 11/24. Unfortunately there’s no discussion on the security implications.
What else can I said that hasn’t been said? To summarize the other threads:
The issue:
Internal user ids, display name and profile pics are leaked without having to login.
Removing the requirement to enter the username weakens the login security. Insecure Design in the OWASP Top 10. Heightened in this case since the software deals with IoT.
This is a textbook information disclosure vulnerability.
Nabu Casa’s response:
Insist that it’s working as designed.
Suppress issue discussion on GitHub.
Keep silence on the request to make the feature optional.
Mitigations:
Place Home Assistant in a dedicated subnet and arrange some technical means (ie, reverse proxy or NAT) to make it think all requests come from a public IP.
If the above is not possible, ensure that only trusted parties (in IoT about nothing is trusted) can reach the web GUI endpoint (port 8123 by default).
You can understand that whoever updates to this latest release-202312 automatically have all their users exposed in their LAN and you can assume that most (if not all) people use a proxy, they automatically get all their users exposed to the outside world.
So in your view almost everyone is using a reverse proxy, and the majority of those have it configured in a way that does not pass the origin ip through to Home Assistant correctly, likely ignoring the inclusion of the X-Forwarded-For header and possibly other headers. They connect from outside their network, and they appear to HA to be connecting from a device inside their network.
Ignoring the local login page, how could that best be addressed?
Most of users haven’t ever heard about reverse proxy and the X-Forwarded-For header and possibly other headers. They surf WWW and repeat as shown. As for me, I’m not a super-puper IT-specialist, so I found several ways to expose my HA to WWW. The most suitable for me is SSH-tunnel between HA and VPS (I suppose it works as reverse proxy). The Nginx on VPS forwards requests on VPS to necessary port on HA. And when I log in from outside my home network my HA detects it as local login. So default security settings for most users must be the Highest Security!
