Diffusions Node.js: les ingénieurs de Google ont trouvé une vulnérabilité dans les scripts NPM

Développeurs Node.js, exécutez la commande `npm install` à vos risques et périls et rappelez-vous que le ver à propagation automatique se déplace librement dans l'écosystème.

Vous ne pouvez jamais supposer qu'un fichier téléchargé sur Internet est sûr. Cela est vrai pour NPM, le gestionnaire de packages Node.js standard. Une vulnérabilité dans l'installation de scripts permet à un attaquant de créer un ver à propagation automatique qui peut traverser les paquets NPM.


"Cela est possible du fait qu'un package NPM peut facilement traverser la plupart de l'écosystème à travers lui-même", écrit le développeur de Google Sam Sakoni dans son article "exposant l'hydre NPM."

Comme dans d'autres gestionnaires de packages, NPM prend en charge les scripts de «cycle de vie» qui peuvent être exécutés par des commandes externes dans le système en tant qu'utilisateur actuel. Bien que ces scripts soient souvent utiles et utilisés pour nettoyer les fichiers après le processus d'installation, compiler des modules binaires et créer automatiquement des fichiers de configuration, ils peuvent être dangereux en même temps, car ils peuvent apporter des modifications au système lors de l'exécution de diverses commandes.
«Il est possible que des packages NPM écrits avec une intention malveillante, lors de l'installation, exécutent des scripts qui sont intégrés dans d'autres packages, qui sont à leur tour publiés dans le registre, et d'autres packages créés par l'utilisateur», écrivent-ils dans un article sur le blog officiel de NPM. Cependant, la société signale que les avantages de l'utilisation de ces scripts l'emportent sur les risques d'une menace potentielle.

La publication minimise le risque et attire l'attention sur les colis qui sont «propres dès le début», mais tous n'en sont pas «à cent pour cent» sûrs. L'article de Sakoni, à l'exception de quelques solutions de contournement, ne précise pas comment être sûr que les packages que les utilisateurs installent ne seront pas ce qu'ils attendaient.

«NPM ne peut garantir la sécurité de leur registre de packages», note l'article.

Le ver s'infiltre dans les dépendances de paquets

Le ver tire parti de trois fonctionnalités de NPM: le contrôle de version sémantique (semver), la publication dans un registre centralisé et les privilèges d'un utilisateur qui se connecte automatiquement. Parce que l'utilisateur reste autorisé jusqu'à ce qu'il soit connecté manuellement. Quiconque se connecte et exécute l'installation permet aux autres modules d'exécuter une grande variété de commandes. Tant qu'il n'y a pas de liaison à des versions spécifiques, les packages peuvent être mis à niveau vers de nouvelles versions et chacun d'eux peut exécuter du code. Et enfin, ils peuvent envoyer des packages au serveur de registre central, d'où d'autres peuvent les installer.

L'attaque du ver repose sur l'ingénierie sociale pour l'infection initiale et les «améliorations» susmentionnées peuvent se déplacer librement dans l'écosystème.

Tout d'abord, l'attaquant incite le propriétaire du package NPM à installer le package infecté sur son système. Il peut s'agir de phishing ou de toute autre attaque similaire. Une fois installé, il crée une version «cheval de Troie» du package du propriétaire du module NPM et définit un hook pour lancer le ver où qu'il soit installé. Le module modifié publié sur le compte du propriétaire devient le point de départ de l'infection de tous ses packages, lançant le module cheval de Troie en tant que dépendance. Le ver crée de nouvelles versions de modules dans le compte avec le commentaire «bugfix», et maintenant, quand il est installé, du code auto-propagé peut être exécuté.

Pour un exemple. Phonegap a 463 dépendances intermédiaires. Et 276 comptes NPM individuels peuvent mettre à jour les versions de leurs packages. Maintenant, une seule personne sur ces 276 est suffisante pour que le ver continue à infecter tous ceux qui ont installé le package du projet PhoneGap, explique Sakoni.

NPM nie les risques

Bien que le trou n'ait pas été fermé, une note sur la vulnérabilité de l'équipe de préparation aux urgences informatiques des États-Unis met en évidence plusieurs solutions pour contourner le danger. Ils utilisent l'option «-ignore-scripts» lorsqu'ils installent de nouvelles dépendances, ferment des versions avec «npm-shrinkwrap» et encouragent les utilisateurs dont les modules eux-mêmes sont constamment débloqués de NPM.

Les organisations qui utilisent NPM dans leur environnement doivent exécuter un miroir de registre NPM local et empêcher les utilisateurs individuels d'installer directement les dépendances à partir du registre principal. Ils doivent vérifier régulièrement le registre local et s'assurer que les fichiers malveillants ne figurent pas dans la liste des dépendances.

Sakoni a recommandé de définir le délai d'expiration des jetons et de forcer les utilisateurs à quitter NPM après un certain laps de temps. Dans un article de blog, l'entreprise n'a pas décrit ces recommandations, mais a annoncé d'autres solutions pour minimiser les risques.

Une idée est de compliquer la publication des modules, si l'utilisateur n'est pas conscient du danger, il peut s'agir d'une authentification à deux facteurs. Vous pouvez toujours travailler avec des entreprises qui offrent une protection, en proposant à ces dernières de vérifier les modules, mais jusqu'à présent, ce n'est pas possible. À l'heure actuelle, la société surveille les packages fréquemment mis à jour, car le ver peut être détecté par des versions très fréquentes de nouvelles versions, mais ils dépendent davantage des utilisateurs qui eux-mêmes notifieront les packages suspects.

"Sans aucun doute, si de nombreux utilisateurs tentent de publier massivement des packages malveillants de concert, ils seront disponibles dans le registre NPM", a déclaré le blog.

Faire confiance mais vérifier

Ce sera quelques jours difficiles pour NPM. L'identification des packages publiés malveillants est leur «talon d'Achille». Dans le débat actuel sur le thème de la réglementation par le gestionnaire des colis retirés du registre. Suppression par le développeur d'un package de NPM la semaine dernière, interrompant ainsi de nombreux projets qui en dépendent. Il est également assez simple d'enregistrer votre code sous le nom du module distant. Quiconque a attribué le nom d'une autre personne peut définir le code pour n'importe quel utilisateur, ce qui dépend de l'original.

Au cours des derniers jours, Reddit et GitHub ont beaucoup discuté de la confiance dans les développeurs, du support des packages qu'ils ont créés et de la possibilité de commencer à créer du code malveillant. Dans l'écosystème mondial, c'est une hypothèse dangereuse, car si l'un de ces développeurs veut casser beaucoup de code, il devra affronter toute la communauté. Cependant, il doit y avoir des moyens d'installer des modules en toute sécurité, il peut s'agir d'une signature numérique ou d'autres méthodes de vérification de la sécurité et de l'exactitude du code. En attendant, il ne reste plus qu'à ressentir l'alarme à chaque fois que vous exécutez la commande `npm install`.

Article d'origine: www.infoworld.com/article/3048526/security/nodejs-alert-google-engineer-finds-flaw-in-npm-scripts.html

Source: https://habr.com/ru/post/fr392409/