Paquets npm de Red Hat piégés : la chaîne logicielle, angle mort des PME
Le 1er juin, 32 paquets npm publiés sous le nom de Red Hat contenaient un voleur d'identifiants. Ce que ça dit des logiciels que vous faites développer.
Le 1er juin, on a appris qu'une trentaine de paquets publiés sur npm sous l'espace de noms officiel de Red Hat avaient été remplacés par des versions piégées. Installées, elles volaient les clés d'accès des développeurs et des serveurs d'intégration. Red Hat n'est pas une petite structure mal outillée : c'est l'un des acteurs les plus sérieux du logiciel libre. Si ça lui arrive, ça peut arriver à n'importe quelle brique dont dépend votre logiciel. Ce qu'il faut en retenir, sans jargon.
Ce qui s'est passé
npm est le registre où les applications web et mobiles écrites en JavaScript vont chercher leurs composants. Un logiciel métier moderne en utilise couramment plusieurs centaines, souvent sans que personne les ait choisis un par un : chaque composant en tire d'autres.
Selon BleepingComputer, qui s'appuie sur les analyses des sociétés Aikido et OX Security, 32 paquets de l'espace @redhat-cloud-services ont été touchés, soit 96 versions, pour environ 117 000 téléchargements par semaine. Le mode opératoire décrit est le suivant :
- un compte GitHub d'un employé de Red Hat a été compromis ;
- l'attaquant s'en est servi pour ajouter une automatisation qui publiait de nouvelles versions des paquets, en passant par le mécanisme de publication de confiance de npm ;
- ces versions contenaient un script lancé automatiquement à l'installation, qui exécutait un programme dissimulé.
Ce programme, baptisé « Miasma » par les chercheurs, est une variante de la famille Shai-Hulud. Il cherche les secrets des serveurs d'intégration continue, les identifiants des clouds AWS, Google Cloud et Azure, les jetons de publication npm et PyPI, les clés SSH, les accès Docker et les fichiers de configuration qui contiennent des mots de passe. BleepingComputer rappelle que le code source d'une version voisine, Mini Shai-Hulud, avait été rendu public en mai : n'importe qui peut désormais s'en servir.
Red Hat a retiré les versions piégées du registre et publié un bulletin de sécurité. L'éditeur indique que la compromission concerne des outils de développement internes et qu'il n'a identifié aucun impact sur les systèmes de ses clients ni sur ses produits. Son enquête était encore en cours au moment de la publication.
Pourquoi une PME devrait s'en soucier
Vous n'installez probablement pas de paquets npm vous-même. Mais si vous avez fait développer une application, un extranet, un site e-commerce ou un logiciel métier ces dernières années, il y a de bonnes chances qu'il en contienne des centaines. Le risque n'est pas théorique, il prend trois formes :
- Le poste du développeur. Une dépendance piégée installée chez votre prestataire peut voler les accès à vos serveurs, à votre hébergement, à votre dépôt de code.
- La chaîne de mise en production. Les serveurs qui construisent et déploient votre logiciel détiennent souvent les clés les plus sensibles. C'est exactement ce que ce type de programme vise.
- Le logiciel livré lui-même, si une version piégée passe jusqu'en production et y reste.
Le point commun : vous n'en saurez rien si personne ne surveille. Ce genre d'attaque ne fait pas tomber le site. Elle se tait et collecte.
Les questions à poser à votre prestataire
Vous n'avez pas besoin de devenir expert. Cinq questions suffisent pour savoir si le sujet est pris au sérieux :
- Les versions des dépendances sont-elles figées ? Un fichier de verrouillage (lockfile) garantit que l'on installe toujours exactement les mêmes versions, et non « la dernière » publiée la veille par on ne sait qui.
- Les scripts d'installation des dépendances sont-ils contrôlés ? C'est par là que Miasma s'exécutait. Certains outils permettent de les bloquer par défaut et de n'autoriser que ceux qui sont nécessaires.
- Où sont stockés les secrets ? Mots de passe, clés de cloud et jetons ne doivent jamais être dans le code, et les serveurs de construction ne doivent détenir que les accès strictement nécessaires.
- Qui a accès au dépôt de code et aux comptes de publication, et avec quelle double authentification ? Ici, tout est parti d'un compte compromis.
- Que se passe-t-il le jour d'une alerte ? Qui vérifie si vous êtes concerné, qui change les clés, en combien de temps ?
Ce que nous faisons de notre côté
Sur les logiciels que nous développons, les versions de dépendances sont figées, les mises à jour sont relues avant d'être intégrées, et les secrets restent hors du code. Lorsqu'une alerte de ce type tombe, la première vérification est simple : la version piégée figure-t-elle dans le fichier de verrouillage d'un projet ? Si oui, on retire, on change toutes les clés accessibles depuis la machine concernée, et on prévient le client.
Nous remettons aussi le code source et la documentation à nos clients. Ce n'est pas un détail : un logiciel dont vous détenez le code peut être audité par quelqu'un d'autre que celui qui l'a écrit. C'est la façon dont nous travaillons sur nos logiciels métier, avec une maintenance qui répond sous 24 heures ouvrées.
Ce que nous conseillons cette semaine
- Si votre prestataire utilise des paquets de l'espace @redhat-cloud-services, demandez-lui s'il en a installé une version piégée depuis le 1er juin. Si oui, les recommandations publiées sont claires : changer immédiatement tous les identifiants accessibles depuis les machines concernées.
- Dans tous les cas, posez les cinq questions ci-dessus. La réponse vous dira plus de choses sur la qualité d'un prestataire qu'une plaquette.
- Si personne ne sait vous répondre, c'est un signal : votre logiciel n'est probablement pas maintenu, seulement hébergé.
Pour faire le point sur un logiciel existant ou sur un projet à venir, vous pouvez prendre un rendez-vous de 30 minutes, gratuit, avec l'équipe.