Case Study: Root auf dem Saugroboter und fremde Kameras
Wir haben einen Saugroboter mit Kamera getestet: Root-Zugriff auf dem Gerät und Lücken in der Cloud-API, die die Live-Kamera fremder Nutzer öffneten. Was schieflief.
Zyberum Security Team · Veröffentlicht am · 5 Min. Lesezeit
Ein Saugroboter mit Kamera ist eine fahrende Kamera mitten in einer Wohnung. Wir haben einen getestet: das Gerät, die App und die Cloud dahinter. Der Name des Herstellers spielt hier keine Rolle. Das Muster schon, denn wir sehen es immer wieder.
Was wir getestet haben
Das komplette Produkt, so wie ein Angreifer es sieht:
- das Gerät selbst
- die Mobile-App
- die Cloud-API, mit der die App spricht
- den MQTT-Kanal zwischen Gerät und Cloud
- die WebRTC-Videoverbindung für die Live-Kamera
Was wir gefunden haben
Root auf dem Gerät
Wir haben vollen Root-Zugriff auf den Saugroboter erlangt. Mit Root kontrolliert ein Angreifer alles, was das Gerät kann: fahren, aufnehmen, im verbundenen Netzwerk mitlauschen und alles auslesen, was der Hersteller darauf gespeichert hat.
Fremde Geräte über die API
Die schwerwiegenderen Findings lagen in der Cloud. Die API hatte die drei klassischen Autorisierungsfehler:
| Lücke | Was das hier bedeutete |
|---|---|
| IDOR / BOLA | Anfragen zu einem Gerät wurden auch für Geräte beantwortet, die anderen Nutzern gehörten |
| BFLA | Funktionen, die eingeschränkt sein sollten, ließen sich aus einem normalen Nutzerkonto aufrufen |
| Excessive Data Exposure | API-Antworten enthielten weit mehr Informationen, als die App je anzeigte |
MQTT
Der Nachrichtenkanal zwischen Geräten und Cloud hatte eigene Schwächen. Dadurch konnte ein einzelner angemeldeter Nutzer noch mehr sehen und tun.
Die Folge: eine Live-Kamera in einer fremden Wohnung
Zusammen gaben uns diese Findings Zugriff auf den WebRTC-Kamerastream fremder Saugroboter. Nicht unser Testgerät: Geräte anderer Nutzer. Keine Malware, kein physischer Zugriff, kein Passwortraten. Ein normales Konto und die richtigen Anfragen reichten.
Warum das passiert ist
Nichts davon brauchte fortgeschrittene Exploits. Die Ursache war bei jedem Finding dieselbe: Das Backend vertraute dem, was der Client schickte. Geprüft wurde, ob ein Nutzer angemeldet war, aber nicht, ob das Gerät in der Anfrage diesem Nutzer gehörte.
Das ist die häufigste schwere Lücke in vernetzten Produkten. Für automatische Scanner bleibt sie unsichtbar, weil jede einzelne Anfrage legitim aussieht.
Was Hersteller daraus mitnehmen sollten
- Bei jeder Anfrage prüfen, wem das Gerät gehört. Auf dem Server, für jede Geräte-ID, jedes Mal. Nicht in der App.
- MQTT wie eine API behandeln. Jeder Client darf nur auf seinen eigenen Topics senden und nur diese abonnieren.
- Nur zurückgeben, was gebraucht wird. Zeigt die App ein Feld nicht an, sollte die API es nicht senden.
- Davon ausgehen, dass das Gerät geöffnet wird. Alles, was darauf gespeichert ist, wird ausgelesen, Schlüssel eingeschlossen.
- Das ganze Produkt testen. Gerät, App und Cloud zusammen. Die schlimmsten Findings entstehen aus der Kombination.
Nach dem Cyber Resilience Act darf ein solches Produkt nicht mit bekannten ausnutzbaren Schwachstellen ausgeliefert werden, und der Hersteller muss Schwachstellen behandeln und melden. Ein Test vor dem Launch ist günstiger als ein Rückruf danach.
Du willst wissen, was dein Gerät preisgibt? Schau dir IoT-Sicherheitstests, Web- und API-Pentests oder die Kosten eines Tests an.
FAQ
Häufig gestellte Fragen
Was sind IDOR, BOLA und BFLA?
IDOR (Insecure Direct Object Reference) und BOLA (Broken Object Level Authorization) beschreiben dasselbe Problem: Der Server liefert oder ändert ein Objekt, etwa ein Gerät, weil die Anfrage dessen ID nennt, ohne zu prüfen, ob es dem Aufrufer gehört. BFLA (Broken Function Level Authorization) heißt: Ein Nutzer kann Funktionen aufrufen, die für eine andere Rolle gedacht sind, zum Beispiel für einen Administrator.
Warum sind diese Lücken in IoT-Produkten so häufig?
IoT-Backends verwalten Millionen Geräte über eine kleine Zahl von API-Aufrufen und MQTT-Topics. Fehlt die Prüfung „Gehört dieses Gerät diesem Nutzer?“ an einer Stelle, ist jedes Gerät hinter diesem Aufruf offen. Automatische Scanner finden das nicht, weil jede Anfrage technisch gültig ist.