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

204PARTAGES

7  0 
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...
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?
3  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.
3  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.
1  0 
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 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  2