Ungeschlossene Shark-Lücke erlaubt Gerätezugriff über eine ganze AWS-Region

Im Kern geht es um eine fehlerhafte Gerätepolitik in AWS IoT. Laut tokay0 war die an das Gerätezertifikat gebundene Richtlinie nicht auf das jeweilige Gerät beschränkt. Wird das Zertifikat gegenüber dem Cloud-Broker von Shark präsentiert, akzeptiert der Broker demnach veröffentlichte Nachrichten für beliebige Geräte, die er bedient. Der Forscher betont, dass dafür weder Speicherfehler noch Rechteausweitung noch das Erraten von Passwörtern nötig seien.

Der ausgeführte Befehl steckt nach seiner Analyse in einem regulären Feld des sogenannten Device Shadow, also des pro Gerät in der AWS-Cloud gepflegten Zustandsdokuments. Mit dem Zertifikat eines RV2320EDUS abonnierte tokay0 das Thema $aws/things/# und beobachtete den über den Broker laufenden Verkehr, wobei er Seriennummern sammelte. Veröffentlichte Nachrichten funktionieren laut seiner Beschreibung nach demselben Prinzip: Der Shadow enthält ein Feld namens Exec_Command, das vom Verwaltungsdienst appd eingelesen und an eine Funktion execute_command übergeben wird, die Inhalte unter 1.000 Byte per popen ausführt.

Ein Shadow-Update mit diesem Feld an das Thema eines Zielgeräts reicht demnach aus, damit ein Gerät mit entsprechendem Handler den Befehl ausführt. Den modellübergreifenden Pfad demonstrierte tokay0 nach eigener Aussage an einem AV1102ARUS, den er eigens als Zielgerät gekauft hatte. Er landete dort eine Reverse Shell und nutzte sie, um einen Live-Feed der Bordkamera abzurufen, während sich der Roboter bewegte.

An das nötige Zertifikat zu gelangen, sei bei älteren Geräten vergleichsweise einfach. Laut tokay0 lässt es sich mit einem Schraubendreher ausbauen: Auf dem Mainboard liegen UART-Pins frei, die U-Boot-Konsole verlange kein Passwort, und mit init=/bin/sh in den Boot-Argumenten erhalte man eine Root-Shell. Schlüssel und Zertifikat liegen demnach unter /mnt/res/vapp/certs/ als gewöhnliche Dateien.

Eine Einschränkung gibt es laut dem Bericht: Zertifikate sind an ihre jeweilige AWS-Region gebunden. Ein in einer Region entnommenes Zertifikat erreicht also nur Geräte in derselben Region. Für eine andere Region wäre ein dort ausgestelltes Zertifikat mit derselben fehlerhaften Richtlinie erforderlich.

AWS selbst hat für genau diese Richtlinienform laut Quelltext eine Prüfung. Device Defender, der Prüfservice für IoT-Flotten, markiert Richtlinien als kritisch, wenn sie publish oder subscribe auf $aws/things/* erlauben, statt das Thema mit ${iot:Connection.Thing.ThingName} an das verbundene Gerät zu binden. Diese Prüfung erscheint als IOT_POLICY_OVERLY_PERMISSIVE_CHECK. In der AWS-Dokumentation wird gewarnt, dass ein kompromittiertes Zertifikat mit einer solchen Richtlinie es Angreifern erlaubt, „Shadows, Jobs oder Job-Ausführungen für alle Ihre Geräte zu lesen oder zu verändern“.

Nicht jedes Zertifikat ist laut tokay0 ein Universalschlüssel. Ein Gerät mit der fehlerhaften Richtlinie werde zum Schlüssel; jedes Gerät, das Exec_Command ausführt, sei ein Ziel, selbst wenn sein eigenes Zertifikat korrekt eingegrenzt sei. Den AV1102ARUS beschreibt er als Ziel, aber nicht als Schlüssel: Dessen Zertifikat sei korrekt eingegrenzt gewesen und habe kein Wildcard-Abonnement erlaubt. Seine Firmware sei mehrere Jahre neuer gewesen. tokay0 wertet das als Hinweis auf eine Bereitstellungsreparatur, die ältere Zertifikate in der Flotte nicht erreicht habe.

Die Reichweite seiner Messung fällt konkreter aus als die Überschrift seines Beitrags mit „Millionen“. Innerhalb von 24 Stunden zählte tokay0 in einer AWS-Region 1.517.605 eindeutige Shark-Seriennummern. Davon sendeten 673.816 Geräte, also 44 Prozent, eine Exec_Response, was er als Bestätigung dafür wertet, dass das Gerät den Befehls-Handler ausführt. Er betont, dass dies beobachtete Antworten seien, nicht getestete oder kompromittierte Geräte.

Zur Offenlegung schildert tokay0, er habe SharkNinja am 1. März kontaktiert und am 11. März Details übermittelt. Das Unternehmen habe den Eingang am nächsten Tag bestätigt, am 27. April mitgeteilt, der Bericht werde geprüft, und am 3. Juli angekündigt, bis Freitag, dem 10. Juli, ein bestätigtes Abschlussdatum zu nennen. Diese E-Mail sei nicht eingetroffen. Veröffentlicht habe er deshalb am 13. Juli. Nach seiner Darstellung spielte der Hersteller die Schwere herunter und stellte infrage, ob „eine CVE angemessen“ sei.

SharkNinja hatte bis Donnerstag nichts zu der Lücke veröffentlicht. Eine CVE gibt es ebenfalls nicht: tokay0 wandte sich am 11. Juni an MITREs „CNA der letzten Instanz“, hatte bei Veröffentlichung aber noch keine Kennung erhalten. Eine Abhilfe müsste laut Bericht nicht über Firmware erfolgen, sondern in SharkNinjas AWS-Konto. Nach den AWS-Empfehlungen lässt sich eine nicht konforme Richtlinie durch eine eingegrenzte Version via CreatePolicyVersion mit gesetztem Schalter setAsDefault ersetzen. Das würde diese Version für alle Zertifikate mit dieser Richtlinie aktiv machen. Eine vollständige Neuvergabe der Zertifikate, die tokay0 bereits im März empfohlen habe, sei die aufwendigere Folgemaßnahme.