Muse für Mac: Wie eine Diktier-Einstellung zum Risiko für das Konto wurde

Eine Sprachnachricht an einen KI-Assistenten sollte nicht auf einem fremden Server landen. Genau das konnte bei Meta Muse für Mac passieren: Der Sicherheitsforscher Patrick Wardle zeigte mit seinem Proof of Concept not-a-mused, dass sich eine undokumentierte Einstellung für die Diktierfunktion lokal verändern ließ. Dadurch konnten diktierte Anfragen an einen Server unter Kontrolle eines Angreifers gehen – und möglicherweise auch der Token offengelegt werden, mit dem sich Muse beim Nutzerkonto anmeldet. Die Schwachstelle war aber kein Weg, aus der Ferne in einen Mac einzubrechen. Dafür musste bereits Code auf dem Gerät laufen. 811

Der Weg über die Diktierfunktion

Die Einstellung endo_voyager_dictation_endpoint legte fest, wohin Muse diktierte Anfragen zur Transkription schickte. Laut Wardle konnte eine lokal laufende App oder ein Terminal-Befehl diesen Wert ohne besondere macOS-Berechtigungen ändern. Zeigte er auf einen Angreifer-Server, wurde die nächste diktierte Anfrage dorthin statt an Meta gesendet. So konnten Spracheingaben und Authentifizierungsmaterial offengelegt werden. Der Angriff setzte also sowohl lokal laufenden Code als auch die Nutzung der Diktierfunktion voraus; er fing nicht automatisch sämtliche Muse-Unterhaltungen ab. 7828

Was die Demonstration über den möglichen Zugriff zeigte

Berichten zufolge rief eine kompromittierte Muse-Sitzung in Wardles Demonstration den Standort eines verbundenen iPhones in Barcelona ab und startete auf dem Gerät einen Bluetooth-Low-Energy-Scan. Das sind konkret gezeigte Aktionen – kein Beleg dafür, dass sämtliche Berechtigungen von Muse ausgenutzt wurden. Das größere Risiko lag darin, dass jemand mit Zugriff auf das Muse-Konto möglicherweise über den Assistenten auch bereits freigegebene Konten und Geräte erreichen konnte. 91926

Für Privatpersonen wie Unternehmen verschiebt das die Sicherheitsfrage: Nicht nur die Rechte eines lokal laufenden Programms zählen, sondern auch, auf welche Dateien, Dienste und Geräte ein damit kompromittierter Assistent zugreifen könnte. 8919

Meta reagierte – Amazon sperrte Muse aus einem anderen Grund

Wardle teilte später mit, Meta habe den Fehler behoben, und dankte dem Unternehmen für die schnelle Korrektur. Laut späteren Berichten entfernte Meta außerdem die interne Einstellung, mit der sich das Ziel der Diktierfunktion ändern ließ. Wardle riet davon ab, Muse zu installieren. Die vorliegenden Berichte belegen jedoch weder eine ausführliche Begründung für diesen Rat noch eine konkrete Vorhersage über weitere Schwachstellen. 281711

Auch Amazon blockierte Muse beim Einkauf auf seiner Website. Diese Entscheidung wurde jedoch nicht als Reaktion auf Wardles Fund dargestellt. Amazon erklärte gegenüber Adweek, Meta habe die Einkaufsaktivitäten von Muse weder vorab offengelegt noch eine Genehmigung dafür eingeholt. Berichten zufolge beanstandete Amazon zudem, dass sich der Agent beim Zugriff auf die Website nicht als solcher zu erkennen gab. 2224