Des chercheurs en sécurité viennent de révéler une vaste campagne de compromission touchant le registre npm. Derrière des modules à l’apparence ordinaire, des opérateurs tentent de récupérer des jetons GitHub et d’autres secrets accessibles depuis les postes de développement.
L’alerte a été donnée fin octobre, lorsque Koi Security a détaillé une série de paquets npm frauduleux diffusés depuis août au fil de publications espacées. Rien, dans leur présentation, ne laissait penser à une opération malveillante. Pourtant, ces modules ont été conçus pour capter jetons d’accès, identifiants et éléments d’environnement susceptibles d’ouvrir une brèche dans les chaînes de développement. La campagne, baptisée PhantomRaven, repose sur un usage détourné des dépendances distantes pour contourner l’analyse statique et déployer une charge malveillante adaptée à chaque contexte.
Offre partenaire
Protection avancée des e-mails, des calendriers, des mots de passe, du réseau… de votre entreprise grâce à la suite d'applications professionnelles sécurisées.
Offre partenaire
Le subterfuge de la dépendance distante
Au total, 126 bibliothèques ont été identifiées, cumulant plus de 86 000 installations, certaines n’ayant enregistré que quelques centaines de téléchargements, d’autres ayant circulé plus largement. Évidemment, toutes adoptent des noms suffisamment crédibles pour passer inaperçues. On y croise notamment op-cli-installer, unused-imports, badgekit-api-client, polyfill-corejs3 ou eslint-comments. Une nomenclature qui profite de l’essor des recommandations automatisées et surfe même sur un phénomène connu des équipes de sécurité, à savoir la génération de références plausibles par certains outils d’assistance… mais inexistantes.
L’appât démontre déjà une approche particulièrement retorse, mais le caractère le plus problématique de l’opération tient au fait que ces modules ne contiennent aucun élément suspect susceptible de faire tiquer les outils d’analyse. Ce n’est qu’une fois ajoutés au projet que leur script d’installation se déclenche, contacte une URL extérieure contrôlée par l’attaquant, récupère une dépendance dynamique contenant le code malveillant et l’exécute localement. Or, comme cette ressource n’apparaît pas dans la déclaration du module, les contrôles de routine perçoivent le paquet comme dépourvu de dépendance et passent ainsi à côté de la manœuvre frauduleuse.
Outre le fait d’échapper aux analyses automatisées, cette technique permet aux opérateurs de modifier à la volée le fichier servi par l’URL. Ils peuvent d’abord fournir un code neutre pour asseoir la crédibilité du module, puis, une fois le paquet suffisamment répandu, remplacer la ressource par une version plus agressive de la charge utile, qui inventorie l’environnement pour siphonner adresses mail, configuration de la chaîne CI/CD, empreinte système, adresse IP publique et, lorsque présents, jetons GitHub et autres secrets locaux, avant de tout exfiltrer vers une infrastructure contrôlée par les attaquants.
Face à PhantomRaven, limiter la portée du risque
Fin octobre, au moment où Koi Security alertait sur la campagne, près de quatre-vingts modules supplémentaires avaient encore été publiés depuis la rentrée. Autrement dit, la diffusion s’est poursuivie plusieurs semaines avant d’être pleinement documentée. Par conséquent, vous pouvez commencer par vérifier quels jetons d’accès ont circulé sur les machines possiblement compromises, révoquer ceux qui n’ont plus lieu d’être, resserrer leurs permissions et en programmer le renouvellement régulier. Un examen de l’activité récente sur GitHub peut également révéler des connexions ou des opérations inhabituelles.
Limiter l’exécution automatique des scripts lors de l’installation réduit ensuite la possibilité de voir du code extérieur s’inviter sans préavis. Vous pouvez, lorsque cela s’y prête, vous appuyer sur des installations reproductibles à partir d’un fichier de verrouillage validé, ce qui aide à garder la main sur les dépendances réellement sollicitées, au prix d’un suivi un peu plus attentif des mises à jour.
L’examen des bibliothèques gagne lui aussi à être plus systématique. S’assurer qu’un module dispose d’une source identifiée, d’un entretien visible et de mises à jour cohérentes permet déjà d’écarter une bonne partie des ajouts douteux. Pour les cas plus sensibles, installer la bibliothèque dans un environnement isolé permet d’observer son comportement réseau et de repérer une récupération de ressource extérieure qui n’apparaît nulle part dans la configuration du projet.
Reste enfin la gestion des secrets. Conserver des jetons longue durée sur vos postes de développement multiplie les points d’exposition. Les espaces dédiés proposés par les outils d’intégration facilitent leur stockage, réduisent la portée des identifiants et encouragent l’usage de clés à durée de vie plus courte. Plus largement, vous interroger sur l’origine et l’utilité réelle d’une nouvelle bibliothèque constitue déjà un réflexe efficace, sans alourdir le travail quotidien.
Source : Koi Security
