Ein Blick in den Code: Wie aus einem Facebook-Fund ein Sicherheitsupdate wurde

Samstagmorgen, Kaffee, Facebook. In der Gruppe Home Assistant DE stellt jemand eine neue Integration vor: eine Haushaltshilfe mit Einkaufsliste, Finanzen und Putzplan, alles direkt in Home Assistant. Sieht gut aus, also schaue ich mir an, wie das gebaut ist.

Eine halbe Stunde später hatte ich eine ziemlich unangenehme Erkenntnis. Wer die Home-Assistant-Instanz erreichen konnte, kam ohne jede Anmeldung an alle Passwörter der App und an ein vollwertiges Zugangstoken für Home Assistant. Gut 24 Stunden später war das Problem behoben, und zwar so, wie man sich das wünscht. Davon handelt dieser Beitrag. Und davon, warum ich mir Integrationen jetzt vor der Installation anschaue.

Was ist die Haushaltshilfe?

Haushaltshilfe Pro von Domenic ist eine Custom Integration für Home Assistant, installierbar über HACS. Sie bringt ein eigenes Panel in die Seitenleiste mit Einkaufsliste, Aufgaben mit Intervallen, Wochen-Essensplan, Fixkosten und Müllkalender. Dazu kommt eine eigene Benutzerverwaltung, damit auf dem Tablet in der Küche jedes Familienmitglied seinen Namen antippen kann.

Die Idee finde ich richtig gut. Genau so etwas fehlt vielen, die Home Assistant nicht nur für Lampen und Thermostate nutzen wollen. Das Projekt ist jung, quelloffen und wird von einer Person in der Freizeit gebaut. Das muss man im Hinterkopf behalten, wenn man den Rest liest.

Was ich gefunden habe

Eine Integration darf in Home Assistant eigene API-Endpunkte registrieren. Dazu schreibt man eine Klasse, die von HomeAssistantView erbt. Eine Zeile entscheidet dabei, ob Home Assistant vor dem Aufruf eine Anmeldung verlangt:

class MeinView(HomeAssistantView):
    url = "/api/meine_integration/daten"
    requires_auth = True   # Standard. False = jeder darf ohne Login zugreifen

In Version 1.0.6 der Haushaltshilfe stand bei fast allen Endpunkten requires_auth = False. Für sich genommen ist das noch kein Weltuntergang. Kritisch wurde es durch das, was diese Endpunkte zurückgegeben haben:

Die Kette dahinter ist kurz:

1. Benutzerliste abrufen, Passwörter stehen gleich mit drin.
2. Mit einem dieser Logins app_login aufrufen und das Token zurückbekommen.
3. Mit dem Token die normale Home-Assistant-API benutzen, mit den Rechten des Benutzers, der das Token erstellt hat. In der Regel ist das der Admin.

Damit hat man alles, was an Home Assistant hängt: Türschlösser, Alarmanlage, Kameras, Heizung. Im Heimnetz ist das schon unschön. Wer Home Assistant über Nabu Casa, einen Reverse Proxy oder eine Portfreigabe von außen erreichbar hat, stand damit faktisch offen im Internet.

Das Token kam übrigens so ins Backend: Das Panel hat das Sitzungstoken aus der laufenden Home-Assistant-Oberfläche gelesen und auf dem Server abgelegt, damit Handys und Tablets ohne eigenes Token auskommen. Bequem, aber genau da lag das Problem.

Wie es weiterging

Ich habe Domenic privat angeschrieben und nichts öffentlich gemacht, bevor ein Fix draußen war. Das ist bei Sicherheitslücken der übliche Weg, auch bei Hobbyprojekten. Er hat sofort geantwortet, sich bedankt und das Problem ohne Ausreden bestätigt. Weil er am Wochenende wenig Zeit hatte, durfte ich mich selbst am Fix versuchen.

Von der ersten Nachricht bis zum Release vergingen also rund 24 Stunden. Domenic hat den Fix getestet, noch eigene Verbesserungen eingebaut und in den Release Notes klar gesagt, was passiert ist und was Nutzer tun müssen. So sollte das laufen.

Was der Fix ändert

Der Grundgedanke: Das Panel läuft sowieso in der Home-Assistant-Oberfläche, der Benutzer ist dort also schon angemeldet. Diese Anmeldung muss man nur benutzen, statt sie zu umgehen.

• Alle Endpunkte verlangen eine Anmeldung. requires_auth = True überall.
• Kein Token mehr im Backend. Das Panel holt sich das Token aus der laufenden HA-Sitzung und erneuert es bei Bedarf. Ein altes, gespeichertes Token wird beim Start gelöscht.
• Kiosk-Tablets bekommen ein eigenes Token. Wer die Seite direkt im Browser aufruft, hinterlegt in den Einstellungen ein Long-Lived Access Token. Das bleibt nur auf diesem einen Gerät.
• Passwörter werden gehasht. Master-, Admin- und Benutzerpasswörter liegen nur noch als PBKDF2-Hash vor. Beim Update werden vorhandene Klartext-Passwörter automatisch umgewandelt, geprüft wird nur noch am Server.
• Der Proxy darf nur noch, was er muss. Schreiben geht nur auf die eigenen Hilfs-Entitäten der Integration, und es lassen sich nur noch die eigenen Events auslösen.

Dazu kamen Tests mit pytest-homeassistant-custom-component, die gegen ein echtes Home Assistant prüfen, dass jeder Endpunkt ohne Anmeldung mit 401 antwortet und nirgends ein Passwort oder Token herauskommt. Mit dem gleichen Test-Setup ließ sich vorher auch nachweisen, dass 1.0.6 tatsächlich Passwörter und Token ohne Login herausgegeben hat.

Du nutzt die Haushaltshilfe? Das solltest du jetzt tun

• ☐ Über HACS auf Version 1.0.7 oder neuer aktualisieren und Home Assistant neu starten.
• ☐ In Home Assistant unter Profil → Sicherheit → Langlebige Zugangstoken alle Tokens widerrufen, die du für die Haushaltshilfe angelegt hast. Im Zweifel lieber eins zu viel.
• ☐ Wenn deine Instanz von außen erreichbar war: unter Einstellungen → System → Protokolle und in der Logbuch-Ansicht kurz schauen, ob dir etwas Ungewöhnliches auffällt.
• ☐ Für Wand-Tablets ein neues Token anlegen, am besten mit einem eigenen HA-Benutzer ohne Admin-Rechte, und in der Haushaltshilfe unter ⚙️ eintragen.
• ☐ Die Passwörter der App-Benutzer ändern, falls du sie auch woanders verwendest.

Checkliste: Integrationen vor der Installation prüfen

Eine Custom Integration ist Python-Code, der mit allen Rechten in deinem Home Assistant läuft. HACS prüft beim Hinzufügen eines eigenen Repositorys nichts davon. Man muss kein Entwickler sein, um die gröbsten Probleme zu finden. Repo klonen und zehn Minuten investieren reicht oft schon.

git clone https://github.com/<autor>/<repo>.git && cd <repo>

# Welche Endpunkte sind ohne Anmeldung erreichbar?
grep -rn "requires_auth = False" custom_components/

# Wird irgendwo ein Token gespeichert oder herausgegeben?
grep -rniE "access_token|long.?lived|token" custom_components/

# Passwörter im Klartext?
grep -rniE "password|passwort|_pw" custom_components/

Worauf ich dabei achte:

1. requires_auth = False ist nicht automatisch falsch, zum Beispiel bei Webhooks. Dann aber genau anschauen, was der Endpunkt zurückgibt oder verändert.
2. Tokens gehören nicht auf den Server. Speichert eine Integration ein Home-Assistant-Token, um es an andere Geräte zu verteilen, ist das ein Warnsignal.
3. Passwörter werden nicht zurückgegeben. Weder im Klartext noch als Hash. Ein Server prüft Passwörter, er verteilt sie nicht.
4. Generische Proxys wie „setze beliebige Entität“ oder „feuere beliebiges Event“ sind gefährlich. Gut ist eine feste Liste, was erlaubt ist.
5. /local/ ist öffentlich. Alles im Ordner config/www liefert Home Assistant ohne Anmeldung aus. Dort hat nichts zu suchen, was geheim ist.
6. Zum Testen eine Spielinstanz. Eine zweite Home-Assistant-VM oder ein Container ohne echte Geräte kostet wenig und erspart Überraschungen.

Das ersetzt kein Audit. Aber es fängt genau die Art Fehler, die bei Hobbyprojekten aus Bequemlichkeit passieren, und darum geht es hier.

Fazit

Fehler passieren, gerade wenn man etwas in der Freizeit baut und es endlich zeigen will. Entscheidend ist, was danach kommt. Domenic hat zugehört, nicht diskutiert, den Fix getestet und offen kommuniziert. Dafür von mir ein ehrliches Danke, und ich hoffe, die Haushaltshilfe findet noch viele Nutzer.

Und für alle anderen: Schaut euch an, was ihr installiert. Nicht aus Misstrauen gegenüber den Entwicklern, sondern weil euer Smart Home die Haustür aufschließen kann.

Wenn ihr selbst etwas findet: erst privat melden, Zeit zum Fixen geben, Hilfe anbieten. Öffentlich wird es erst, wenn das Update draußen ist.

Passend dazu auf der Frickelfabrik:

• Home Assistant auf dem Raspberry Pi 5: das Tutorial mit Docker, Zigbee2MQTT und Backups
• Zigbee-Netz stabil bekommen: Kanalwahl, Router-Geräte und gesprächige Sensoren