Les faux packages visent à voler des données, des informations d’identification et des secrets, et à infecter tous les packages créés à l’aide de ceux-ci, dans ce qui pourrait être « une prise de contrôle organisationnelle complète ».
Les développeurs d’applications sont avertis que des versions malveillantes de pgserve, un serveur PostgreSQL intégré pour le développement d’applications, et d’automagik, un outil de codage d’IA, ont été déposées dans le registre JavaScript npm, où elles pourraient empoisonner les ordinateurs des développeurs.
Le téléchargement et l’utilisation de ces versions entraîneront le vol de données, de jetons, de clés SSH, d’informations d’identification, y compris celles d’Amazon Web Services (AWS), de Microsoft Azure et de Google Cloud Platform (GCP), de pièces cryptographiques provenant des portefeuilles de navigateur et de mots de passe de navigateur. Le malware se propage également à d’autres PC connectés.
Les avertissements sont venus cette semaine de chercheurs de deux sociétés de sécurité.
Les chercheurs de Socket ont découvert de faux packages destinés aux développeurs d’applications à la recherche de pgserve, un serveur PostgreSQL intégré pour le développement et les tests d’applications, et d’automagik, une CLI de codage d’IA et d’orchestration d’agents de Namastex.ai. Les chercheurs ont déclaré que l’attaque présente des similitudes avec une campagne récente baptisée CanisterWorm, une attaque de chaîne d’approvisionnement utilisant un ver qui a remplacé le contenu de packages légitimes par des logiciels malveillants sur npm.
Au moment de l’examen de Socket, le faux package automagik/genie affichait 6 744 téléchargements hebdomadaires, et le faux package pgserve affichait environ 1 300 téléchargements hebdomadaires.
Les fausses versions d’automagik étaient les versions 4.260421.33 à 4.260421.39 lorsque Socket a publié son avis, et des versions malveillantes supplémentaires sont toujours publiées et identifiées. L’ensemble des versions concernées, des responsables ou des compromissions sur le chemin de publication est toujours à l’étude, ont indiqué les chercheurs.
Par ailleurs, les chercheurs de StepSecurity ont également trouvé des versions malveillantes de pgserve sur npm, notant que les versions compromises (1.1.11, 1.1.12 et 1.1.13) injectent un script de collecte d’informations d’identification de 1 143 lignes qui s’exécute via la post-installation à chaque installation.
La dernière version légitime de pgserve est la v1.1.10, selon StepSecurity.
StepSecurity a déclaré que, contrairement aux simples voleurs d’informations, ce malware est un ver de la chaîne d’approvisionnement : s’il trouve un jeton de publication npm sur la machine victime, il se réinjecte dans chaque paquet que ce jeton peut publier, propageant ainsi la compromission. Les données volées sont cryptées et exfiltrées vers une cartouche ICP (Internet Computer Protocol) décentralisée, un point de terminaison de calcul hébergé sur une blockchain choisi spécifiquement parce qu’il ne peut pas être supprimé par les forces de l’ordre ou par la saisie de domaine.
Encore une autre attaque contre la chaîne d’approvisionnement
Il ne s’agit là que du dernier exemple en date d’une attaque contre la chaîne d’approvisionnement logicielle, dans laquelle les acteurs malveillants espèrent que les développeurs téléchargeront des utilitaires et des outils infectés à partir d’un registre open source et les utiliseront dans des packages qui propageront largement le malware.
Dans l’un des exemples les plus récents, des pirates ont compromis le mois dernier le compte npm du principal responsable de la bibliothèque client HTTP Axios. Et l’été dernier, des attaquants ont compromis plusieurs utilitaires de test JavaScript sur npm.
Conseils aux développeurs victimes
Les développeurs qui ont téléchargé les versions malveillantes de pgserver et automagik doivent agir rapidement, déclare Tanya Janca, responsable du cabinet de conseil canadien en codage sécurisé SheHacksPurple.
« Faites pivoter tous les titres de compétences auxquels vous pouvez penser, dès maintenant, avant de faire quoi que ce soit d’autre », a-t-elle déclaré. « Ensuite, renforcez les contrôles de sortie de votre réseau CI/CD afin que vos exécuteurs de build ne puissent atteindre que les domaines dont ils ont explicitement besoin. Assurez-vous que vos exécuteurs de build et vos exécuteurs de déploiement utilisent des comptes de service distincts avec des autorisations distinctes. L’objectif est de garantir que même si un package malveillant s’exécute dans votre environnement de build, il ne peut pas atteindre l’infrastructure d’un attaquant (pour l’exfiltration de données et de secrets) et également l’empêcher de pivoter dans votre pipeline de déploiement. «
Pour éviter d’être compromis par un package npm malveillant, Janca a déclaré que les responsables informatiques devraient désactiver par défaut l’exécution automatique du script de post-installation.
Les développeurs doivent également exécuter cette commande immédiatement : . Certains paquets légitimes se briseront occasionnellement à cause de cela, a-t-elle admis. Mais l’objectif est de créer un point de friction intentionnel pour forcer les développeurs à décider consciemment qu’un script est ou n’est pas autorisé à s’exécuter sur leurs machines.
De plus, a-t-elle déclaré, les développeurs ont besoin d’outils qui vérifient si ce qui est publié sur npm correspond réellement à ce qui se trouve dans le référentiel source. « Tous les outils d’analyse de la composition logicielle ne font pas cela », a déclaré Janca, « demandez donc spécifiquement à votre fournisseur si l’outil détecte les inadéquations entre le registre et le dépôt. »
Enfin, a-t-elle conseillé, appliquez le principe du moindre privilège d’accès aux jetons de publication ; étendez-les étroitement, accordez-leur uniquement les autorisations dont ils ont besoin pour un package spécifique et faites-les alterner régulièrement – automatiquement et non manuellement.
Plus qu’un simple vol d’identifiants
« Les gens ont tendance à considérer cela comme un incident de vol d’identifiants », a déclaré Janca. « Il s’agit en fait d’une potentielle prise de contrôle organisationnelle complète, et elle peut se dérouler par étapes. Premièrement, l’attaquant obtient vos secrets lors de l’installation : clés AWS, jetons GitHub, clés SSH, mots de passe de base de données, tout ce qui se trouve dans votre environnement ou répertoire personnel. Deuxièmement, si vous disposez d’un jeton de publication npm, le ver l’utilise immédiatement pour s’injecter dans chaque package que vous pouvez publier, ce qui signifie que vos utilisateurs en aval sont désormais également des victimes. Troisièmement, ces informations d’identification cloud volées sont utilisées pour pivoter dans votre infrastructure : rotation des ressources, exfiltration des données, se déplaçant latéralement entre les comptes. Quatrièmement, vos pipelines CI/CD, qui font implicitement confiance à vos exécuteurs et à vos comptes de service, accueillent le code malveillant des attaquants en production.
Elle a souligné qu’il faut souvent beaucoup de temps aux développeurs pour remarquer des attaques de ce type, « et à ce moment-là, l’attaquant a potentiellement accès au code source, aux systèmes de production, aux données des clients et aux logiciels sur lesquels vos utilisateurs comptent ».
Changement de tactique
Janet Worthington, analyste principale de la sécurité et des risques chez Forrester Research, a déclaré que les attaques récentes telles que la campagne CanisterSprawl et la compromission des packages npm Namastex.ai montrent une évolution des acteurs malveillants vers des logiciels malveillants auto-propagés qui volent les informations d’identification et les utilisent pour infecter automatiquement d’autres packages.
« Ce comportement fait écho à des épidémies antérieures comme le ver Shai-Hulud, qui s’est propagé sur des centaines de paquets en récoltant des jetons npm et en republiant des versions trojanisées appartenant au mainteneur compromis », a-t-elle déclaré dans un e-mail.
Alors que les plateformes de registre ouvert comme npm introduisent des protections plus renforcées autour des comptes et des jetons des éditeurs, ces incidents mettent en évidence le fait que les compromissions ne sont plus limitées à un seul package malveillant, a-t-elle déclaré. Au lieu de cela, ils se répercutent rapidement dans un écosystème de registre et sautent même vers d’autres écosystèmes. « Les entreprises doivent s’assurer que seuls des composants open source et tiers approuvés sont utilisés en maintenant des registres organisés, en automatisant la SCA (analyse de la composition logicielle) dans les pipelines et en utilisant des pare-feu de dépendance pour limiter l’exposition et le rayon d’explosion », a déclaré Worthington.
Les développeurs se situent à l’intersection du code source, de l’infrastructure cloud, des pipelines CI/CD et des informations d’identification de publication, a souligné Janca, donc compromettre un développeur peut signifier compromettre chaque utilisateur de chaque package qu’il gère, voire une organisation entière. Cette attaque, et plusieurs autres au cours des derniers mois, s’attaquent également aux portefeuilles cryptographiques personnels ainsi qu’aux informations d’identification de l’entreprise. « Cela nous indique », a-t-elle déclaré, « que les attaquants comprennent exactement le type de personne qu’ils frappent et qu’ils optimisent le rendement maximal d’une seule attaque. »
