Du code malveillant dans des paquets Red Hat volait les clés du cloud

Pendant un temps, certaines des briques logicielles distribuées sous le nom de Red Hat ont travaillé en silence contre ceux qui les installaient. Dans plus de 30 paquets de la collection publique @redhat-cloud-services de l’entreprise se trouvait un petit script prêt à s’exécuter dès qu’un développeur en installait un. Il était inscrit comme une étape preinstall, l’une de ces tâches automatiques que l’outil npm lance de lui-même avant qu’une seule ligne du vrai logiciel ne se charge. Sa mission était de chercher des mots de passe, puis de se propager.

Red Hat ne fabrique pas d’applications que la plupart des gens ouvrent par leur nom, mais son code soutient une part énorme de ce qu’ils utilisent chaque jour : les tableaux de bord cloud par lesquels une banque se connecte, les systèmes sur lesquels tournent hôpitaux et administrations, les outils avec lesquels d’autres entreprises bâtissent leurs propres produits. Quand un code portant cette étiquette devient hostile, le rayon d’impact n’est pas une application. C’est tout ce qui est assemblé par-dessus.

Le script caché est parti à la chasse aux clés qui déverrouillent l’informatique moderne. Selon la société de sécurité StepSecurity, la première à avoir signalé les paquets, il a ramassé des jetons d’accès pour Amazon Web Services, Google Cloud, Microsoft Azure, Kubernetes, HashiCorp Vault, npm lui-même et le service d’automatisation CircleCI, ainsi que les secrets stockés dans les chaînes de compilation de GitHub. Pour les atteindre, il lisait la mémoire brute du processus de compilation en cours, une astuce qui contourne les garde-fous censés tenir les secrets hors des journaux.

Ce qui transforme un vol de données ordinaire en quelque chose de plus proche d’une épidémie, c’est ce que le code faisait ensuite. Muni des jetons de publication npm dérobés, il tentait de mettre en ligne des versions fraîchement piégées de tous les autres paquets auxquels le compte détourné pouvait accéder, en s’appuyant sur un paramètre qui écarte la vérification en deux étapes normalement présente. Un vol qui se recopie ne reste pas auprès de ses premières victimes. Il voyage le long de la confiance même sur laquelle repose tout le système.

Sur les machines des développeurs eux-mêmes, la charge allait plus loin : elle déposait des instructions dans les réglages de tâches de Visual Studio Code et dans la configuration de Claude Code, l’assistant de programmation par intelligence artificielle, afin de continuer à s’exécuter bien après la fin de l’installation. Ceux qui sont les plus susceptibles d’installer ces paquets, les ingénieurs qui entretiennent le logiciel de tous les autres, étaient aussi ceux dont l’ordinateur devenait une porte d’entrée.

Le détail le plus gênant tient à l’origine des mauvaises versions. Les développeurs de Red Hat, qui ont reconnu le problème sur le dépôt public du projet, et les chercheurs qui ont décortiqué le code s’accordent : les versions empoisonnées sont sorties par la propre chaîne de publication automatique de Red Hat, la mécanique qui prend le code de ses dépôts et l’envoie au monde. Les attaquants n’ont pas usurpé l’identité de Red Hat. Pendant un temps, ils ont pu publier en tant que Red Hat. Le sceau de la confiance et ce à quoi on se fiait se sont disjoints.

Ce n’est pas la première fois que la chaîne d’approvisionnement du logiciel libre se transforme en circuit de livraison. Extensions de navigateur piégées et comptes de développeurs détournés sont réapparus tout au long du printemps, tous exploitant la même habitude : le logiciel moderne s’assemble à partir de milliers de composants gratuits que personne n’écrit en partant de zéro. Ce qui rend ce cas plus lourd, c’est le nom sur la boîte. Toute la raison de prendre du code chez un fournisseur comme Red Hat, plutôt que chez un contributeur anonyme, c’est que ce nom est censé être la garantie.

Il faut dire clairement ce que cet incident ne signifie pas. À ce stade, rien n’indique que des appareils d’utilisateurs ordinaires aient été infectés, ni que les produits d’entreprise payants de Red Hat et les systèmes en production de ses clients aient été forcés. Les versions malveillantes visaient le territoire intermédiaire du développement, les serveurs de compilation automatiques et les machines des ingénieurs, et nombre des paquets touchés sont des outils d’interface et de développement, non le cœur d’un service en fonctionnement. Le tableau reste mouvant, et le nombre exact de paquets contaminés a évolué à mesure que Red Hat et les chercheurs externes parcourent la liste. Le dommage qui compte le plus, les identifiants volés, demeure invisible jusqu’à ce que quelqu’un s’en serve.

Red Hat a retiré peu à peu les versions malveillantes, et les publications compromises sont en train d’être effacées de npm. À qui les a installées dans la fenêtre concernée, on demande de considérer comme brûlé chaque jeton que la compilation pouvait voir et de le renouveler. La divulgation est arrivée début juin, et le nettoyage durera plus longtemps que les titres. Le problème de fond durera plus longtemps que le nettoyage : internet s’assemble, à grande vitesse, à partir de millions de petites pièces entretenues par des gens que nous ne connaîtrons jamais, et de plus en plus par des systèmes automatiques que l’on peut détourner pour signer ces pièces à leur place.

Étiquettes: cybersécurité, npm