Snyk révèle des activités malveillantes dans la chaîne d’approvisionnement open source sur le registre npm
5 mai 2021
0 minutes de lectureL’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 :

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 :
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 :
Ou, si vous utilisez yarn :
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 :

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 :
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.

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 :
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.
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.



