La chaîne d'approvisionnement du logiciel d'avertissement: les paquets dYdX engagés volent les identifiants et permettent l'accès à distance

La communauté de la sécurité vient d'identifier un nouvel incident qui ramène une menace connue mais de plus en plus sophistiquée : la chaîne d'approvisionnement du logiciel. Les chercheurs de Socket ont détecté que des versions malveillantes de paquets légitimes publiés dans npm et PyPI ont été distribuées pour voler les identifiants des portefeuilles de cryptomoneda et, dans le cas de Python, obtenir même un accès à distance aux systèmes touchés. Vous pouvez lire l'analyse technique dans le rapport original de Socket ici: Socket: Malicieux dYdX paquets publiés à npm et PyPI.

Les paquets compromis servent les développeurs qui intègrent les fonctionnalités du protocole dYdX, une plate-forme décentralisée pour l'échange dérivé et les opérations cryptoactives. Dans npm les noms affectés sont @ dydxprotocol / v4-client-js, avec plusieurs versions malveillantes détectées ; dans PyPI le paquet affecté est dydx-v4-client dans une version post-publiée. dYdX a confirmé l'incident dans une série de messages publics et a recommandé que les utilisateurs aient téléchargé ces versions pour isoler l'équipement, déplacer les fonds d'un système propre et faire pivoter les clés et les références. La publication dYdX originale est disponible sur X (avant Twitter): dYdX: communiqué.

Selon l'analyse, l'attaquant n'a pas exploité une vulnérabilité technique des dépôts, mais publié de nouvelles versions avec des références de publication légitimes, ce qui indique que engagement de comptes de maintenance. L'acteur malveillant a introduit le code dans les fichiers centraux du paquet (par exemple, les fichiers de log et de compte), de sorte que la charge nuisible a été exécutée pendant l'utilisation habituelle de la librairie. Cela montre une connaissance approfondie de la structure interne des paquets et de la façon dont ils sont intégrés dans des applications qui manipulent les fonds et les clés.

La charge utile de l'écosystème JavaScript est destinée à l'exfiltration : elle recueille des phrases de semences de portefeuilles et de données de périphériques pour les envoyer à un serveur contrôlé par l'attaquant. La variante Python ajoute un composant plus dangereux : un Trojan d'accès à distance (RAT) qui fonctionne lors de l'importation du paquet et qui consulte un serveur externe pour recevoir des commandes. En particulier, ce composant contacte un paramètre observé par les chercheurs et utilise les drapeaux du système d'exploitation - par exemple, le drapeau CRÉER _ AUCUNE _ POUVOIR dans Windows - à exécuter sans afficher les fenêtres et passer inaperçu. Socket et d'autres analystes ont également mis en évidence un degré élevé d'utilisation dans la version PyPI, suggérant l'intention de cacher l'activité malveillante et persistante.

Cet événement n'est pas né de nulle part : dYdX avait déjà été la cible d'attaques sur la chaîne d'approvisionnement dans le passé. En 2022, il a été signalé que les comptes npm liés à l'équipe ont été compromis et que des paquets ont été publiés qui ont volé des identifiants, et en 2024 le web associé à sa plateforme v3 a été manipulé pour rediriger les victimes vers un site d'hameçonnage. La récurrence de ces incidents montre que les acteurs malveillants voient les projets avec des composantes financières comme des objectifs de grande valeur et que les canaux de distribution fiables - dépôts officiels, comptes de maintenance - sont un vecteur très attrayant pour atteindre un grand impact avec peu de bruit. Sur l'incident de 2022 vous pouvez voir le fil dans GitHub et la couverture médiatique: Numéro GitHub et Ordinateur de brouillage.

En plus des attaques contre les paquets existants, les chercheurs mettent en garde contre une autre technique inquiétante: la publication de paquets "ghost" avec des noms mentionnés dans la documentation ou les scripts mais jamais publiés officiellement. Aikido a fait une étude sur ce phénomène et a constaté que des dizaines de paquets sans enregistrement préalable ont accumulé des centaines de milliers de téléchargements ces derniers mois, simplement parce que les utilisateurs ont exécuté des commandes npx qui ont tenté d'invoquer des noms non existants et, par conséquent, l'enregistrement a permis la création de paquets avec ces noms. L'analyse d'Aikido détaille le risque de « confusion npx » et énumère des exemples de paquets qui ont atteint des milliers de téléchargements; vous pouvez lire votre rapport ici: Aïkido: confusion NPX - noms de colis non réclamés.

Ce vecteur profite d'une configuration par défaut qui cherche à être pratique mais ouvre la porte à l'exécution de code à distance sans vérification explicite de l'utilisateur. Comme l'un des chercheurs l'a souligné, l'écosystème de npm a des millions de paquets et les développeurs exécutent des commandes npx très souvent; par conséquent, il y a un écart entre le confort et le risque réel d'exécuter le code arbitraire du réseau.

Face à ces problèmes, il existe à la fois des mesures immédiates pour les utilisateurs touchés et des pratiques préventives pour les développeurs et les organisations. dYdX a recommandé - et il est sage de répéter - que quiconque a installé les versions malveillantes isole l'ordinateur, arrête d'utiliser les clés dans cet environnement, déplace les fonds d'un système qui connaît propre et tourne toutes les clés et API clés. Au niveau de l'exploitation, Aikido et d'autres experts recommandent d'éviter que npx ne recule pour installer des paquets à partir du registre non vérifié: utilisez l'option npx --no-install empêche l'installation automatique et force la commande à échouer si elle n'existe pas localement. Il convient également d'installer explicitement les outils CLI qui sont souvent utilisés et de vérifier toujours l'existence et la réputation du paquet que la documentation suggère d'exécuter.

Pour les équipes de développement et les gestionnaires de projet, les pratiques d'atténuation comprennent l'obligation d'authentification multifacteurs pour les comptes de publication, la vérification et la minimisation des droits des clés de publication, les séances de clôture et les lettres de créance tournantes pour tout soupçon d'engagement, et le suivi de la chaîne de dépendances avec les outils d'analyse de la composition des logiciels. Conserver les fichiers de verrouillage (fichier de verrouillage) dans les dépôts, les versions de peinture, examiner les changements dans les dépendances transitoires et valider les signatures ou les montants de paquet si possible sont des mesures qui réduisent la surface de risque. En outre, l'enregistrement de variantes évidentes de noms de paquets ou d'alias peut être une barrière contre les acteurs opportunistes qui tentent de publier des paquets avec des noms confus.

Cet incident est un appel à l'attention: la confiance que nous mettons dans les dépôts centraux et les comptes de maintenance est un actif qui doit être pris en charge avec le même sérieux que les clés privées dans le monde critique. Les attaquants préfèrent « se déplacer en amont » parce que compromettre une seule identité d'édition peut affecter des milliers ou des millions d'utilisateurs à la fois, avec très peu de bruit dans les systèmes de détection conventionnels. Comme le résume une analyse sectorielle, la tendance est claire : tant les attaques dirigées contre des responsables spécifiques que les campagnes à grande échelle qui profitent des configurations par défaut sont en augmentation, et la défense exige simultanément des contrôles techniques, des processus organisationnels et une plus grande hygiène en compte et une gestion clé. Un bon résumé de l'évolution récente de ces menaces figure dans le rapport de Sygnia sur la chaîne d'approvisionnement : Sygnia: La chaîne d'approvisionnement attaque T4 2025.

Si vous travaillez sur des projets qui interagissent avec des signatures, des transactions ou des secrets de stockage liés à cryptoactive, rappelez-vous que l'exposition principale n'est pas toujours dans votre code: parfois c'est dans la chaîne qui apporte ce code à vos environnements. Vérifiez les dépendances critiques, protégez les comptes avec la capacité de publier, et lorsque l'outil à bord inclut l'exécution de commandes à distance, arrêtez un moment et vérifiez la source. La commodité est rentable si elle n'est pas accompagnée de contrôles de sécurité minimaux.

Pour plus de contexte et de lectures supplémentaires sur l'incident et les vecteurs impliqués, vérifiez la couverture technique dans Socket, la version dYdX, l'analyse d'Aikido et la couverture historique dans Bleeping Computer et GitHub liée au texte ci-dessus.