Le registre NPM (Node Package Manager) souffre d’une faille de sécurité appelée « confusion manifeste », qui sape la fiabilité des packages et permet aux attaquants de cacher des logiciels malveillants dans des dépendances ou d’exécuter des scripts malveillants lors de l’installation.

NPM est un gestionnaire de packages pour le langage de programmation JavaScript et la valeur par défaut pour l’environnement Node.js largement utilisé. Le gestionnaire de packages aide les propriétaires de projets à automatiser l’installation, la mise à niveau et la configuration des packages logiciels hébergés sur la base de données « npm Registry » sur npmjs.com.

En 2020, la plate-forme a été acquise par Microsoft via GitHub, et aujourd’hui, on estime que plus de 17 millions de développeurs de logiciels dans le monde l’utilisent, téléchargeant 208 milliards de packages par mois.

Darcy Clarke, un ancien ingénieur GitHub, a souligné le problème de confusion manifeste dans un article sur son blog, expliquant que bien que son ancien employeur soit au courant du problème depuis au moins novembre 2022, peu a été fait pour faire face aux risques associés.

Le registre NPM est également extrêmement populaire parmi les développeurs car il contient un large assortiment de packages qui peuvent être utilisés pour étendre les fonctionnalités d’une application sans nécessiter de travail de développement supplémentaire.

Cependant, sa popularité en fait une cible de choix pour les acteurs de la menace qui distribuent des packages malveillants pour prendre le contrôle des ordinateurs des développeurs, voler des informations d’identification ou même déployer des rançongiciels.

Confusion manifeste
Une confusion manifeste se produit, il y a une incohérence entre les informations manifestes d’un package présentées sur le registre npm et le fichier ‘package.json’ réel dans l’archive tar du package npm publié utilisé lors de l’installation du package.

Les données manifestes soumises à NPM lors de la publication d’un package et le package.json contiennent des informations sur le nom du package, la version et d’autres métadonnées, telles que les scripts utilisés dans le déploiement, les dépendances de construction, etc.

Les deux sont soumis séparément au registre npm, et la plate-forme ne valide pas s’ils correspondent, de sorte que leurs données pourraient différer, et personne ne le saurait à moins d’examiner leur contenu.

Cela permet à un auteur de menace de modifier les données manifestes soumises avec un nouveau package pour supprimer les dépendances et les scripts afin qu’ils n’apparaissent pas dans le registre NPM. Cependant, ces scripts et dépendances existent toujours dans le fichier package.json et seront exécutés lors de l’installation du package.

Cette « confusion manifeste » est illustrée dans l’image ci-dessous, montrant qu’il n’y a aucune dépendance répertoriée sur NPM pour le package de preuve de concept de Clarke, même s’il existe des dépendances répertoriées dans le package.json.

Exemple de données manifestes manipulées

Les risques qui découlent de l’incohérence de « confusion manifeste » incluent l’empoisonnement du cache, l’installation de dépendances inconnues, l’exécution de scripts inconnus et potentiellement aussi les attaques de rétrogradation.

« Et pour être clair, il ne s’agit pas seulement de dépendances cachées », a averti le PDG de Socket, Feross Aboukhadijeh, à Breachtrace , qui a déclaré que leurs outils ne sont pas concernés par ce problème.

« La confusion manifeste permet également à un attaquant d’inclure également des scripts d’installation cachés. Ces scripts et dépendances cachés n’apparaîtront pas sur le site Web npm ou dans la plupart des outils de sécurité, même s’ils seront installés par la CLI npm. »

Malheureusement, la communauté npm et tous les principaux gestionnaires de packages, y compris npm@6, npm@9, yarn@1 et pnpm@7, sont impactés par ce problème.

npm@6 exécutant le script d’installation non présent dans le manifeste ou vice-versa

Malheureusement, cela conduit à un manque de confiance dans le registre NPM car les dépendances, les numéros de version et même les noms de packages peuvent ne pas être exacts.

Au lieu de cela, les développeurs doivent lire manuellement le package.json pour déterminer les numéros de version, les dépendances qui seront installées et les scripts qui seront exécutés.

Problème toujours non résolu
Clarke dit que GitHub est au courant des problèmes de confusion manifeste depuis au moins 2022, et un rapport de bogue déposé sur le référentiel GitHub de la npm CLI concernant le paquet node-canvas semble le confirmer.

L’ingénieur a soumis un rapport HackerOne détaillé qui présentait des exemples du problème le 9 mars 2023.

Le 21 mars 2023, GitHub a fermé le ticket, répondant qu’ils traitaient le problème en interne. Pourtant, ils n’ont pas encore remédié aux risques et ne les ont pas communiqués à la communauté npm.

Clarke mentionne qu’en raison de la taille même de npm et du fait qu’il suit cette pratique dangereuse depuis de nombreuses années, résoudre ce problème est loin d’être anodin.

Jusqu’à ce que GitHub élabore un plan pour faire face à la confusion manifeste sur npm, Clarke suggère que les auteurs et les mainteneurs de packages suppriment la dépendance aux données manifestes et se procurent à la place toutes les métadonnées à l’exception du nom et de la version des fichiers ‘package.json’ qui sont moins enclins à manipulation.

Une autre mesure de protection consisterait à utiliser un proxy de registre entre la base de données du package et le client npm, ce qui pourrait implémenter des vérifications et des validations supplémentaires pour assurer la cohérence entre les données du manifeste et les informations contenues dans l’archive tar du package.

Breachtrace a contacté GitHub à propos du problème, et nous mettrons à jour ce message dès que nous aurons reçu une réponse.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *