L'histoire de la sécurité open source est jonchée d'exemples de défaillances catastrophiques et de quasi-accidents. Une campagne de cryptomalveillance découverte début septembre se situe quelque part entre les deux. Selon (lire ici), un acteur de menace non identifié a compromis un seul compte de mainteneur npm et, grâce à cet accès, a déployé du code malveillant sur des packages avec plus de deux milliards de téléchargements hebdomadaires.

Il a déjà été décrit comme la plus grande compromission de la chaîne d'approvisionnement de l'histoire de npm, lui-même le plus grand registre de logiciels au monde. Si cela est un signe avant-coureur, comment les entreprises utilisatrices d'open source peuvent-elles se protéger des cyber-risques croissants ?

Qu'est-il arrivé à npm ?

Le 8 septembre, Josh Junon (alias « qix »), développeur et mainteneur open source, a révélé sur les réseaux sociaux que son compte npm avait été compromis. Il l'a découvert après que ce compte a commencé à publier des versions trojanisées de paquets populaires tels que Chalk (300 millions de téléchargements hebdomadaires), Debug (357 millions) et Ansi-Styles (371 millions).

Le code malveillant « intercepte silencieusement l'activité crypto et web3 dans le navigateur, manipule les interactions du portefeuille et réécrit les destinations de paiement de sorte que les fonds et les approbations soient redirigés vers des comptes contrôlés par l'attaquant sans aucun signe évident pour l'utilisateur », selon Aïkido.

Junon aurait été la cible d'une attaque sophistiquée d'ingénierie sociale. Les pirates avaient enregistré un domaine de typosquattage quelques jours auparavant et l'avaient utilisé pour se faire passer pour des administrateurs npm légitimes dans un e-mail de réinitialisation de l'authentification à deux facteurs. Junon a affirmé que cela « semblait très légitime ».

Une évasion chanceuse ?

Finalement, la communauté open source s’est mobilisée et, fait impressionnant, toutes les versions de packages malveillants ont été supprimées moins de quatre heures plus tard.

« Tout le monde travaille ensemble. L'information peut être partagée. Le nombre de personnes travaillant actuellement sur ce projet dépasse non seulement votre équipe de sécurité, mais aussi votre entreprise », a déclaré Anchore, vice-président de la sécurité. Josh Bressers. Les rapports de l'époque suggéraient que les acteurs de la menace avaient réussi à voler moins de 1 000 dollars dans les portefeuilles cryptographiques des victimes, malgré la portée potentiellement énorme de la campagne.

Mais l'histoire ne s'arrête pas là. Même durant la courte période où les paquets circulaient librement, ils se sont propagés à grande échelle. Selon l'éditeur de sécurité Wiz, 10 % des environnements cloud ont été impactés.

« Pendant le court laps de temps de deux heures pendant lequel les versions étaient disponibles au téléchargement, si elles étaient incorporées dans des versions frontales et expédiées en tant qu'actifs Web, tout navigateur chargeant le site Web affecté exécuterait une charge utile malveillante qui accrocherait les API du réseau et du portefeuille afin de réécrire silencieusement les destinataires/approbations de cryptomonnaie avant la signature, de sorte que les transactions seraient détournées vers des portefeuilles contrôlés par l'attaquant », a affirmé le fournisseur.

Il est apparu par la suite que les pirates ciblaient également d'autres mainteneurs et paquets, notamment duckdb, proto-tinker-wc, prebid-universal-creative, ainsi que prebid et prebid.js. Bien qu'il soit heureux que la charge malveillante ne soit qu'un malware de vol de cryptomonnaies, et non un fléau plus sérieux, il s'agit assurément d'un avertissement pour l'avenir.

Les mainteneurs dans la ligne de mire

Impossible de remettre le génie de l'open source dans sa bouteille. Plus de 6 600 milliards de composants open source ont été téléchargés en 2024, et npm a généré 4 500 milliards de requêtes, selon SonatypeIl est toutefois inquiétant de constater que les mainteneurs de packages extrêmement populaires, souvent sous-financés et surmenés, sont de plus en plus ciblés. Mitun Zavery, vice-président régional de Sonatype, compare cette dernière campagne à celle ciblant xz Utils l'année dernière.

« Nous avons constaté l'émergence d'une tendance claire où les acteurs malveillants ciblent les mainteneurs de projets largement utilisés mais sous-financés. La récente compromission de paquets npm comme chalk et debug reflète ce que nous avons observé avec la tentative de porte dérobée xZ Utils. Dans les deux cas, l'adversaire a patiemment instauré la confiance pour prendre le contrôle, ce qui montre que l'ingénierie sociale est désormais une étape clé dans la compromission de la chaîne d'approvisionnement », explique-t-il à ISMS.online.

L'industrie doit reconnaître que les mainteneurs open source font partie intégrante de notre infrastructure critique et commencer à les doter des ressources nécessaires, notamment en matière de financement, d'outils de sécurité et de réseaux de soutien. Nos travaux sur xz Utils ont montré qu'une alerte précoce collaborative et une réponse rapide à l'échelle de l'écosystème peuvent stopper ces attaques avant qu'elles ne se propagent.

Assumer un compromis

Sachar Menashe, vice-président de la recherche en sécurité chez JFrog, affirme que le défi de telles attaques est leur vitesse.

« Une fois qu'un package fiable est compromis, il peut se propager rapidement dans les pipelines CI/CD et entre les projets. Une approche zéro confiance est essentielle : aucun package ne devrait être considéré comme fiable uniquement parce qu'il est populaire », explique-t-il à ISMS.online. « Pour atténuer ces attaques, les organisations devraient imposer l'authentification à deux facteurs. Cette authentification est déjà appliquée dans npm et PyPI, mais pas dans d'autres dépôts comme Maven et NuGet. »

Idéalement, les packages devraient être examinés avant d’entrer dans une organisation, avec des règles définies et une analyse des dépendances directes et transitives dans leur contexte, poursuit Menashe.

« Retarder les mises à niveau est également utile. En effet, nos recherches montrent qu'attendre au moins 14 jours avant de déployer de nouvelles versions de paquets constitue une protection solide, car les paquets piratés sont presque toujours détectés et supprimés dans ce délai », explique-t-il.

Zavery de Sonatype soutient que la visibilité sur les composants et les packages open source est également essentielle.

« Les organisations doivent partir du principe qu'une compromission est possible et être prêtes à réagir en maintenant des nomenclatures logicielles précises (SBOM), en surveillant les modifications de dépendances suspectes et en testant les builds en sandbox », explique-t-il. « Lors de notre enquête sur l'incident xz Utils, nous avons constaté que cette visibilité permettait d'identifier et de supprimer rapidement les composants contaminés. »

Les normes de sécurité pourraient également aider les organisations, soutient Zavery.

« Des référentiels comme la norme ISO 27001 peuvent contribuer à la mise en place de processus rigoureux de gestion des risques, de contrôle des accès et de réponse aux incidents, mais ils doivent être appliqués dans une perspective de chaîne d'approvisionnement », conclut-il. « L'intégration de contrôles de sécurité open source dans ces normes peut renforcer la résilience des organisations face au type de piratage de comptes que nous venons d'observer. »

Une chose est sûre : ces attaques reviendront chaque fois plus fortes. Quelques jours seulement après le lancement de cette campagne, premier malware vermifuge L'écosystème NPM est touché. Quoi qu'il en soit, les RSSI ne peuvent se permettre d'avoir un angle mort en matière de sécurité open source au sein de leur organisation.