Ein Saugroboter wirkt wie ein harmloses Haushaltsgerät: Er fährt durch die Wohnung, erstellt eine Karte und kehrt zur Station zurück. Der Shark-Fall zeigt, dass dahinter eine größere Cloud-Architektur stehen kann: Gerätezertifikate, MQTT, AWS IoT, App-Konten, Wohnungspläne, manchmal Kameras und Zugriffsregeln, die der Besitzer nicht einsehen kann.

Markenloser Saugroboter mit Wohnungsplan, Router und Cloud-Sicherheits-Schild

Am 13. Juli veröffentlichte der Sicherheitsforscher tokay0 eine Analyse zu Shark-Robotervacuums. Nach seiner Darstellung konnte ein Zertifikat aus einem Shark RV2320EDUS genutzt werden, um Befehle an andere Shark-Geräte in derselben AWS-Region zu senden, weil die Cloud-Policy nicht eng genug auf das eigene Gerät begrenzt war. Genannt werden AWS IoT shadow commands, Remote Code Execution, Kamera-Stream, Motorsteuerung, Wohnungspläne und ein Wi-Fi PSK im Klartext.

Die richtige Schlussfolgerung ist nicht Panik. Der ursprüngliche Beitrag enthält inzwischen den Hinweis, dass SharkNinja die Schwachstelle nach eigenen Angaben am 20. Juli behoben hat. Wichtig ist die Struktur: Wenn der Fehler in der Cloud-Autorisierung des Herstellers liegt, kann der Nutzer zu Hause kaum prüfen, ob Zertifikate rotiert, Policies eingeschränkt oder alle Modelle abgedeckt wurden.

Was der Bericht behauptet

In einem sauber begrenzten IoT-System darf das Zertifikat eines Geräts nur die Topics und Shadows dieses Geräts verwenden. AWS IoT Device Defender warnt selbst vor overly permissive policies, weil ein kompromittiertes Zertifikat sonst Nachrichten, Shadows oder Jobs für viele Geräte lesen oder ändern kann. Tokay0 sagt, genau diese Grenze sei bei seinem Testgerät zu weit gewesen.

Besonders sensibel sind die Datenarten: Kamera, Karte, Wi-Fi-Passwort und Fernsteuerung. The Hacker News, Malwarebytes, Tom’s Hardware und Digital Trends griffen den Fall auf. Die Zahlen aus dem Bericht müssen korrekt eingeordnet werden: 1.517.605 beobachtete Seriennummern und 673.816 Geräte mit Exec_Response in 24 Stunden in einer Region sind kein Nachweis für genauso viele kompromittierte Haushalte, sondern ein Hinweis auf die sichtbare Angriffsfläche.

Was Nutzer tun können

Besitzer sollten App und Firmware prüfen, Support-Hinweise von SharkNinja suchen und Kamera-, Karten- und Verlaufsfunktionen kontrollieren. Wer sehr besorgt ist, kann den Roboter vorübergehend vom WLAN trennen, verliert dann aber Fernsteuerung, Zeitpläne und Cloud-Karten. Ein WLAN-Passwortwechsel ist sinnvoll, wenn man die eigene Einheit für betroffen hält und bewusst alle Geräte neu verbinden will.

Dauerhaft hilft Netztrennung: IoT-Geräte gehören in ein Gastnetz, eine eigene SSID oder ein VLAN ohne freien Zugriff auf Laptops, NAS und Arbeitsgeräte. Das behebt keinen Cloud-Fehler, begrenzt aber lokale Folgeschäden.

Beim nächsten Kauf lohnt ein Datenschutz-Check neben Saugleistung und Navigation. Brauchen Sie wirklich eine Kamera? Funktioniert der Roboter ohne Cloud? Lassen sich Karten löschen? Hat der Hersteller eine Vulnerability Disclosure Policy und klare Security Advisories? Das klügste Smart-Home-Gerät ist oft nicht das mit den meisten Cloud-Funktionen, sondern das, das die Aufgabe mit möglichst wenig Vertrauensfläche löst.