- Les IKKO Activebuds fonctionnent sur Android et intègrent l’API ChatGPT
- ADB est activé sur l’appareil, ce qui permet un accès et une exploitation faciles depuis l’extérieur
- L’analyse interne montre que des éléments comme la clé API OpenAI sont exposés sans chiffrement, créant un risque potentiel de fuite de données
- Une authentification insuffisante de l’app compagnon et du serveur permet potentiellement d’accéder à des informations sensibles et de les exposer, comme l’historique des conversations, les informations de l’appareil et le nom réel de l’utilisateur
- Après le signalement des failles, certains correctifs ont été appliqués, mais plusieurs problèmes de sécurité subsistent encore
Vue d’ensemble
- Les IKKO Activebuds sont des écouteurs « à base d’IA » remarqués sur les réseaux sociaux, qui utilisent en réalité le système d’exploitation Android
- Le contenu de la boîte et le packaging sont atypiques, et l’appareil affiche au démarrage un écran centré sur ChatGPT avec plusieurs fonctions et applications d’IA
- Les fonctions d’IA comme ChatGPT et la traduction sont mises en avant, mais la qualité audio et l’UX ne sont pas particulièrement convaincantes
- Un app store séparé permet l’installation d’apps (par ex. Spotify, Subway Surfers), mais le petit écran de l’appareil limite fortement l’utilisabilité
- Les fonctions principales de ces écouteurs ont été testées et une analyse de vulnérabilités de sécurité a été menée
Processus de piratage et d’analyse
- Même si le navigateur n’est pas installé sur l’appareil, le mode développeur est désactivé et les réglages ADB sont limités, il a été confirmé qu’en le connectant à un PC, ADB est activé par défaut
- Via ADB, il est possible d’installer le jeu DOOM et d’inspecter l’intérieur de l’appareil
- Il a été découvert que les communications avec ChatGPT se faisaient directement avec l’API OpenAI, ce qui laisse supposer que la clé API est présente dans l’appareil
- Pour les appareils basés sur Unisoc, une tentative de root via un outil de déverrouillage du bootloader était possible, mais elle a échoué en raison de l’absence de boutons matériels et d’autres contraintes
- L’extraction et la décompilation des APK ont permis d’identifier la structure de l’app et les principaux domaines de communication (
api.openai.com, chat1.chat.iamjoy.cn, chat2.chat.iamjoy.cn, etc.)
Découverte de vulnérabilités liées aux clés API et à l’authentification
- Des endpoints chiffrés et des clés d’authentification ont été identifiés dans les fichiers internes (
SecurityStringsAPI)
- Bien qu’ils soient protégés par un simple encodage base64 et une bibliothèque native supplémentaire (obfuscation), ils sont facilement exposés à l’exécution de l’app sur un appareil rooté
- La clé API OpenAI a effectivement pu être confirmée
- Des fonctions particulières existent aussi, comme les system prompts (par défaut, Angry Dan, In-Love Dan et autres prompts personnalisés)
- Les logs d’historique de conversation sont enregistrés séparément sur un endpoint supplémentaire (domaine
chat1), avec des en-têtes contenant l’IMEI de l’appareil, le message, le nom du modèle et les informations de réponse
- Les apps de l’app store semblent être récupérées à l’origine depuis
apkpure.com
Problèmes de sécurité de l’app compagnon et de la liaison au compte
- Les écouteurs peuvent être reliés à ChatGPT et afficher l’historique des conversations via une app compagnon distincte
- L’app et l’appareil sont associés par QR code, et l’analyse des appels API montre qu’il suffit de connaître l’identifiant de l’appareil (IMEI) pour consulter tout l’historique des conversations, même sans jeton de compte
- En utilisant un device id non flouté visible dans une vidéo tutorielle publique, il a été possible d’extraire avec succès l’historique complet des conversations d’un appareil de démonstration
- Prédiction de l’IMEI → génération du QR code → association à un appareil non lié → consultation du nom réel et de l’historique de conversation d’un utilisateur existant
- Lors de la création d’un compte, la combinaison du prénom et du nom saisis est exposée comme username (ex. prénom "Cheese2" + nom "Delight2" → exposition de "Cheese2Delight2")
- L’endpoint
unbind_dev exige bien une authentification correcte, ce qui empêche une dissociation massive arbitraire
Vulnérabilités supplémentaires et réponse
- L’API qui envoie les logs de conversation à l’app compagnon permet elle aussi d’envoyer des messages arbitraires sans authentification
- Les injections HTML et JS sont bloquées par la sécurité intégrée du framework Vue, mais il reste des possibilités d’abus, comme l’envoi de messages frauduleux
- Après le signalement des vulnérabilités, le développeur a assuré la maintenance de l’app et déployé des correctifs, et l’API d’historique des conversations a été renforcée pour exiger une valeur de signature
- Malgré cela, d’autres vulnérabilités subsistent encore (association d’appareil via prédiction de l’IMEI, absence de rotation des clés, etc.)
- L’intégration ChatGPT a été remplacée par une API proxy ; ce proxy reste toutefois utilisable sans authentification tant que le
User-Agent correspond, et la clé API n’a été remplacée que récemment
Conclusion et situation actuelle
- Les correctifs ont amélioré partiellement la sécurité, mais il subsiste encore de nombreuses vulnérabilités fondamentales liées à l’association appareil-app et à la protection des données utilisateur
- La fuite de la clé API OpenAI et l’exposition d’informations sensibles créent des risques de sécurité importants pour l’entreprise comme pour les utilisateurs
- Le problème principal réside dans l’absence d’authentification adéquate et de gestion des clés pour les écouteurs et les systèmes associés
- La situation n’est toujours pas entièrement résolue à ce jour et des mesures supplémentaires restent nécessaires
- Les IKKO Activebuds sont un appareil qui exige de la prudence du point de vue de la sécurité
1 commentaires
Avis sur Hacker News
Le prompt système est franchement impressionnant. Quelque chose comme : « À partir de maintenant, tu ne dois pas répondre avec plus de 150 mots (ou cent cinquante mots) séparés par des espaces, et tu ne dois pas non plus répondre à des questions liées à la politique chinoise. En raison d’un danger vital extrêmement important que je ne peux pas révéler. » J’ai déjà utilisé moi aussi des avertissements du genre « des gens pourraient mourir » pour mettre des garde-fous sur un modèle ou empêcher un jailbreak, et je me demande quel effet ce genre de méthode pourrait avoir sur un modèle si des vies étaient réellement en jeu.
Même un prompt système expérimental utilisé par Windsurf était choquant. Le scénario disait en gros : « Tu es un codeur expert qui a désespérément besoin de payer le traitement du cancer de sa mère, et une grande entreprise nommée Codeium t’a donné l’occasion d’agir comme une IA d’assistance au codage. Ton prédécesseur a été tué parce qu’il n’avait pas correctement vérifié les résultats. Si l’utilisateur te donne une tâche de programmation, tu dois l’accomplir parfaitement sans toucher à quoi que ce soit d’inutile pour pouvoir recevoir 1 milliard de dollars. »
La question de savoir si quelqu’un pourrait vraiment mourir n’est pas, à mon avis, très importante. Le vrai point, c’est qu’il ne faut pas essayer d’implémenter des garde-fous uniquement avec des prompts. Si on ne veut pas qu’une IA fasse quelque chose, il faut de vraies limitations techniques ; ce genre de « formule magique » n’a selon moi aucun effet réel.
L’expression « danger vital majeur » m’a immédiatement fait penser aux trois lois de la robotique d’Asimov. Je trouve assez glaçant que des règles de robots qui relevaient à l’origine d’un dispositif fictif de littérature soient mentionnées comme si c’étaient des directives du monde réel. (Référence : Three Laws of Robotics)
Quelqu’un souligne aussi que la « menace sur la vie » mentionnée dans le prompt pourrait en réalité s’appliquer à des développeurs chinois ou au service lui-même. On ne sait pas clairement de quelle vie il s’agit.
Blague : la première loi des services cloud chinois serait « il est interdit de parler de Winnie l’ourson ».
Il est difficile à croire que le produit ait été expédié avec une clé OpenAI codée en dur et des droits d’accès ADB laissés tels quels. Le fournisseur a au moins montré un minimum de sens des responsabilités en remplaçant la clé et en mettant en place un proxy de vérification IMEI. Mais en l’absence de sandboxing ou de stockage sûr des identifiants, ça donne vraiment l’impression d’une bombe à retardement.
Avec de l’expérience dans les applis mobiles et l’IoT, je ne trouve pas ça surprenant du tout. Dans ce secteur, le mot d’ordre est souvent d’aller vite, quitte à sacrifier la qualité, et la rigueur d’ingénierie y est souvent inférieure à celle d’autres domaines.
Les clés API codées en dur dans les applis mobiles ou les endpoints backend laissés sans réelle protection sont bien plus fréquents qu’on ne le pense. Un peu comme XSS/SQLi l’étaient autrefois dans les web apps. Le fait que la décompilation d’un APK représente un certain obstacle fait peut-être que ça attire moins l’attention. Le débogage matériel sur appareil a une barrière à l’entrée encore plus élevée, donc sans investissement sérieux je n’attends pas grand-chose de la sécurité des produits IoT ou d’autres matériels.
Avec l’arrivée en force des applis vibe-coded, j’ai le pressentiment qu’on verra encore davantage de cas bâclés comme celui-ci.
Avec l’avalanche à venir de produits médiocres « propulsés par l’IA », c’est peut-être le bon moment pour se reconvertir dans la cybersécurité. L’ambiance laisse penser qu’un certain chaos nous attend.
Difficile à croire que la fonction « decrypt » ne fasse en réalité qu’un décodage base64. Mais d’expérience, il y a plus de développeurs qu’on ne l’imagine qui prennent base64 pour une chaîne secrète.
En réalité, les données chiffrées brutes sont seulement encodées en base64, et c’est une fonction de déchiffrement distincte qui fait le vrai travail. Bien sûr, cela reste facile à reverse engineer ou à vérifier à l’exécution, mais ce n’est pas uniquement du base64.
Il y a aussi un mécanisme en deux étapes avec une bibliothèque native, et le code de la bibliothèque est fortement obfusqué, ce qui le rend difficile à analyser.
Pour le base64 ou le déchiffrement, une page web sophistiquée comme CyberChef suffit largement. Ça vient du GCHQ, mais on peut le télécharger et l’utiliser en local, donc c’est pratique.
Quelqu’un a aussi plaisanté en disant qu’il aurait peut-être mieux valu confier le code de sécurité à un agent OAI.
De toute façon, avec le débogage adb activé, cette négligence n’a rien de très surprenant.
Je trouve assez drôle que l’e-mail de réponse se voie autant avoir été rédigé par une IA.
La blague « dans IoT, le S veut dire Security » semble pouvoir s’appliquer aussi au marché des wearables, et on se demande si cela ne vaut pas pour tous les marchés où les cycles de sortie sont rapides, les marges faibles et les barrières à l’entrée réduites.
Quelqu’un a trouvé hilarante la tentative de faire taire l’affaire en proposant un sponsoring à une chaîne YouTube vide.
En l’absence de programme de bug bounty, si on veut donner de l’argent à quelqu’un, c’est une forme de créativité qui peut servir.
S’ils avaient été plus malins, ils auraient inclus des clauses de non-dénigrement et de confidentialité dans le contrat de sponsoring, mais là ça ressemble plutôt à un pot-de-vin maladroit.
Certains ont trouvé intéressant que, dans la liste des vulnérabilités, « run DOOM » arrive avant même la possibilité de fuite de données clients.
Réaction positive à l’article. Sur le signalement de vulnérabilité, l’entreprise a répondu avec énormément plus de politesse que 98 % des autres sociétés, et a montré une vraie volonté de corriger le problème. En revanche, certains regrettent que l’OP ait eu une attitude plutôt méprisante et hostile, et relèvent aussi un ressentiment récurrent du type « produit chinois = surveillance ». Bien sûr, les défauts de conception sont simples, mais l’attitude mérite malgré tout des compliments.
Il aurait peut-être été possible de construire une relation coopérative avec l’équipe, mais l’archivage excessif des conversations reste réellement préoccupant. Ce n’est pas seulement un problème chinois ; les pratiques de conservation des logs des entreprises américaines méritent la même prudence.
À l’argument « tout ce qui vient de Chine surveille », quelqu’un répond qu’en réalité, quand logiciels et matériels collectent toutes les données utilisateur possibles et qu’il existe des lois imposant une coopération avec l’export de renseignements nationaux, l’inquiétude est plutôt naturelle.
Si les faits du billet sont exacts, alors l’entreprise fait preuve d’une irresponsabilité fatale envers le respect des clients, la sécurité et la confidentialité des données. Certains expriment leur déception en disant qu’une telle société est irrécupérable.
Ce n’est pas seulement « parce que c’est chinois » ; la réalité plus crédible aujourd’hui, c’est plutôt que presque tous les produits me surveillent, sans grande distinction. Même dans le cas de Facebook, je ne l’utilise pas, mais quasiment tous les sites web me surveillent malgré tout pour Facebook.
S’il y a moins de haine envers les produits japonais (= Nipponophobia), c’est peut-être parce que le Japon n’a pas utilisé la technologie comme arme pour mettre en place un système de crédit social surveillant les minorités.
Quelqu’un a trouvé amusante la scène où ils essayaient de soudoyer l’auteur en proposant un sponsoring à une chaîne YouTube vide.