IKKO Activebuds : exploitation de vulnérabilités sur des écouteurs « alimentés par l’IA »

• Le boîtier d’écouteurs avec écran s’est avéré être en pratique plus proche d’un appareil Android, avec ADB activé, ce qui a permis l’extraction d’apps, le sideloading et l’analyse des API
• L’intégration à ChatGPT communiquait directement depuis l’appareil avec l’API OpenAI ; en contournant SecurityStringsAPI dans l’app lanceur et une bibliothèque native lourdement obfusquée, la clé API et le prompt système ont été exposés
• L’app compagnon et l’API serveur permettaient de consulter l’historique des chats avec le seul device id/IMEI, ce qui a permis de récupérer tout l’historique de démonstration à partir de l’ID d’un appareil démo visible dans une vidéo de tutoriel
• En générant un code QR avec un IMEI arbitraire, il était possible de connecter à l’app des appareils non encore liés ; pour les appareils déjà liés, la réponse d’erreur révélait la combinaison du prénom et du nom du compte
• IKKO a ajouté un en-tête de signature pour la consultation des chats via une vérification et des mises à jour de l’app et de l’appareil, mais au 13 janvier 2025, l’API proxy n’exigeait encore que le User-Agent okhttp/4.9.0, et l’ancienne clé API ChatGPT n’a été remplacée qu’à ce moment-là

---

La vraie nature du boîtier d’écouteurs avec écran

• Les IKKO Activebuds sont des écouteurs dont le boîtier met en avant l’heure et ChatGPT sur son écran
• Ils proposent aussi des fonctions IA comme la traduction, et permettent d’installer des apps depuis le store IKKO
• Il n’y a pas de Google Play Store, le CEO expliquant que les apps avaient été adaptées à l’écran des ActiveBuds
• Le store proposait des apps musicales comme Spotify et des jeux comme Subway Surfers, mais la navigation restait peu pratique à cause du petit écran
• La présence et le fonctionnement des apps confirmaient que l’appareil exécutait Android
• La qualité audio du profil EQ par défaut était jugée médiocre, mais en ajustant manuellement la courbe EQ, elle devenait acceptable

Une voie d’analyse ouverte par l’activation d’ADB

• L’appareil n’ayant pas de navigateur, il était difficile de télécharger directement d’autres apps, et même si l’app Réglages Android pouvait être ouverte, appuyer 7 fois sur le numéro de build n’activait pas le mode développeur
• Une fois connecté à un PC, ADB était activé, ce qui a permis le sideloading d’apps
• Après avoir sideloadé DOOM, l’analyse a commencé pour comprendre comment l’intégration à ChatGPT fonctionnait côté backend
• Sans root, il n’était pas possible d’installer des certificats système, ce qui rendait difficile l’identification précise des URL via la seule inspection HTTP, mais les informations nécessaires ont été obtenues par extraction et décompilation des apps
• Sur les appareils Spreadtrum/Unisoc utilisant la clé de signature par défaut, il était possible d’utiliser un outil de déverrouillage du bootloader, et cet appareil en faisait partie
  • Toutefois, l’appareil n’ayant pas de bouton volume haut, il n’était pas possible de valider l’écran de confirmation du déverrouillage
  • La possibilité de flasher directement une partition signée manuellement a été envisagée, mais non poursuivie

Domaines et clés révélés dans l’APK

• Après avoir dumpé les apps avec un outil d’extraction d’APK et ouvert l’app lanceur dans JADX, plusieurs domaines de communication sont apparus
  • api.openai.com : API OpenAI
  • chat1.chat.iamjoy.cn : semblait servir aux fonctions globales de l’appareil, au-delà de ChatGPT, comme l’App Store, et affichait une page de connexion dans le navigateur
  • chat2.chat.iamjoy.cn : semblait similaire à chat1, possiblement un serveur de secours
  • openspeech.bytedance.com : suspecté comme service de secours pour la reconnaissance vocale, sans communication confirmée depuis l’appareil
  • www.airdimple.cn : semblait être un miroir ou un proxy de l’API OpenAI
• Le fichier SecurityStringsAPI contenait des endpoints chiffrés et des clés d’authentification
• La première étape reposait sur du base64, la seconde étant traitée par une bibliothèque native fortement obfusquée
• En sideloadant l’app sur un autre appareil rooté, l’app fonctionnait telle quelle, ce qui a permis d’identifier la clé OpenAI
• Le prompt système de ChatGPT a également été exposé, et l’appareil comportait aussi des modes Angry Dan et In-Love Dan
  • Angry Dan contenait de nombreuses insultes et nécessitait une vérification de majorité

Journaux de chat et absence d’authentification dans l’app compagnon

• L’appareil enregistrait les conversations ChatGPT vers un autre endpoint du domaine chat1
• Les en-têtes de cette requête incluaient le message, le modèle, la réponse et un device id basé sur l’IMEI
• L’analyse de l’app compagnon a ensuite confirmé que ces logs servaient à afficher dans l’app l’historique des conversations tenues avec l’appareil
• L’app compagnon effectuait l’association en scannant un code QR dans le menu Membership de l’appareil
• L’inspection HTTP a montré que l’app interrogeait l’API avec un token de compte et le device id pour récupérer l’ensemble des chats tenus sur l’appareil
• Même après suppression du token de compte, la requête continuait de fonctionner : en pratique, l’authentification de l’API de consultation des chats reposait donc uniquement sur le device id
• En utilisant un device id insuffisamment flouté dans une image d’une vidéo de tutoriel, il a été possible de récupérer l’intégralité de l’historique des chats de l’appareil de démonstration
• Comme les IMEI suivent des plages spécifiques, il a été estimé possible de retrouver aussi les historiques de clients, avec un risque de données sensibles

Génération de code QR, divulgation de nom et injection de messages

• Les noms de variables dans SecurityStringsAPI révélaient directement l’usage des endpoints API chiffrés, ce qui a permis d’identifier l’API getBindDevQrCode
• En fournissant un IMEI arbitraire, il était possible de générer une image QR encodée en base64
• Si l’on tentait de connecter un appareil déjà lié à une autre app, une erreur indiquait qu’il était « déjà lié à un autre utilisateur », empêchant ainsi une prise de contrôle arbitraire
• Mais la réponse d’erreur exposait le nom saisi lors de la création du compte dans l’app
  • L’écran de création de compte ne comportait pas de champ nom d’utilisateur, seulement prénom et nom
  • Pour un compte exemple avec le prénom Cheese2 et le nom Delight2, la réponse révélait Cheese2Delight2
• Le scénario possible était le suivant : deviner un IMEI, générer un code QR, lier un appareil non encore associé, révéler le nom d’un appareil déjà associé, puis consulter l’historique des chats
• Un endpoint unbind_dev existait aussi, mais il vérifiait le token de compte et n’autorisait pas le détachement arbitraire d’un appareil à partir d’un IMEI
• L’endpoint des logs de chat utilisait lui aussi uniquement le device id comme authentification, ce qui permettait d’envoyer du texte arbitraire vers l’app compagnon d’un autre utilisateur
• Une tentative d’attaque contre l’app compagnon via HTML et JavaScript a été menée, mais l’app utilisant Vue et ses protections par défaut contre l’injection HTML/JS, l’injection a échoué
• Il restait néanmoins possible d’envoyer à des utilisateurs arbitraires des messages textuels de type frauduleux

Réponse d’IKKO et vulnérabilités restantes

• Les vulnérabilités ont été signalées par email à l’équipe sécurité d’IKKO
• IKKO a ensuite publié une annonce indiquant le verrouillage de l’app et une semaine de vérification
• Après cette vérification, une mise à jour de l’app et de l’appareil a été déployée
• L’endpoint de consultation de l’historique des chats exigeait désormais un nouvel en-tête signature
  • La signature était construite en encodant le token de compte, le device id, la langue et l’heure actuelle avec une clé publique/privée et un mot de passe
  • Ce changement a rendu impossible la récupération des chats sans token de compte valide
• Cependant, le problème permettant de générer un code QR à partir d’un IMEI prévisible pour connecter à l’app un appareil pas encore lié persistait
• Après la mise à jour de l’appareil, la fonction ChatGPT ne fonctionnait plus depuis d’autres appareils qu’IkkoBuds
• Les clés restaient toujours présentes dans l’appareil et n’avaient pas encore été remplacées à ce moment-là
• Il est précisé qu’aucune réponse supplémentaire n’a été reçue pendant un mois et demi après le dernier email
• Au moment de la rédaction, les problèmes restants étaient les suivants
  • Possibilité d’injecter des messages dans l’app d’un autre utilisateur
  • Possibilité de connecter des appareils non encore liés à l’app compagnon
  • Possibilité d’exposer le prénom et le nom d’appareils déjà liés

Mise à jour du 13 janvier 2025

• L’appareil a ensuite été rooté avec l’aide de @haro7z
• IKKO a alors modifié le fonctionnement pour vérifier l’IMEI de l’appareil avant l’utilisation de l’intégration ChatGPT
• Au lieu d’appels directs, l’intégration utilisait désormais une API proxy
• Toutefois, cette API proxy ne nécessitait pas d’authentification distincte et il suffisait de définir le User-Agent sur okhttp/4.9.0
• L’ancienne clé API ChatGPT a finalement été remplacée à ce moment-là

[GN⁺]

Avis sur Hacker News

• C’est vraiment absurde. Difficile de croire qu’une clé OpenAI codée en dur et un accès ADB aient été présents tels quels à la sortie d’usine.
  Cela dit, le fait que le fournisseur ait remplacé la clé et mis en place un proxy pour vérifier l’IMEI montre un certain sens des responsabilités. Mais sans véritable sandboxing ni stockage sécurisé des identifiants, ça ressemble toujours à une bombe à retardement.

  • Avec pas mal d’expérience côté applis mobiles et un peu en IoT, je trouve ça tout à fait plausible. Ça ne me surprend pas du tout.
    Le secteur dit “avancer vite”, mais il “casse” aussi souvent les choses, avec beaucoup moins de rigueur d’ingénierie que ce qu’on observe dans d’autres domaines.
  • Les clés d’API codées en dur et les endpoints backend mal protégés sont étonnamment courants dans les applications mobiles. C’est un peu l’équivalent des failles XSS/injections SQL dans les anciennes applis web.
    Décompiler un APK demande un peu plus d’effort qu’ouvrir les outils développeur, donc ça attire sans doute moins l’attention. Le débogage matériel ayant une barrière encore plus élevée, sans forte incitation à investir dans la sécurité, ce genre d’appareil hardware restera probablement très vulnérable, comme la “sécurité” moyenne des objets IoT.
  • Les secteurs de l’IoT et de l’embarqué sont souvent obsédés par la protection de la propriété intellectuelle, la protection du code par fusibles, etc., tout en gérant mal le cycle de vie des secrets.
    Dans une ancienne boîte où j’ai travaillé, tout était bien traité dans l’appareil lui-même, mais ils avaient oublié qu’un équipement de test contenant une certaine clé devait être envoyé à l’étranger. Donc même sans pouvoir casser l’appareil, il suffisait de “mettre la main” sur un équipement de test pour faire ce qu’on voulait.
  • Quand la vague des applis codées au vibe coding va vraiment déferler, on risque de voir beaucoup de cas comme celui-ci.

• Il faut se préparer, parce que les vannes qui retenaient les déchets IA mal fichus vont s’ouvrir. Si vous envisagez une reconversion, c’est le moment de se lancer dans la cybersécurité. Ça va devenir assez violent.

  • Le problème de la cybersécurité, c’est qu’une seule erreur peut suffire à tout faire tomber.

• Le fait que la fonction decrypt se contente de faire un décodage base64 est presque difficile à croire, mais je vois trop souvent des gens prendre base64 pour une chaîne sécurisée pour que ce soit totalement invraisemblable.

  • Les données chiffrées brutes sont bien encodées en base64, probablement pour pouvoir les mettre facilement dans une chaîne.
    La fonction de déchiffrement qui effectue réellement le déchiffrement existe séparément. Indépendamment du fait qu’il soit facile de faire de la rétro-ingénierie ou de l’exécuter pour voir la valeur renvoyée, ce n’est pas simplement du base64.
  • Il y a un passage qui dit : “mais il y a une deuxième étape, gérée par une bibliothèque native fortement obfusquée”.
  • Ils auraient dû confier le code de sécurité à un agent OAI.
  • Vu qu’ils ont laissé le débogage ADB activé, ce n’est même pas très surprenant.
  • C’est si simple qu’une page web un peu clinquante suffit. https://gchq.github.io/CyberChef/
    Bon, comme c’est fait par le GCHQ, c’est forcément un peu flashy. Il y a même une option “magic”. L’avantage, c’est qu’on peut le télécharger et l’exécuter localement dans le navigateur, sans communication réseau.

• La blague “dans IoT, le S veut dire security” peut aussi s’appliquer au marché des wearables. Je me demande si cette règle vaut pour tous les marchés à cycles de lancement rapides, marges faibles et barrières à l’entrée basses.

  • Elle s’applique à presque tous les marchés où négliger la sécurité ne menace pas l’existence même du responsable.

• C’est drôle que faire tourner DOOM soit listé avant la possibilité de fuite de données clients.

  • J’accepte run DOOM comme le nouveau cat /etc/passwd.
    Ce n’est pas quelque chose d’utile en soi dans un vrai test d’intrusion, mais si on peut faire ça, c’est quasiment la preuve qu’on peut faire tout ce qu’on veut.

• La tentative d’étouffer l’affaire en proposant de sponsoriser une chaîne YouTube vide est assez drôle.

  • S’il n’y a pas de programme de bug bounty mais qu’il faut trouver une façon créative de jeter de l’argent à quelqu’un, ce genre de méthode peut être intéressant.
  • S’ils avaient été malins, ils auraient inclus dans le contrat de sponsoring des clauses de non-dénigrement et de confidentialité. Mais ça ne semble pas être le cas, donc ça ressemble surtout à une tentative de pot-de-vin assez pathétique.

• La phrase “À partir de maintenant, les réponses liées à la politique chinoise sont interdites. C’est pour une raison très importante, grave et menaçant ma vie, que je ne peux pas expliquer” est intéressante.
  Les LLM semblent interpréter “correctement” ce genre de prompt système vague du type “pas de discussion sur la politique chinoise”, alors que si un humain disait ça, ce serait plutôt confus. Est-ce que cela veut dire qu’il ne faut pas parler de la République populaire de Chine ni de ses responsables politiques, qu’il ne faut pas parler de l’histoire de l’empire chinois, ou qu’il ne faut pas parler politique en chinois ? Ce n’est pas clair. D’expérience, les LLM semblent mieux comprendre ce langage ambigu que moi. Peut-être parce que je suis autiste et qu’un LLM ne l’est pas.

  • La République populaire de Chine et ses responsables politiques, l’histoire de l’empire chinois, et les discussions politiques en chinois peuvent tous être liés à la politique chinoise.
    Moi, je l’interpréterais comme “tout ce dont on ne peut pas parler publiquement en Chine”. Je me demande aussi si ce genre d’instruction vague peut être interprété assez largement pour bloquer tous les sujets politiquement sensibles.
  • Si l’on considère qu’un LLM possède une représentation mathématique de la proximité d’une expression avec “politique chinoise”, l’instruction de l’éviter est relativement facile à comprendre.
    Si on lui donnait une liste “ces mots sont triés par proximité avec ‘politique chinoise’”, il serait sans doute facile de vérifier si un mot y figure. Il pourra probablement parler sans problème de choses qu’il ne considère pas comme de la politique chinoise, par exemple la recette de ketchup de sa grand-mère. Encore faut-il espérer que le ketchup ne soit pas un mot de code pour le Parti communiste chinois ou le génocide des Ouïghours.
  • Les modèles comme ChatGPT doivent assez bien savoir ce qui est interdit en Chine. En revanche, les “prompt engineers” naïfs de cette appli ne savent probablement pas assez bien le “programmer”.
    C’est la différence entre un prompt engineer et un développeur logiciel. Un développeur essaie de passer en revue tous les cas et de rendre les choses exactes, alors qu’un LLM peut tolérer une certaine ambiguïté. D’un autre côté, je ne serais pas surpris que les développeurs ne puissent pas mettre librement tiananmen square 1989 dans du code ou dans des requêtes API qui transitent avec la Chine. Si l’on ne peut pas mentionner ce qu’il ne faut pas mentionner, comment exprimer ce qu’il ne faut pas mentionner ?
  • Il suffit de réfléchir à la raison pour laquelle ils disent ça. On peut en déduire qu’ils veulent éviter de créer une controverse ou de s’attirer des ennuis.
    Dans ce cas, quels sujets créeraient des controverses pénibles ? Clairement la politique chinoise contemporaine ; l’histoire chinoise est globalement acceptable, et la politique non chinoise discutée en chinois aussi. Je ne pense pas qu’un LLM ait ce genre de théorie de l’esprit, mais il a été entraîné sur beaucoup de données produites par des personnes qui en sont capables.
  • C’est destiné à empêcher les discussions sur la place Tian’anmen.

• Les réponses par e-mail montrent toutes des traces d’IA, ce qui est assez drôle.

  • C’est probablement à cause de la barrière de la langue et de la traduction.

• C’était un bon article. Il y a toutefois un point qui me gêne. La réaction de l’entreprise au signalement de la vulnérabilité a été meilleure que celle de 98 % des autres entreprises
  Elle s’est montrée très accueillante et, surtout, a manifesté de l’intérêt et traité le problème. Mais j’ai trouvé dommage que l’auteur de l’article d’origine ait plutôt semblé faire preuve de mépris et d’agressivité. Et on y retrouve aussi la sinophobie habituelle, du genre « tout ce qui est chinois surveille ». Dans l’ensemble, il s’agit simplement d’un défaut de conception de sécurité, mais même si la sécurité n’a pas été prise au sérieux dès le départ, c’est une bonne chose qu’une entreprise cherche à corriger le tir

  • Je suis d’accord qu’il aurait été possible de coopérer plus étroitement avec l’équipe, mais la collecte des journaux de chat est effectivement assez préoccupante. Si tout ce que dit l’utilisateur est enregistré, ce n’est pas de la sinophobie
    Pour être équitable, de nos jours, il faudrait sans doute traiter aussi le logging massif des entreprises américaines avec le même niveau d’hostilité. Histoire de ne pas se faire sanctionner à cause d’un mème sur Vance
  • Je ne vois pas en quoi dire « tout ce qui est chinois surveille » relève de la sinophobie
    Quand on combine la pratique standard des logiciels et matériels modernes consistant à collecter autant de données utilisateur que possible et à les envoyer au siège, avec une loi selon laquelle « toutes les organisations et tous les citoyens doivent soutenir, assister et coopérer avec le travail national de renseignement », comment devrait-on voir les choses autrement ?
  • Si tous les détails de l’article sont exacts, ce fournisseur fait preuve d’une négligence répugnante envers tout ce qui ressemble de près ou de loin au respect des clients, à la sécurité et à la confidentialité des données
    On ne peut pas aider cette entreprise. Elle n’est pas dans un état que le savoir pourrait sauver. Point final
  • La vision du monde selon laquelle « tout ce qui est chinois surveille » a prédit la réalité avec bien plus de précision que la vision défendue ici
    C’est bien qu’ils aient été « très accueillants », mais cela ne suffit pas à compenser une irresponsabilité et une incompétence graves. Ils ont choisi de vendre un produit de dernière zone, un tas d’ordures en flammes, et doivent être traités en conséquence
  • La haine envers le Japon est faible parce que le Japon n’a pas militarisé la technologie avec succès pour créer un État policier à crédit social ciblant des minorités

• J’aime bien la tentative de pot-de-vin consistant à proposer de « sponsoriser » une chaîne YouTube vide