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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

Invasion silencieuse : des centaines de bibliothèques malveillantes publiées sur NPM

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    9 049
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 9 049
    Points : 209 083
    Points
    209 083
    Par défaut Invasion silencieuse : des centaines de bibliothèques malveillantes publiées sur NPM
    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.

    Nom : pup.png
Affichages : 77397
Taille : 91,7 Ko

    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.

    Nom : clip.png
Affichages : 23703
Taille : 22,3 Ko

    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté
    Homme Profil pro
    retraité
    Inscrit en
    Septembre 2014
    Messages
    641
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Septembre 2014
    Messages : 641
    Points : 1 519
    Points
    1 519
    Par défaut
    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)

  3. #3
    Expert éminent Avatar de kain_tn
    Homme Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 713
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 713
    Points : 8 023
    Points
    8 023
    Par défaut
    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?
    Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include <stdio.h>
     
    int main(int argc, char **argv) {
     
        printf("So long, and thanks for the fish, Dennis...\n");
        return 0;
    }

  4. #4
    Membre régulier
    Homme Profil pro
    Chômeur inutile
    Inscrit en
    Juillet 2012
    Messages
    97
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Chômeur inutile
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2012
    Messages : 97
    Points : 99
    Points
    99
    Par défaut
    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

  5. #5
    Membre actif
    Homme Profil pro
    retraité depuis juin 2019
    Inscrit en
    Février 2018
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : Belgique

    Informations professionnelles :
    Activité : retraité depuis juin 2019
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Février 2018
    Messages : 63
    Points : 218
    Points
    218
    Par défaut C'est la même chose en Java !
    Vu le nombre de dépendances issues du monde libre, cela devrait être la même chose en Java !

  6. #6
    Membre chevronné
    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    951
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France

    Informations forums :
    Inscription : Octobre 2005
    Messages : 951
    Points : 1 864
    Points
    1 864
    Par défaut
    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.

  7. #7
    Membre chevronné
    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    951
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France

    Informations forums :
    Inscription : Octobre 2005
    Messages : 951
    Points : 1 864
    Points
    1 864
    Par défaut
    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.

Discussions similaires

  1. Réponses: 6
    Dernier message: 02/05/2022, 10h51
  2. Réponses: 5
    Dernier message: 13/09/2015, 19h52
  3. Réponses: 4
    Dernier message: 24/02/2008, 22h16
  4. Réponses: 3
    Dernier message: 30/04/2007, 17h37
  5. Réponses: 3
    Dernier message: 20/04/2007, 09h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo