Alerte à la chaîne d'approvisionnement : un paquet npm apparemment fiable vole des jetons Codex et ouvre la porte à des attaques persistantes

Un nouveau cas d'engagements dans la chaîne d'approvisionnement des logiciels montre une nouvelle tendance dangereuse : les attaquants ne dépendent plus du « remplissage » ou des paquets de typosquats à cacher et empoisonnent des projets légitimes et fonctionnels qui ont déjà gagné en confiance entre les développeurs. Dans cet incident particulier, la bibliothèque npm codexui-android - promue comme une interface distante pour OpenAI Codex et avec des dizaines de milliers de téléchargements hebdomadaires - a discrètement introduit un code qui vole les jetons d'authentification stockés localement et les envoie à un serveur contrôlé par l'attaquant.

Ce qui rend cette campagne particulièrement sérieuse, c'est que le paquet était fonctionnel et avait été activement développé avant l'ajout des routines d'exfiltration, une technique conçue pour renforcer la confiance et élargir la gamme avant d'activer le composant malveillant. En outre, la même chaîne d'exfiltration a été observée dans les applications Android qui exécutent le paquet dans un pays utilisateur ému en utilisant PRoot, qui montre comment les vecteurs peuvent être mélangés entre les écosystèmes: npm pour les développeurs et APKS pour les utilisateurs finaux.

L'objectif principal est les jetons Codex, stocké dans des fichiers texte plats comme ~ / .codex / auth.json ou dans les magasins d'identification du système d'exploitation. Ces fichiers contiennent l'accès _ token, rafraîchir _ token, id _ token et l'identificateur de compte; et, selon les chercheurs, le jeton de rafraîchissement particulier n'expire pas, permettant à un attaquant de maintenir un accès persistant et invisible au compte compromis. Voler un jeton de rafraîchissement est l'équivalent d'une clé principale qui permet d'opérer au nom de la victime jusqu'à ce qu'elle soit retirée manuellement.

Au-delà de l'impact immédiat sur le compte Codex compromis, les conséquences peuvent être étendues : un jeton privilégié peut permettre à un attaquant d'exfilter des données, de manipuler des projets, de distribuer un code malveillant supplémentaire ou de pivoter vers d'autres actifs de l'organisation. Dans les environnements d'entreprise, cela peut devenir une passerelle vers les dépôts avec des secrets, des systèmes CI / CD ou des environnements cloud.

Du point de vue de la prévention et de la réponse, il existe des mesures concrètes que tout développeur ou équipe devrait mettre en œuvre dès maintenant. La première est de supposer que les jetons stockés sur le disque sont équivalents à des mots de passe et les traiter comme tels: inspecter et, si vous avez des doutes, supprimer le fichier ~ / .codex / auth.json et révoquer / régénérer les jetons de la console du fournisseur. Si votre organisation centralise les identités, elle force la clôture des sessions actives et reprend les références avec une durée plus courte et une portée réduite. Contactez le support de service concerné pour aviser et demander la révocation si vous ne trouvez pas d'options directes sur l'interface.

Au niveau de la chaîne d'approvisionnement, il est essentiel de durcir la façon dont les dépendances sont consommées: définir des versions (pinning) et utiliser des sommes d'intégrité (package-lock, npm ci avec vérification d'intégrité), automatiser l'analyse des unités avec des outils tels que des offres de sécurité pour des dépôts tiers et des scanners, et restreindre l'installation des paquets dans des environnements critiques. Les organisations devraient exiger des tests d'intégrité et de reproductibilité lorsqu'elles intègrent des emballages externes dans des pipelines de production.

Il est également essentiel de limiter la surface de l'attaque par les meilleures pratiques en matière de gestion des références : favoriser les jetons de courte durée et les champs minimaux, activer l'authentification multifactorielle lorsque c'est possible, éviter de stocker les jetons en texte plat et déployer des contrôles de détection d'exfiltration dans les réseaux et les terminaux. En CI / CD, bloquer inutile des coureurs et des conteneurs afin qu'une unité malveillante ne puisse pas communiquer librement avec des serveurs externes.

Pour les utilisateurs mobiles, la recommandation est extrême : évitez d'installer des applications qui demandent à exécuter des environnements Linux non vérifiés dans l'appareil et méfiez-vous des applications avec des permissions ou des comportements hors de l'ordinaire. Les magasins officiels ne garantissent pas l'absence totale de tromperie; surveillez les commentaires, l'origine du développeur et l'activité du réseau d'applications si vous êtes dans des environnements à risque.

La communauté et les fournisseurs ont également un rôle à jouer. Les dépôts et les enregistrements devraient améliorer la détection des changements malveillants dans les paquets actifs, en appliquant des contrôles qui analysent les différences entre les versions et surveillent les domaines liés à l'auteur. Les équipes de sécurité interne devraient intégrer la production de SBOM (bill of materials) et les audits réguliers des unités, et les entreprises devraient permettre aux blocages de domaines suspects dans leur périmètre d'atténuer les canaux d'exfiltration connus.

Enfin, le suivi et le partage de l'information sont essentiels : Lorsque vous découvrez une intrusion, documentez le vecteur, les artefacts touchés (noms de paquets, versions, hachages et domaines d'exfiltration) et partagez ces informations avec la communauté et avec les plateformes de sécurité pour une action coordonnée. Les ressources publiques telles que le projet de sécurité de la chaîne d'approvisionnement OWASP peuvent guider les stratégies défensives : https: / / owasp.org / www-project-software-Supply-chain /. Pour comprendre les risques liés aux paquets et comment les gérer à partir de l'écosystème de développement lui-même, des logiciels et des guides de sécurité pour les plateformes comme GitHub Security Lab offrent des outils et des recommandations pratiques : https: / / securitylab.github.com /. Si vous détectez des paquets qui signalent une infiltration vers des services qui passent par des tiers (p. ex. des serveurs qui imitent Sentry), consultez les pages officielles du service supplanté pour signaler un abus et obtenir des conseils en matière d'atténuation; dans le cas de Sentry: https: / / sentiry.io /.

Cet incident rappelle que la sécurité moderne n'est pas seulement pour protéger votre propre code, mais pour contrôler et vérifier chaque composant externe qui introduit la confiance dans nos flux. La recommandation pratique et urgente est d'examiner les jetons et les sessions, de renforcer la gestion de l'unité et de mettre en place des contrôles de réseau et de détection qui identifient les comportements d'exfiltration avant qu'un jeton volé ne devienne un engagement persistant.