Invasion silencieuse : des centaines de bibliothèques malveillantes publiées sur NPM tentent d'installer des malwares sur les machines des développeurs pour infiltrer les entreprises

Depuis quelques années, les attaques de type "supply chain" ou chaîne d'approvisionnement sont devenues un sujet de préoccupation croissant pour les développeurs et les responsables de la sécurité informatique. Une nouvelle vague de logiciels malveillants a récemment ciblé le registre Node Package Manager (NPM), qui est largement utilisé dans l'écosystème JavaScript. Dans ce cadre, des centaines de bibliothèques (ou "packages" ont été publiées avec un seul objectif : infecter les machines des développeurs et propager des logiciels malveillants.

Les logiciels malveillants distribués sur NPM emploient diverses méthodes pour infecter les systèmes cibles

NPM est l'un des plus grands dépôts de packages JavaScript au monde, avec des millions de bibliothèques disponibles. Il permet aux développeurs de partager et de télécharger des modules pour réutiliser du code, simplifiant ainsi le développement d'applications en leur offrant un accès rapide à des fonctionnalités prêtes à l'emploi. Cependant, ce vaste dépôt est aussi devenu un terrain fertile pour les attaquants, qui peuvent y publier des packages malveillants se faisant passer pour des bibliothèques légitimes.

La vulnérabilité principale de NPM réside dans son accessibilité ouverte : tout développeur peut y publier une bibliothèque sans vérification préalable stricte. Bien que des processus d'audit et de vérification soient en place, ils ne suffisent souvent pas à détecter les logiciels malveillants avant leur propagation, car les attaques de type "typosquatting" et l'utilisation de noms similaires permettent aux packages malveillants de passer sous le radar.

Les logiciels malveillants distribués sur NPM emploient diverses méthodes pour infecter les systèmes cibles. Voici quelques-unes des techniques les plus courantes :

• Typosquatting : Cette méthode consiste à publier des paquets aux noms très similaires à des bibliothèques populaires en espérant que les développeurs feront des fautes de frappe lorsqu'ils cherchent à les installer. Par exemple, une bibliothèque légitime comme lodash pourrait être imitée par une bibliothèque nommée lodas, qui contient du code malveillant. Cette technique repose sur l’erreur humaine et profite de la négligence pour s’installer facilement sur les machines.
• Injection de scripts malveillants : Les attaquants introduisent des scripts directement dans les bibliothèques qui, une fois installées, exécutent des commandes malveillantes sur la machine cible. Ces scripts peuvent être utilisés pour des actions variées, allant du vol de données d’identification à l’accès non autorisé à des serveurs critiques.
• Obfuscation du code : Pour éviter d'être détectés, les développeurs de logiciels malveillants utilisent des techniques d'obfuscation, rendant leur code difficile à lire et à analyser. Les lignes de code sont souvent délibérément complexes, cachant la véritable nature du paquet jusqu'à ce qu'il soit exécuté.
• Chaînes d'approvisionnement compromises : Les développeurs malveillants peuvent également cibler des paquets populaires et tenter de compromettre leurs chaînes d'approvisionnement. Cela signifie qu’un attaquant pourrait obtenir un accès non autorisé au compte de développeur d'une bibliothèque légitime et y ajouter du code malveillant. Les utilisateurs qui mettront ensuite à jour cette bibliothèque se retrouveront infectés par le malware.

Une attaque en cours

Selon des chercheurs, une attaque en cours télécharge des centaines de paquets malveillants sur le dépôt du gestionnaire de paquets node (NPM) en open source afin d'infecter les appareils des développeurs qui s'appuient sur les bibliothèques de code qui s'y trouvent.

Les paquets malveillants portent des noms similaires aux noms légitimes des bibliothèques de code Puppeteer et Bignum.js, ainsi que de diverses bibliothèques permettant de travailler avec des crypto-monnaies. La campagne a été signalée par des chercheurs de l'entreprise de sécurité Phylum. Cette découverte fait suite à une campagne similaire menée il y a quelques semaines et visant les développeurs utilisant des forks de la bibliothèque Ethers.js.


Attention à l'attaque de la chaîne d'approvisionnement

« Par nécessité, les auteurs de logiciels malveillants ont dû s'efforcer de trouver de nouveaux moyens de dissimuler leurs intentions et d'obscurcir les serveurs distants qu'ils contrôlent », écrivent les chercheurs de Phylum. « Il s'agit, une fois de plus, d'un rappel persistant que les attaques de la chaîne d'approvisionnement sont bien vivantes ».

Une fois installés, les paquets malveillants utilisent une nouvelle méthode pour dissimuler l'adresse IP que les appareils contactent pour recevoir les charges utiles malveillantes de la deuxième étape. L'adresse IP n'apparaît pas du tout dans le code de la première étape. Au lieu de cela, le code accède à un contrat intelligent Ethereum pour « récupérer une chaîne, dans ce cas une adresse IP, associée à une adresse de contrat spécifique sur le réseau principal Ethereum ». Le mainnet, abréviation de « main network », est le réseau principal de la blockchain qui soutient une crypto-monnaie telle qu'Ethereum et où les transactions ont lieu.

L'adresse IP renvoyée par un paquet analysé par Phylum était : hxxp://193.233.201[.]21:3001.

Alors que cette méthode était probablement destinée à dissimuler la source des infections de deuxième stade, elle a ironiquement eu pour effet de laisser une trace des adresses précédentes que les attaquants avaient utilisées dans le passé. Les chercheurs expliquent :

Une fois installés, les paquets malveillants se présentent sous la forme d'un paquet Vercel emballé. La charge utile s'exécute en mémoire, se charge à chaque redémarrage et se connecte à l'adresse IP du contrat ethereum. Elle « exécute ensuite une poignée de requêtes pour récupérer des fichiers Javascript supplémentaires, puis renvoie des informations sur le système au même serveur demandeur », écrivent les chercheurs de Phylum. « Ces informations comprennent des informations sur le GPU, le CPU, la quantité de mémoire sur la machine, le nom d'utilisateur et la version du système d'exploitation ».

Les attaques de ce type s'appuient sur le typosquattage, un terme qui désigne l'utilisation de noms qui imitent étroitement ceux de paquets légitimes, mais qui contiennent de petites différences, comme celles qui pourraient survenir si le paquet était mal orthographié par inadvertance. Le typosquattage est depuis longtemps une tactique pour attirer les internautes vers des sites web malveillants. Au cours des cinq dernières années, le typosquattage a été adopté pour inciter les développeurs à télécharger des bibliothèques de codes malveillants.

Les développeurs devraient toujours vérifier les noms avant d'exécuter les paquets téléchargés. Le billet de blog de Phylum fournit les noms, les adresses IP et les hachages cryptographiques associés aux paquets malveillants utilisés dans cette campagne.


Impact sur les développeurs et les entreprises

L’installation de bibliothèques malveillantes sur les machines de développement n’affecte pas seulement les développeurs individuels ; elle peut également compromettre les projets entiers et les chaînes de production des entreprises. Les conséquences peuvent inclure :

• Fuites de données : Les informations sensibles stockées sur les machines compromises peuvent être extraites, y compris les identifiants d’API, les mots de passe et les informations confidentielles des clients.
• Détournement de ressources : Certains logiciels malveillants cherchent à détourner les ressources des machines infectées, souvent pour miner des cryptomonnaies, ce qui alourdit la charge des serveurs et ralentit les processus de développement.
• Perte de confiance : Lorsqu'une entreprise est compromise, cela peut affecter sa réputation et sa crédibilité auprès de ses clients, partenaires et investisseurs, causant des dommages à long terme.
• Propagation de logiciels malveillants : Si les logiciels malveillants ne sont pas détectés et éliminés rapidement, ils peuvent être intégrés dans le produit final, qui, une fois distribué aux clients, propagera l'infection à un plus grand nombre d’utilisateurs.

Mesures de protection et pratiques sécuritaires

Pour contrer cette menace, les développeurs et entreprises doivent adopter plusieurs mesures de protection et de bonnes pratiques :

• Vérification des dépendances : Avant d’installer une bibliothèque, il est essentiel de vérifier sa source, la réputation de ses auteurs et ses dépendances. Les outils de vérification de paquets, comme npm audit, peuvent aider à détecter les failles de sécurité potentielles.
• Utilisation de solutions de sécurité automatisées : Des outils de sécurité peuvent analyser le code source des bibliothèques et détecter des modèles malveillants avant que les paquets ne soient installés. Ces outils analysent également les mises à jour pour s'assurer que le code n'a pas été compromis.
• Mises à jour régulières des bibliothèques de confiance : Il est souvent préférable de s’en tenir aux versions les plus récentes et testées de bibliothèques populaires, car elles sont plus susceptibles d’être sécurisées et bien surveillées par leurs mainteneurs.
• Contrôle d'accès strict : Les entreprises doivent surveiller l'accès aux comptes de développeurs et adopter l'authentification à deux facteurs (2FA) pour éviter les compromissions de comptes.
• Formation et sensibilisation : Les développeurs doivent être formés aux bonnes pratiques de sécurité, et des sessions de sensibilisation doivent être organisées régulièrement pour les informer des nouvelles menaces.

Les défis d’une protection totale sur NPM

Malgré les mesures de sécurité en place, NPM reste un environnement difficile à protéger totalement, en raison de son caractère ouvert et de la nature même de l'écosystème JavaScript. Tout le monde peut publier un paquet sur NPM, et bien que des mécanismes de vérification existent, ils ne sont pas toujours suffisants pour empêcher la distribution de logiciels malveillants. Les audits de sécurité automatisés sont loin d’être parfaits et peuvent facilement manquer des techniques d'obfuscation avancées.

Par ailleurs, l'approche même de la communauté JavaScript, qui valorise la modularité et l'intégration de nombreux paquets dans les projets, contribue à cette vulnérabilité. En dépendant de centaines de bibliothèques, chaque projet expose son code à de multiples points de défaillance potentiels, rendant la tâche de sécurisation encore plus complexe. La gestion de dépendances dans le développement JavaScript exige donc une vigilance constante, mais il est clair que des approches plus strictes devront être adoptées à l'avenir pour protéger l'intégrité des projets.

La responsabilité de la sécurité sur NPM ne repose pas uniquement sur les épaules des utilisateurs, mais également sur celles de la plateforme elle-même, qui devrait renforcer ses politiques de vérification et mieux encadrer la publication de paquets. En parallèle, l’adoption d’outils comme les « sandbox » pour isoler l’exécution de nouveaux paquets avant leur installation pourrait également réduire les risques.

Conclusion

La communauté JavaScript est-elle trop dépendante de bibliothèques externes ? Existe-t-il des moyens d’encourager davantage l’autosuffisance en développement, ou est-ce inévitable dans l’écosystème actuel ? Les entreprises devraient-elles intégrer des équipes dédiées à la surveillance et la sécurité des dépendances dans leurs flux de travail, ou est-ce une mesure excessive ?

En attendant de répondre à ces questions, les chercheurs ont conclu en disant : « Par nécessité, les auteurs de logiciels malveillants ont dû s'efforcer de trouver de nouveaux moyens de dissimuler leurs intentions et d'obnubiler les serveurs distants qu'ils contrôlent. Cela nous rappelle une fois de plus que les attaques contre la chaîne d'approvisionnement existent bel et bien. Elles évoluent en permanence et ciblent souvent la vaste communauté des développeurs de logiciels avec des progiciels malveillants ».

Sources : Phylum (1,2), documentation (npm-audit), Ethereum

Et vous ?

Quelle est la responsabilité de la plateforme NPM dans la diffusion de ces logiciels malveillants ? Devrait-elle être davantage réglementée pour protéger les utilisateurs ?
À quel point les développeurs sont-ils eux-mêmes responsables de la sécurité lorsqu’ils choisissent d’utiliser des bibliothèques open source ? Où placer la limite entre vigilance individuelle et protection institutionnelle ?
Les outils comme npm audit sont-ils suffisants pour détecter ces menaces ? Que pourrait-on ajouter pour mieux sécuriser les dépendances des projets ?
La mise en place de "sandbox" pour tester l’exécution des bibliothèques avant leur intégration est-elle réaliste ? Quelles pourraient en être les limitations et les défis techniques ?
Quel pourrait être l’impact de ces infections à long terme pour les entreprises ? Est-il possible de mesurer le coût réel de ce type de cyberattaque sur les projets de développement ?
En cas d’attaque réussie par une bibliothèque malveillante, quelles sont les actions immédiates qu'une entreprise peut prendre pour limiter les dégâts ?