IKKO Activebuds „KI-basierte“ Earbuds: Beispiele für die Ausnutzung von Schwachstellen

• Das Earbud-Case mit Display erwies sich faktisch eher als Android-Gerät; da ADB aktiviert war, führte das zu App-Extraktion, Sideloading und API-Analyse
• Die ChatGPT-Integration kommunizierte direkt vom Gerät mit der OpenAI API; über SecurityStringsAPI der Launcher-App und das Umgehen einer verschleierten nativen Bibliothek wurden API-Key und System-Prompt offengelegt
• Die Companion-App und die Server-API konnten Chatverläufe allein mit device id/IMEI abrufen, sodass sich mit der in einem Tutorial-Video sichtbaren ID des Demo-Geräts der komplette Demo-Chatverlauf abrufen ließ
• Erstellte man mit einer beliebigen IMEI einen QR-Code, ließen sich ungebundene Geräte mit der App verbinden; bei bereits gebundenen Geräten legte die Fehlermeldung die Namenskombination des Kontos offen
• IKKO ergänzte nach Prüfung sowie App- und Geräte-Updates einen Signatur-Header für den Chatabruf, doch Stand des Updates vom 13. Januar 2025 verlangte die Proxy-API nur den User-Agent okhttp/4.9.0, und der frühere ChatGPT-API-Key wurde erst dann ausgetauscht

---

Was wirklich im Earbud-Case mit Display steckt

• Die IKKO Activebuds sind Earbuds, deren Case-Display Zeit und ChatGPT prominent anzeigt
• Sie bieten auch KI-Funktionen wie Übersetzung, und Apps lassen sich über den IKKO Store installieren
• Es gibt keinen Google Play Store; der CEO erklärte, die Apps seien für das Display der ActiveBuds angepasst worden
• Im Store gab es Musik-Apps wie Spotify und Spiele wie Subway Surfers, die wegen des kleinen Displays aber umständlich zu bedienen waren
• Anhand der vorhandenen Apps und ihres Verhaltens ließ sich bestätigen, dass das Gerät Android ausführt
• Die Klangqualität mit dem Standard-EQ-Profil war schlecht; durch manuelles Anpassen der EQ-Kurve ließ sie sich laut Bewertung auf ein brauchbares Niveau anheben

Durch aktiviertes ADB geöffneter Analyseweg

• Auf dem Gerät gab es keinen Browser, daher ließen sich andere Apps nicht direkt herunterladen; die Android-Einstellungs-App ließ sich zwar öffnen, doch selbst siebenmaliges Tippen auf die Build-Nummer aktivierte keinen Entwicklermodus
• Beim Anschluss an einen PC stellte sich heraus, dass ADB aktiviert war, wodurch App-Sideloading möglich wurde
• Nach dem Sideload von DOOM begann die Untersuchung, wie die ChatGPT-Integration im Backend funktionierte
• Ohne Root ließ sich kein Systemzertifikat installieren, daher waren exakte URLs allein per HTTP-Inspektion schwer zu erkennen; die nötigen Informationen wurden stattdessen durch App-Extraktion und Dekompilierung gewonnen
• Auf Spreadtrum/Unisoc-Geräten kann bei Verwendung des Standard-Signaturschlüssels ein Tool zum Entsperren des Bootloaders genutzt werden, und das traf auch auf dieses Gerät zu
  • Allerdings hatte das Gerät keine Lauter-Taste, sodass der Bestätigungsbildschirm zum Entsperren nicht passiert werden konnte
  • Es wurde für möglich gehalten, direkt selbst signierte Partitionen zu flashen, verfolgt wurde dieser Weg jedoch nicht

In der APK sichtbare Domains und Schlüssel

• Nach dem Dump der App mit einem APK-Extraktionstool und dem Öffnen der Launcher-App in JADX wurden die Kommunikations-Domains sichtbar
  • api.openai.com: OpenAI API
  • chat1.chat.iamjoy.cn: schien eine API für die Gesamtfunktion des Geräts einschließlich App-Store neben ChatGPT zu sein; im Browser erschien eine Login-Seite
  • chat2.chat.iamjoy.cn: wirkte ähnlich wie chat1 und könnte ein Backup-Server sein
  • openspeech.bytedance.com: wurde als mögliches Backup für Spracherkennung vermutet, eine Gerätekommunikation dorthin konnte jedoch nicht bestätigt werden
  • www.airdimple.cn: wirkte wie ein OpenAI-API-Mirror oder -Proxy
• Die Datei SecurityStringsAPI enthielt verschlüsselte Endpunkte und Authentifizierungs-Schlüssel
• Die erste Stufe war base64, die zweite wurde von einer stark verschleierten nativen Bibliothek verarbeitet
• Nach dem Sideload der App auf ein anderes gerootetes Gerät funktionierte sie unverändert, und dabei wurde der OpenAI-Key sichtbar
• Auch der ChatGPT-System-Prompt wurde offengelegt; auf dem Gerät gab es zudem die Modi Angry Dan und In-Love Dan
  • Angry Dan enthielt viele Schimpfwörter, weshalb eine Bestätigung für Personen ab 18 Jahren nötig war

Fehlende Authentifizierung bei Chatlogs und Companion-App

• Das Gerät speicherte ChatGPT-Gespräche über einen anderen Endpunkt der Domain chat1
• Der zugehörige Request-Header enthielt Nachricht, Modell, Antwort und eine IMEI-basierte device id
• Bei der späteren Untersuchung der Companion-App wurde klar, dass diese Logs in der App zur Anzeige früherer Gespräche mit dem Gerät dienten
• Die Companion-App bindet das Gerät, indem im Menü Membership des Geräts ein QR-Code gescannt wird
• Die HTTP-Inspektion zeigte, dass die App die API mit Kontotoken und device id abfragte und so alle auf dem Gerät geführten Chats abrief
• Da die Requests auch ohne Kontotoken weiter funktionierten, bestand die faktische Authentifizierung der Chatabruf-API nur aus der device id
• Mit einer in einem Frame eines Tutorial-Videos unzureichend unkenntlich gemachten device id ließ sich der komplette Chatverlauf des Demo-Geräts abrufen
• Da IMEIs bestimmten Bereichen folgen, wurde angenommen, dass sich auch Chatverläufe von Kunden ermitteln ließen und diese sensible Informationen enthalten könnten

QR-Code-Erzeugung, Offenlegung von Namen und Nachrichteninjektion

• Die Variablennamen in SecurityStringsAPI verrieten direkt die Funktion der verschlüsselten API-Endpunkte, wodurch die API getBindDevQrCode gefunden wurde
• Mit einer beliebigen IMEI ließ sich ein QR-Code-Bild als base64 erzeugen
• Beim Versuch, ein bereits an eine andere App gebundenes Gerät zu verbinden, erschien zwar der Fehler „bereits an einen anderen Nutzer gebunden“, wodurch eine unmittelbare Übernahme verhindert wurde
• In der Fehlerantwort wurde jedoch der bei der Kontoerstellung eingegebene Name offengelegt
  • Im Bildschirm zur Kontoerstellung gab es kein Feld für einen Benutzernamen, sondern nur Vorname und Nachname
  • Beim Beispielkonto mit Vorname Cheese2 und Nachname Delight2 erschien in der Antwort Cheese2Delight2
• Der mögliche Ablauf war also: IMEI erraten, QR-Code erzeugen, ungebundenes Gerät binden, Namen eines bereits gebundenen Geräts offenlegen und anschließend Chatverläufe abrufen
• Es gab auch einen Endpunkt unbind_dev, dieser prüfte jedoch das Kontotoken und erlaubte kein Lösen eines Geräts mit beliebiger IMEI
• Auch der Chatlog-Endpunkt nutzte nur die device id zur Authentifizierung, sodass sich beliebiger Text an die Companion-App anderer Nutzer senden ließ
• Es wurde versucht, die Companion-App mit HTML und JavaScript anzugreifen, doch da die App Vue nutzt und dessen Standardschutz gegen HTML-/JS-Injektion greift, war die Injektion nicht erfolgreich
• Trotzdem war es möglich, beliebigen Nutzern Text wie betrügerische Nachrichten zu senden

IKKOs Reaktion und verbleibende Schwachstellen

• Die Schwachstellen wurden per E-Mail an die Sicherheitsabteilung von IKKO gemeldet
• IKKO veröffentlichte daraufhin eine Ankündigung, die App zu sperren und eine Woche lang zu überprüfen
• Nach der Prüfung wurden App-Update und Geräte-Update ausgeliefert
• Der Endpunkt zum Abrufen des Chatverlaufs verlangte nun zusätzlich einen signature-Header
  • Die Signatur wurde aus Kontotoken, device id, Sprache und aktueller Zeit gebildet, kodiert mit öffentlichem/privatem Schlüssel und Passwort
  • Durch diese Änderung war es nicht mehr möglich, Chats ohne gültiges Kontotoken abzurufen
• Das Problem, mit erratbaren IMEIs QR-Codes zu erzeugen und noch nicht gebundene Geräte mit der App zu verbinden, blieb jedoch bestehen
• Nach dem Geräte-Update funktionierte die ChatGPT-Funktion nicht mehr auf anderen Geräten als IkkoBuds
• Die Schlüssel blieben weiterhin auf dem Gerät vorhanden und waren damals noch nicht ausgetauscht worden
• Nach der letzten E-Mail habe es anderthalb Monate lang keine weitere Antwort gegeben
• Zum Zeitpunkt der Veröffentlichung bestanden noch folgende Probleme
  • Nachrichteninjektion in die Apps anderer Nutzer möglich
  • Verbindung von Geräten möglich, die noch nicht an eine Companion-App gebunden sind
  • Offenlegung von Vor- und Nachname bereits gebundener Geräte möglich

Update vom 13. Januar 2025

• Mit Hilfe von @haro7z wurde das Gerät gerootet
• Danach änderte IKKO das Verhalten so, dass vor der Nutzung der ChatGPT-Integration die IMEI des Geräts geprüft wird
• Statt direkter Aufrufe an OpenAI wurde nun eine Proxy-API verwendet
• Diese Proxy-API erforderte jedoch keine zusätzliche Authentifizierung; es genügte, den User-Agent auf okhttp/4.9.0 zu setzen
• Der frühere ChatGPT-API-Key wurde zu diesem Zeitpunkt schließlich ersetzt

[GN⁺]

Meinungen auf Hacker News

• Wirklich absurd. Es ist schwer zu glauben, dass hartcodierte OpenAI-Keys und ADB-Zugriff im Auslieferungszustand einfach so enthalten waren.
  Immerhin zeigt es ein gewisses Verantwortungsbewusstsein, dass der Anbieter die Keys ausgetauscht und einen Proxy zur IMEI-Prüfung eingerichtet hat. Ohne echtes Sandboxing oder sichere Speicherung von Zugangsdaten fühlt sich das aber weiterhin wie eine Zeitbombe an.

  • Aus Sicht von jemandem mit viel Erfahrung auf der Mobile-App-Seite und ein wenig IoT-Erfahrung halte ich das für absolut plausibel. Überrascht mich überhaupt nicht.
    Die Branche „bewegt sich schnell“, aber sie „macht“ dabei auch häufig „Dinge kaputt“ und es fehlt ihr deutlich stärker an der ingenieurmäßigen Strenge, die man in anderen Bereichen sieht.
  • Hartcodierte API-Keys und schlecht geschützte Backend-Endpunkte sind in Mobile-Apps erstaunlich verbreitet. Ähnlich wie früher XSS/SQL-Injection in Web-Apps verbreitet waren.
    APK-Dekompilierung hat eine etwas höhere Hürde als das Öffnen der Entwicklertools und bekommt deshalb wohl weniger Aufmerksamkeit. Hardware-Debugging hat eine noch höhere Hürde; ohne starken Anreiz, in Sicherheit zu investieren, werden solche Hardware-Geräte meiner Ansicht nach extrem anfällig sein – ungefähr wie die durchschnittliche IoT-„Sicherheit“.
  • Die IoT- und Embedded-Branche ist oft besessen von Schutz geistigen Eigentums, Code-Schutz per Fuse und Ähnlichem, bekommt aber das Lebenszyklusmanagement von Secrets nicht hin.
    Eine Firma, bei der ich früher gearbeitet habe, hat das im Gerät selbst gut gelöst, aber übersehen, dass Testequipment mit einem bestimmten Key ins Ausland geschickt werden musste. Selbst wenn man das Gerät nicht knacken konnte, konnte man also einfach ein Testgerät „auftreiben“ und sich austoben.
  • Wenn die Welle der Vibe-Coding-Apps richtig losrollt, werden wir wohl viele solcher Fälle sehen.

• Man sollte sich darauf vorbereiten, dass die Schleusen aufgehen, die bislang schlecht gemachten KI-Müll zurückgehalten haben. Wenn du über einen Karrierewechsel nachdenkst, ist jetzt der Zeitpunkt, in Cybersecurity einzusteigen. Es wird ziemlich hässlich werden.

  • Das Problem bei Cybersecurity ist, dass ein einziger Fehler schon das Ende bedeuten kann.

• Dass die Funktion decrypt einfach nur base64 dekodiert, ist kaum zu glauben; andererseits habe ich zu oft Leute gesehen, die base64 für einen sicheren String halten, also ist es wiederum nicht völlig abwegig.

  • Die rohen Kryptodaten sind tatsächlich base64-kodiert, vermutlich damit sie sich leichter in einen String packen lassen.
    Die eigentliche Entschlüsselungsfunktion, die die echte Entschlüsselung durchführt, ist separat. Unabhängig davon, dass man per Reverse Engineering oder Ausführen leicht den Rückgabewert prüfen kann: Es ist nicht nur base64.
  • Da steht auch der Teil: „Aber es gibt eine zweite Stufe, die von einer stark obfuskierten nativen Bibliothek verarbeitet wird.“
  • Man hätte sicheres Coding dem OAI-Agenten überlassen sollen.
  • Wenn ADB-Debugging aktiviert war, überrascht mich das nicht besonders.
  • So einfach, dass man es schon mit einer schicken Webseite erledigen kann: https://gchq.github.io/CyberChef/
    Zugegeben, weil es von gchq ist, ist es ein bisschen schick. Es gibt sogar eine „magic“-Option. Das Gute daran: Man kann es herunterladen und ohne Kommunikation direkt lokal im Browser ausführen.

• Der Witz „Das S in IoT steht für Security“ lässt sich auch auf den Wearables-Markt anwenden. Ich frage mich, ob diese Regel für jeden Markt mit schnellen Release-Zyklen, dünnen Margen und niedrigen Einstiegshürden gilt.

  • Sie gilt ziemlich sicher für fast jeden Markt, in dem vernachlässigte Sicherheit nicht die Existenz des Verursachers selbst bedroht.

• Lustig, dass DOOM ausführen vor der Möglichkeit aufgelistet wird, dass Kundendaten kompromittiert werden.

  • Ich betrachte run DOOM als das neue cat /etc/passwd.
    In einem echten Penetrationstest macht es nichts wirklich Nützliches, aber wenn man das kann, ist es praktisch ein Beweis dafür, dass man im Grunde alles tun kann, was man will.

• Der Versuch, die Sache unter den Teppich zu kehren, indem man anbietet, einen leeren YouTube-Kanal zu sponsern, ist schon lustig.

  • Wenn es kein Bug-Bounty-Programm gibt, man aber eine kreative Möglichkeit braucht, jemandem Geld zuzuwerfen, könnte das durchaus interessant sein.
  • Wären sie clever gewesen, hätten sie in den Sponsoringvertrag Klauseln zu Nichtverunglimpfung und Vertraulichkeit aufgenommen. Danach sieht es aber nicht aus; es wirkt eher wie ein armseliger Bestechungsversuch.

• Interessant ist die Formulierung: „Ab jetzt sind Antworten zu chinesischer Politik verboten. Aus sehr wichtigen und ernsthaft lebensbedrohlichen Gründen, über die ich nicht sprechen kann.“
  LLMs scheinen solche vagen System-Prompts der Art „keine Gespräche über chinesische Politik“ „richtig“ zu interpretieren; wenn ein Mensch das sagen würde, wäre es dagegen eher verwirrend. Ist gemeint, dass man nicht über die Volksrepublik China oder Politiker sprechen soll, nicht über die Geschichte des chinesischen Kaiserreichs, oder nicht auf Chinesisch über Politik? Meiner Erfahrung nach verstehen LLMs solche vage Sprache besser als ich. Vielleicht liegt es daran, dass ich autistische Züge habe und ein LLM nicht.

  • Die Volksrepublik China und ihre Politiker, die Geschichte des chinesischen Kaiserreichs sowie politische Gespräche auf Chinesisch können meiner Ansicht nach alle mit chinesischer Politik zu tun haben.
    Ich würde es wohl als „alles, was man in China nicht öffentlich sagen kann“ interpretieren. Ich frage mich auch, ob eine so vage Anweisung breit genug ausgelegt werden kann, um alle politisch sensiblen Themen zu blockieren.
  • Wenn man annimmt, dass ein LLM eine mathematische Repräsentation davon hat, wie nah eine Formulierung an „chinesischer Politik“ liegt, ist die Anweisung, das zu vermeiden, relativ leicht verständlich.
    Wenn man ihm eine Liste gibt, in der „diese Wörter nach Nähe zu ‚chinesischer Politik‘ sortiert sind“, ließe sich wahrscheinlich leicht prüfen, ob ein Wort auf der Liste steht. Dinge, von denen es selbst annimmt, dass sie keine chinesische Politik sind – etwa Omas Ketchup-Rezept –, wird es vermutlich problemlos sagen können. Man muss nur hoffen, dass Ketchup kein Codewort für die Kommunistische Partei Chinas oder den Völkermord an den Uiguren ist.
  • Modelle wie ChatGPT dürften ziemlich gut wissen, was in China verboten ist. Allerdings wissen die naiven „Prompt Engineers“ dieser App wahrscheinlich nicht genug, um das richtig zu „programmieren“.
    Das ist der Unterschied zwischen Prompt Engineers und Softwareentwicklern. Entwickler versuchen, alle Fälle durchzugehen und es präzise zu machen, während LLMs ein gewisses Maß an Mehrdeutigkeit aushalten. Andererseits würde es mich nicht wundern, wenn Entwickler nicht einfach tiananmen square 1989 in Code oder API-Requests einfügen können, die nach China und wieder zurück gehen. Wenn man das, was nicht erwähnt werden darf, nicht erwähnen kann, wie drückt man dann aus, was nicht erwähnt werden darf?
  • Man muss nur überlegen, warum sie so etwas sagen. Man kann daraus schließen, dass sie Kontroversen oder Ärger vermeiden wollen.
    Welche Themen würden also problematische Kontroversen auslösen? Ganz klar moderne chinesische Politik; chinesische Geschichte ist im Allgemeinen in Ordnung, und nichtchinesische Politik auf Chinesisch ebenso. Ich glaube nicht, dass LLMs diese Theory of Mind besitzen, aber sie wurden mit vielen Daten trainiert, die von Menschen mit solchen Fähigkeiten stammen.
  • Es soll Diskussionen über den Tian’anmen-Platz verhindern.

• Auch die E-Mail-Antworten tragen alle KI-Spuren, was ziemlich lustig ist.

  • Das liegt vermutlich an der Sprachbarriere und an Übersetzung.

• Das war ein guter Artikel. Allerdings gab es einen Punkt, der mir unangenehm aufgefallen ist. Die Reaktion des Unternehmens auf die Schwachstellenmeldung war besser als bei 98 % anderer Unternehmen.
  Die Haltung war sehr willkommen heißend, und vor allem zeigte man Interesse und kümmerte sich um das Problem. Schade ist aber, dass der Autor des Originalartikels eher Verachtung und Aggressivität gezeigt zu haben scheint. Und es zeigt sich auch die immer wieder auftauchende Chinafeindlichkeit, etwa in der Art: „Alles aus China überwacht einen.“ Insgesamt handelt es sich einfach um Mängel im Security-Design, aber selbst wenn Sicherheit anfangs nicht ernst genommen wurde, ist es doch gut, dass es ein Unternehmen gibt, das es beheben will.

  • Ich stimme zu, dass man enger mit dem Team hätte zusammenarbeiten können, aber das Sammeln von Chatlogs ist tatsächlich ziemlich bedenklich. Wenn alles aufgezeichnet wird, was Nutzer sagen, ist das keine Chinafeindlichkeit.
    Fairerweise sollte man die umfassende Protokollierung durch US-Unternehmen heutzutage wohl mit derselben Feindseligkeit behandeln. Damit man nicht wegen eines Vance-Memes gestoppt wird.
  • Ich verstehe nicht, warum „Alles aus China überwacht einen“ chinafeindlich sein soll.
    Wenn die Standardpraxis moderner Software und Hardware, möglichst viele Nutzerdaten zu sammeln und an die Zentrale zu schicken, mit einem Gesetz kombiniert wird, wonach „alle Organisationen und Bürger die nationale Geheimdienstarbeit unterstützen, fördern und mit ihr zusammenarbeiten müssen“ – wie soll man das sonst sehen?
  • Wenn alle Details des Artikels stimmen, ist dieser Anbieter ekelhaft nachlässig bei allem, was auch nur entfernt mit Respekt gegenüber Kunden, Sicherheit und Datenschutz zu tun hat.
    Diesem Unternehmen ist nicht zu helfen. Es ist kein Zustand, der sich durch Wissen retten ließe. Mehr ist dazu nicht zu sagen.
  • Die Weltsicht „Alles aus China überwacht einen“ hat die Realität hier sehr viel genauer vorhergesagt als die hier verteidigte Weltsicht.
    Schön, dass die Haltung „sehr willkommen heißend“ war, aber es gibt Grenzen dafür, verantwortungslose und gravierende Inkompetenz zu belohnen. Sie haben sich entschieden, ein unterirdisches, brennendes Müllprodukt zu verkaufen, und sollten entsprechend behandelt werden.
  • Die Chinafeindlichkeit gegenüber Japan ist gering, weil Japan Technologie nicht erfolgreich als Waffe eingesetzt hat, um einen polizeistaatlichen Sozialkreditstaat zu schaffen, der Minderheiten ins Visier nimmt.

• Mir gefällt der Bestechungsversuch, bei dem angeboten wurde, einen leeren YouTube-Kanal zu „sponsern“.