Changez chaque clé de CI utilisée le 4 août

Ce qui a été publié entre 09h35 et 11h44 UTC

La première publication empoisonnée était keyv en version 6.0.0, diffusée à 09h35 UTC le 4 août. Semgrep, qui a baptisé la campagne ChainDrop, a compté 1 557 versions malveillantes réparties sur 435 paquets lors de la vague suivante, entre 09h40 et 11h44 UTC. Wiz, qui suivait le même incident, est parvenue à plus de 400 paquets distincts et l'a rattaché à un compte de mainteneur dont les identifiants avaient été dérobés. Il ne s'agissait pas d'imitations aux noms voisins ni de nouveaux paquets. C'étaient les véritables bibliothèques, republiées sous le nom du véritable mainteneur, avec un fichier supplémentaire.

En une demi-heure la propagation a franchi les frontières entre organisations. Parmi les espaces touchés figurent @deliveroo, @ornikar, @qlik, @servicetitan, @onereach, @or-sdk, @arv-bedrock et @adminide-stack, ainsi que les familles keyv et cacheable elles-mêmes. Ces organisations ne partagent ni code ni propriétaire. Elles partageaient un jeton de publication volé : chaque infection récoltait les identifiants npm sur la machine qui installait le paquet, puis s'en servait pour republier tout ce que ce jeton pouvait atteindre. C'est ce qui en fait un ver et non une publication empoisonnée isolée.

Les porteurs sont des paquets que personne n'a choisis

Nous avons relevé les chiffres de téléchargement du registre npm pour les 30 jours achevés le 3 août, la veille de la compromission. keyv a réuni 619,7 millions de téléchargements. flat-cache 579,8 millions. file-entry-cache 571,2 millions. cacheable-request 137,0 millions, cacheable 30,1 millions et cache-manager 16,3 millions. Ces six bibliothèques totalisent environ 1,95 milliard de téléchargements dans le mois qui a précédé leur empoisonnement.

Presque personne n'installe flat-cache ou file-entry-cache délibérément. Ce sont des utilitaires de mémoire tampon qui arrivent sous les outils d'analyse et de compilation, plusieurs niveaux plus bas dans un arbre de dépendances, dans des projets dont les responsables n'ont jamais tapé ni l'un ni l'autre de ces noms. Voilà la part inconfortable du calcul. Les paquets au rayon d'action le plus large sont précisément ceux qui manquent à la liste de dépendances que vous avez examinée et approuvée, de sorte qu'auditer vos propres décisions ne dit presque rien de cet incident. Le chiffre qui prédit votre exposition est le nombre de fois où votre compilation a été lancée le 4 août.

Le code malveillant cherchait l'assistant d'intelligence artificielle

Le mécanisme était un point d'accroche preinstall, ce qui compte parce qu'il s'exécute pendant la résolution des dépendances et n'attend pas que votre code importe quoi que ce soit. Les fichiers de chargement, setup.mjs et math_init.js, téléchargeaient un environnement d'exécution Bun autonome et lançaient une deuxième étape obscurcie. Wiz a reconnu le trafic à son agent utilisateur, Bun/1.3.13. Le collecteur visait les jetons npm, les identifiants d'infonuagique, les clés SSH, les secrets de CI, les portefeuilles de cryptomonnaies et les fichiers de configuration des outils d'intelligence artificielle.

Il a également inscrit sa persistance dans les répertoires .claude et .vscode, ce qui constitue un choix délibéré quant à l'endroit où les développeurs placent désormais leur confiance. Un éditeur et un assistant d'intelligence artificielle disposent d'un accès au dépôt, de droits sur l'interpréteur de commandes et, de plus en plus, du pouvoir d'exécuter des commandes. Le commandement était dissimulé dans un contrat intelligent Ethereum, lu au moyen d'un appel eth_call et renvoyant le domaine npm-cache[.]com, si bien que les opérateurs peuvent réorienter leur infrastructure sans diffuser de nouveau code. L'exfiltration allait vers des dépôts GitHub créés sous les identités usurpées et intitulés Shai-Hulud: Here We Go Again, du nom de la famille de code malveillant dont celui-ci descend.

Deux heures suffisent pour un constat NIS2

Pour un exploitant de l'Union européenne ou du Royaume-Uni, la question de conformité n'est pas seulement de savoir si vous avez été touché, mais si vous savez décrire ce qui s'est passé. Deux des espaces touchés appartiennent à Deliveroo et Ornikar, une plateforme britannique de livraison et une entreprise française d'auto-écoles. Aucune des deux n'est une boutique obscure et aucune n'a choisi de figurer dans cet incident. NIS2 place la sécurité de la chaîne d'approvisionnement auprès de la direction et non de l'équipe de sécurité, et DORA exige des entités financières les mêmes preuves sur le risque informatique lié aux tiers.

Le relevé compte donc autant que la remise en état. Établissez si une compilation a été lancée le 4 août entre 09h35 et environ 15h00 UTC, moment où le canal de commandement Ethereum a été documenté alors que l'analyse se poursuivait. Changez chaque accès qu'un exécuteur pouvait atteindre, pas seulement le jeton npm : clés d'infonuagique, jetons GitHub, clés SSH, accès Kubernetes et Terraform. Reconstruisez les exécuteurs plutôt que de les nettoyer. Consignez ensuite ce que vous avez changé et quand, car c'est ce document que réclameront le régulateur, l'auditeur ou l'assureur. En France, l'ANSSI est l'autorité à laquelle remonte un incident déclarable.

À lire ensuite: 16.000 firmes mutualisent leur risque fournisseur. Pas vous  |  Le correctif signe les fichiers neufs, pas l'archive