IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

92PARTAGES

7  0 
Invasion silencieuse : des centaines de bibliothèques malveillantes publiées sur NPM tentent d'installer des malware 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 :

Le stockage de ces données sur la blockchain Ethereum présente l'intérêt de stocker un historique immuable de toutes les valeurs qu'il a jamais vues. Ainsi, nous pouvons voir toutes les adresses IP que cet acteur malveillant a jamais utilisées.

Le 2024-09-23 00:55:23Z il s'agissait de hxxp://localhost:3001
Le 2024-09-24 06:18:11Z c'était hxxp://45.125.67[.]172:1228
Le 2024-10-21 05:01:35Z, il s'agissait de hxxp://45.125.67[.]172:1337
Du 2024-10-22 14:54:23Z il s'agissait de hxxp://193.233[.]201.21:3001
Depuis le 2024-10-26 17:44:23Z il s'agit de hxxp://194.53.54[.]188:3001

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 :
[LIST][*]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[/*]...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 12/11/2024 à 0:21
Citation Envoyé par TotoParis Voir le message
Finalement l'Open Source pose de sacrés problèmes de sécurité.
NPM pourrait-il bloquer l'accès à un nouveau dépôt pendant 1 mois avant de le rendre disponible ?
Aucun rapport. Ce serait un miroir de soft closed-source ou on attendrait 2 ans que ce serait exactement la même chose... C'est le fait de ne pas vérifier ses dépendances (et les dépendances transitives) qui pose problème, ici.

Citation Envoyé par TotoParis Voir le message
NPM pourrait-ils faire payer par CB les dépôts ?
Car là on a surement des acteurs étatiques impliqués (Iran, Chine, Corée du Nord, Russie)
Et ces acteurs là n'ont pas les moyens de payer ou d'utiliser des cartes volées?
2  0 
Avatar de BugFactory
Membre chevronné https://www.developpez.com
Le 18/11/2024 à 15:36
Citation Envoyé par schlebe Voir le message
Vu le nombre de dépendances issues du monde libre, cela devrait être la même chose en Java !
Avec NPM, Java, et tous les dépôts publiques en fait. Mais je pense que c'est NPM le plus durement touché. Pure spéculation de ma part, mais ce genre d'attaques est devenu populaire pendant l'essor de NPM, alors que Java a déjà des bibliothèques bien établies. Il y a aussi le fait qu'avec Node le framework à la mode change tous les trois mois quand ce n'est pas toutes les trois secondes. Donc même si structurellement les deux systèmes ont la même exposition le calendrier est horrible pour Node. Non pas que ce soit une bonne idée de baisser la garde avec Java.

On est allé trop loin avec l'idée de ne pas réinventer la roue. Ca parait être du bon sens jusqu'au moment où on se rend compte qu'intégrer une librairie tierce a pris plus de temps qu'implémenter la fonctionnalité soi même. Ajoutons à ça les différentes variantes du dependance hell et la multiplication de ces attaques, et je pense qu'il faudrait faire un effort réel pour réduire le nombre de dépendances des applications.
2  0 
Avatar de TotoParis
Membre expérimenté https://www.developpez.com
Le 11/11/2024 à 20:18
Finalement l'Open Source pose de sacrés problèmes de sécurité.
NPM pourrait-il bloquer l'accès à un nouveau dépôt pendant 1 mois avant de le rendre disponible ?
NPM pourrait-ils faire payer par CB les dépôts ?
Car là on a surement des acteurs étatiques impliqués (Iran, Chine, Corée du Nord, Russie)
1  1 
Avatar de Zeeraptor
Membre régulier https://www.developpez.com
Le 12/11/2024 à 1:31
Y'a des antivirus qui sont capable de détecter des virus dans du code compile...

Et des virus posent problème en javascript?

J'ai du louper quelque chose

Si le code est 'spaghetti' tu peux déjà te méfier..Car tentative d'obfuscation
1  1 
Avatar de schlebe
Membre actif https://www.developpez.com
Le 14/11/2024 à 23:04
Vu le nombre de dépendances issues du monde libre, cela devrait être la même chose en Java !
0  0 
Avatar de BugFactory
Membre chevronné https://www.developpez.com
Le 18/11/2024 à 15:46
Citation Envoyé par Zeeraptor Voir le message
Y'a des antivirus qui sont capable de détecter des virus dans du code compile...

Et des virus posent problème en javascript?

J'ai du louper quelque chose

Si le code est 'spaghetti' tu peux déjà te méfier..Car tentative d'obfuscation
Ce que vous avez loupé c'est que ce ne sont pas des virus... Modifier une librairie SSL pour qu'elle n'utilise pas réellement des clés générées aléatoirement, mais partiellement aléatoirement (pour donner le change) et partiellement selon des règles connues uniquement de l'attaquant permettrait d'affaiblir le chiffrement au profit exclusif de ce dernier et pourrait être particulièrement difficile à détecter. Pas de virus là dedans, et ce n'est qu'un exemple des attaques possibles.
0  0