Shark-Saugroboter: Ein Gerätezertifikat öffnete eine ganze Cloud-Region
Ein Sicherheitsforscher, der unter dem Namen tokay0 veröffentlicht, hat gezeigt, dass sich mit dem Zertifikat eines einzigen Shark-Saugroboters beliebige andere Shark-Geräte derselben Cloud-Region fernsteuern lassen. Möglich waren dabei nicht nur Start und Stopp, sondern die Ausführung beliebiger Shell-Befehle mit Root-Rechten. Auf Testgeräten kam der Forscher damit an den Kamerastream, an die gespeicherte Wohnungskarte und an das WLAN-Passwort im Klartext.
Der Fehler saß nicht in der Firmware der Roboter, sondern in der Cloud-Konfiguration bei SharkNinja. Nach Angaben des Forschers ist die Lücke seit dem 20. Juli 2026 behoben. SharkNinja teilte über ihn mit, man habe die gemeldete Schwachstelle vollständig beseitigt und nehme Datenschutz und Datensicherheit sehr ernst. Eine CVE-Nummer wurde bis heute nicht vergeben.
Vom Lötkolben zum Root-Shell
Der Forscher begann mit einem Shark RV2320EDUS. Auf der Platine fand er offen liegende Debug-Pins, die sich als UART-Schnittstelle entpuppten. Der Login am Betriebssystem war passwortgeschützt, der U-Boot-Bootloader dagegen nicht. Ein Abbruch des Bootvorgangs genügte, um die Bootparameter auf init=/bin/sh zu setzen und eine Root-Shell zu erhalten.
Für dauerhaften Zugriff nutzte er ein Verzeichnis, das ein Startskript des Geräts beim Booten automatisch abarbeitet: /mnt/udisk/debug_sh_folder. Ein dort abgelegtes Skript startete den bereits vorhandenen OpenSSH-Server. Damit war das Gerät nach dem Zusammenbau per SSH erreichbar.
Ein Zertifikat für die ganze Region
Auf dem Roboter läuft ein Dienst namens appd, der eine dauerhafte MQTT-Verbindung zu einem AWS-IoT-Core-Broker hält. Die Authentifizierung erfolgt über gegenseitiges TLS mit einem gerätespezifischen Zertifikat und privaten Schlüssel, die unverschlüsselt im Dateisystem liegen.
So weit ist das übliche Praxis. Der Fehler steckte in der AWS-IoT-Richtlinie, die an dieses Zertifikat gebunden war. Sie beschränkte den Zugriff nicht auf das Gerät, dem das Zertifikat gehört. Der Forscher konnte sich mit seinem eigenen Zertifikat auf den Wildcard-Pfad $aws/things/# abonnieren und damit den Nachrichtenverkehr sämtlicher Shark-Geräte seiner Region mitlesen. Veröffentlichen ließ sich ebenfalls an fremde Gerätepfade. Aus einem Gerätezertifikat wurde damit ein regionaler Generalschlüssel.
Amazon kennt genau diesen Fehlertyp. Die Prüfung IOT_POLICY_OVERLY_PERMISSIVE_CHECK in AWS IoT Device Defender stuft zu weit gefasste Publish-, Subscribe- und Shadow-Berechtigungen als kritisch ein. Die empfohlene Absicherung besteht darin, Ressourcen an die Identität des tatsächlich verbundenen Geräts zu binden.
Der Weg zur Codeausführung
Beim Mitlesen des eigenen Datenverkehrs fiel dem Forscher im Device Shadow ein Feld namens Exec_Command auf. Die Analyse von appd in Ghidra zeigte, warum: Beginnt der Wert dieses Feldes mit dem Präfix ex:, übergibt der Dienst den Rest als Shell-Befehl an popen, sofern er kürzer als 1000 Byte ist.
Der komplette Angriff bestand damit aus drei Schritten. Zertifikat und privaten Schlüssel aus einem selbst gekauften Gerät auslesen, sich damit am MQTT-Broker anmelden und eine präparierte Nachricht an $aws/things/<Seriennummer>/shadow/update senden. Das Zielgerät führt den Befehl aus. Kein Speicherfehler, keine Rechteausweitung, kein zu erratendes Passwort.
Die benötigten Seriennummern sind kein Hindernis. Sie lassen sich programmatisch durchprobieren oder direkt über das Wildcard-Abonnement einsammeln. Zum Nachweis kaufte der Forscher ein zweites Gerät eines anderen Modells, den AV1102ARUS, und öffnete darauf mit dem Zertifikat des ersten Roboters eine Reverse Shell. Der Angriff funktioniert also auch modellübergreifend. Nach eigener Angabe hat er ausschließlich Geräte angegriffen, die ihm selbst gehören.
Um die Reichweite abzuschätzen, ließ der Forscher 24 Stunden lang einen Mitschnitt auf dem Wildcard-Pfad laufen. Ergebnis: 10.536.535 verarbeitete MQTT-Nachrichten und 1.517.605 eindeutige Geräte in einer einzigen AWS-Region. Davon antworteten 673.816 Geräte, also rund 44 Prozent, mit einer Exec_Response-Nachricht, was den vorhandenen Befehlsempfänger belegt.
Diese Zahl beschreibt beobachtete Antworten, keine übernommenen Roboter. Der Forscher hält die tatsächliche Zahl verwundbarer Geräte für höher, da nicht jedes Gerät innerhalb des Beobachtungszeitraums eine solche Antwort sendet. Zertifikate sind an ihre Region gebunden, ein Angreifer müsste für andere Regionen also passende Geräte beschaffen. Ein ernsthafter Aufwand ist das nicht.
Interessant ist ein Nebenbefund: Das Zertifikat des AV1102ARUS besaß eine korrekt eingegrenzte Richtlinie. Dessen Firmware war älter als die des RV2320EDUS. Die fehlerhafte Richtlinie dürfte also irgendwann im Provisionierungsprozess eingeführt worden sein.
- Prüfen, ob der Saugroboter die aktuelle Firmware hat, und die Herstellerinformationen zu diesem Vorfall im Blick behalten.
- Das WLAN-Passwort ändern, wenn ein betroffenes Modell längere Zeit online war. Das lag auf dem Gerät im Klartext und wäre bei einer Übernahme abgeflossen.
- Smarte Geräte mit Kamera oder Mikrofon in ein eigenes WLAN oder Gäste-Netz legen, damit ein gekapertes Gerät nicht auch noch NAS, Drucker und Rechner sieht.
- Bei Geräten, die nicht mehr genutzt werden, WLAN-Zugang entfernen und Gerät aus dem Herstellerkonto löschen, bevor es weitergegeben wird.