Last year our electricity bill was higher than expected. So I’ve decided to I need some insights into our consumption and bought a LEDVANCE Matter SMART+ plug. It can connect to my Home Assistant installation using matter, the promising new standard for IoT.

Since my Home Assistant setup runs self-managed on an Orange Pi 5B, I opted to install python-matter-server in a container alongside the Home Assistant installation. During the setup I have encountered a potential security issue that I have reported and I will now share publicly.

Advisory

Here is the advisory that I have filed on 2024-10-20. The GitHub URL is not usable by the public since it was rejected/“closed”.

Summary

python-matter-server exposes read & write access to matter devices without authentication.

While I am not 100% sure if this classifies as a security issue (esp. since the matter integration is marked as “beta”), just opening a public GitHub issue felt wrong. Better be safe than sorry. Feel free to move this to an ordinary issue. Thank you.

Details

The README suggests starting the python-matter-server container w/ --network=host, probably to avoid some IPv6 issues. However, this also means that – if not prevented by a firewall – the UI and WebSocket port (5580) is now exposed on the host and hence to all networks that this host sits on (if the host is exposed to the internet, that now means it’s also on the internet). That port requires zero authentication. Home assistant – which is the biggest user of python-matter-server – requires authentication to shield dashboards (= read) and controls (= write) from unprivileged humans and machines (incl. malware). It seems that python-matter-server kinda pushes a hole into that setup for all Matter devices registered with that controller.

Ideally the UI and websocket port would require some form of authentication (e.g. a password). Note that support for that has to be added to home assistant.

As an alternative, we should at least advice users (e.g. in the README) that they should set some port blocking (e.g. via iptables or nftables) to prevent access external (as in: not from the same machine).

PoC

Local

1. devices: pick 3 devices
   • PoC host (e.g. a raspberry pi)
   • a matter device
   • a local network attacker (e.g. a developer laptop)
2. set up:
   • install home assistant on host
   • set up python-matter-server as described by its README
   • add matter integration to home assistant
   • pair matter device
3. attack:
   • access host port 5580 from attacker, list matter device and attributes from UI (= read w/o auth)
   • use description from python-matter-server README to perform changes to matter device via python (= write w/o auth)

Global

A quick Censys search that filters for port 5580 (python-matter-server) and port 8123 (Home Assistant, to increase the likelihood that the other port is the matter sever) found a few hosts where python-matter-server is indeed exposed to the public. This confirms the hypothesis that this is a real problem.

Impact

Unauthenticated access.

Response

The response was received on 2024-11-25:

Thank you for bringing a security concern to our attention. However, it does not qualify as a security report on our end, as this requires a network that’s already seriously compromised.

Generally, users should not expose ports to the internet, unless there’s a specific need and the required precautions to secure the port has already been taken by the user.

The only officially supported way of running the Matter Server with Home Assistant, is by using the Home Assistant Matter Server add-on. By default, for the Home Assistant Matter Server add-on, the websocket server is bound to an internal interface only and external connections are prohibited.

There are no plans at the moment to add authentication to the Matter Server. Users that are running the Matter Server not via the Home Assistant Matter Server add-on, need to ensure that access to the used port is restricted/secured, eg by binding to localhost/host internal interface only.

We will clarify the readme of the Matter Server regarding the securing of the used ports.

We appreciate your efforts in helping us maintain the security of our project.

Sincerely,

<retracted>¹

My Take

The response narrows the thread model of Home Assistant installations quite significantly by excluding network access. That is – in my opinion – a bit shortsighted. First, a “seriously compromised network” is not just a singular rating but comes in levels:

1. Network Connection: Being able to open new connections to network devices and use them to talk to services. This basically applies to most WiFi networks and also home setups once you either have the WiFi password of physical access to an Ethernet port. This is already sufficient to perform the described attack.
2. MITM: Being able to intercept and potentially modify network traffic. This may be possible by rouge devices in a home network using ARP spoofing or NDP spoofing, but is sometimes harder due to smart routers. Also note that this is generally not possible when the traffic goes through loopback network interface.

Second we should consider how the network may get “compromised”:

• Access Control Bypass: The network is secure but that security was bypassed, e.g. somewhat guessed your WiFI password. This is probably rather unlikely.
• Accidental Exposure: An internal device or port was exposed to the internet by accident. As shown in the advisory, this may happen more often than anticipated, especially when the insecure service (e.g. the matter server) is hosted on the same device that also exposes a valid public service (e.g. Home Assistant).
• Hacked Device: In vain of bad security practices – especially for many IoT devices – we have to consider the possibility that a network-local device may be compromised.

Counter-Measures

The current instructions for Docker still do not mention the risk. I have secured my matter installation by adding the following nftables rules:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
        chain input {
                type filter hook input priority filter;
                iif != "lo" tcp dport 5580 drop;
        }
        chain forward {
                type filter hook forward priority filter;
        }
        chain output {
                type filter hook output priority filter;
        }
}

The Matter Experience

The matter interface of the LEDVANCE plug is horribly broken. Despite being from a German brand, it is just a cheap white-label product from some Chinese manufacturer. I have sent it back (for free) and replaced it via a Tasmota Sockets by Eightree. They are connected to Home Assistant using MQTT and work great. They are also cheaper than the LEDVANCE plugs.

I still want matter to succeed though because it promises to be better than the status quo on so many levels. The end user experience is smoother (no custom MQTT setup required, no remembering under which address the HTTP interface can be found, no guessing if Home Assistant will work with it nor not) and we can finally have true interoperability through standardized interfaces and data semantics. I guess it is just a bit early.

Image: by Jakub Zerdzicki on Pexels