Case Study: Smarte Bewässerung, die jeder steuern konnte
Wir haben ein smartes Bewässerungssystem getestet: Durch ein fehlerhaftes MQTT-Setup konnten wir Geräte anderer Kunden sehen, schalten und ihren Standort ermitteln.
Zyberum Security Team · Veröffentlicht am · 4 Min. Lesezeit
Smarte Bewässerung klingt harmlos: Ventile, ein Controller, eine App. Wir haben ein solches System getestet. Am Ende hatten wir die Kontrolle über Geräte, die nicht uns gehörten, und eine Karte ihrer Standorte.
Was wir getestet haben
- den Controller und seine Firmware
- die Mobile-App
- den Cloud-Dienst
- die MQTT-Verbindung, über die Befehle und Statusmeldungen laufen
Was wir gefunden haben
MQTT war kaputt
Das System verband Geräte, App und Cloud über MQTT. Das Setup trennte die Kunden nicht voneinander. Aus unserem eigenen Konto konnten wir die Geräte anderer Kunden sehen, samt ihrer Statusmeldungen.
Wir konnten sie schalten
Beim Sehen blieb es nicht. Wir konnten auch Befehle senden: Ventile öffnen, die Bewässerung starten, Einstellungen ändern, und das auf Anlagen, die anderen gehörten.
Wir konnten sie finden
Die Nachrichten und API-Antworten enthielten genug Informationen, um die Geräte zu orten. Ein Angreifer wüsste, welches Gerät wo steht.
Warum das wichtig ist
Zusammengenommen: eine Liste von Geräten, ihre Standorte, ihre Aktivität und die Möglichkeit, sie aus der Ferne zu steuern. Das bedeutet Wasserschäden und Kosten im großen Stil, und es sind Standortdaten zu Privathäusern und Unternehmen.
Und wie bei den meisten IoT-Findings dieser Art musste hier niemand Verschlüsselung brechen oder Speicherfehler ausnutzen. Das System beantwortete Fragen, die es hätte ablehnen müssen.
Was Hersteller daraus mitnehmen sollten
- Jedem Gerät eine eigene Identität geben. Eigene Zugangsdaten, keine gemeinsamen aus der Firmware.
- Topics auf dem Broker einschränken. Ein Client darf nur seine eigenen Topics lesen und schreiben. Wildcard-Subscriptions müssen für normale Clients unmöglich sein.
- Keine Standortdaten in Nachrichten, die sie nicht brauchen. Daten, die nicht gesendet werden, können nicht abfließen.
- Die Autorisierung auch in der Cloud prüfen. Dieselbe Eigentumsprüfung gehört in jeden API-Aufruf.
- Den Broker überwachen. Ein Client, der alles abonniert, ist ein Vorfall und sollte einen Alarm auslösen.
Genau diese Punkte machen die Cybersecurity-Anforderungen der RED (EN 18031) und der Cyber Resilience Act jetzt für vernetzte Produkte zur Pflicht.
Wir testen Geräte, ihre Apps und ihre Cloud als ein System. Schau dir IoT-Sicherheitstests oder Hardware-Pentests an, oder sieh nach, was ein Test kostet.
FAQ
Häufig gestellte Fragen
Was ist MQTT und warum ist es ein Risiko?
MQTT ist ein leichtgewichtiges Messaging-Protokoll, das viele IoT-Produkte nutzen: Geräte und Apps veröffentlichen Nachrichten auf Topics eines zentralen Brokers und abonnieren diese Topics. Schränkt der Broker nicht ein, welche Topics ein Client nutzen darf, kann jeder verbundene Client Nachrichten für jedes Gerät lesen und senden.
Ist eine Gartenbewässerung wirklich ein Sicherheitsproblem?
Ja. Wer sie kontrolliert, kann Wasserschäden und Kosten verursachen. Die Standortdaten verraten einem Angreifer, wo die Geräte installiert sind, und ihre Aktivität verrät, wann niemand da ist. Dieselben Produktfamilien laufen außerdem in der Landwirtschaft und auf Gewerbeflächen.