Vulnérabilité permettant de publier une mise à jour pour n'importe quel package dans le dépôt NPM

La société GitHub a annoncé deux incidents survenus dans l'infrastructure du dépôt de paquets NPM. Le 2 novembre, des chercheurs en sécurité indépendants (Kajetan Grzybowski et Maciej Piechota) ont signalé une vulnérabilité dans le dépôt NPM dans le cadre du programme Bug Bounty, permettant de publier une nouvelle version de tout paquet en utilisant un compte non autorisé pour effectuer de telles mises à jour.

La vulnérabilité était due à une vérification des droits incorrecte dans le code des microservices qui traitent les requêtes à NPM. Le service d'authentification vérifiait les droits d'accès aux paquets en fonction des données transmises dans la requête, mais un autre service, qui télécharge la mise à jour dans le dépôt, déterminait le paquet à publier en fonction des métadonnées contenues dans le paquet téléchargé. Ainsi, un attaquant pouvait demander la publication d'une mise à jour pour son propre paquet, auquel il avait accès, tout en spécifiant dans le paquet lui-même les informations d'un autre paquet qui serait finalement mis à jour.

Le problème a été corrigé six heures après la divulgation de l'information sur la vulnérabilité, mais cette vulnérabilité était présente dans NPM plus longtemps que ce que couvrent les journaux de télémétrie. GitHub affirme qu'aucune trace d'attaques utilisant cette vulnérabilité n'a été enregistrée depuis septembre 2020, mais il n'y a aucune garantie que le problème n'ait pas été exploité auparavant.

Le deuxième incident s'est produit le 26 octobre. Lors d'opérations techniques sur la base de données du service replicate.npmjs.com, des données confidentielles révélant des informations sur les noms de paquets internes mentionnés dans le journal des modifications ont été découvertes dans une base de données accessible aux requêtes externes. Ces informations sur de tels noms peuvent être utilisées pour mener des attaques sur des dépendances dans des projets internes (en février, une telle attaque a permis d'exécuter du code sur serveurs PayPal, Microsoft, Apple, Netflix, Uber et encore 30 autres entreprises).

De plus, en raison de la recrudescence des cas de prise de contrôle des dépôts de grands projets et de la propagation de code malveillant par la compromission des comptes des développeurs, GitHub a décidé d'introduire une authentification à deux facteurs obligatoire. Ce changement entrera en vigueur au premier trimestre de 2022 et s'appliquera aux mainteneurs et aux administrateurs de paquets figurant sur la liste des plus populaires. Il est également prévu une modernisation de l'infrastructure, où une surveillance et une analyse automatisées des nouvelles versions des paquets seront mises en place pour détecter rapidement les modifications malveillantes.

Rappelons qu'en vertu d'une étude menée en 2020, seulement 9,27 % des mainteneurs de paquets utilisent l'authentification à deux facteurs pour protéger l'accès, et dans 13,37 % des cas lors de l'enregistrement de nouveaux comptes, les développeurs ont tenté de réutiliser des mots de passe compromis figurant dans des fuites de mots de passe connues. Lors de la vérification de la fiabilité des mots de passe utilisés, il a été possible d'accéder à 12 % des comptes sur NPM (13 % des paquets) en raison de l'utilisation de mots de passe prévisibles et triviaux, tels que « 123456 ». Quatre comptes d'utilisateurs parmi le Top 20 des paquets les plus populaires ont été concernés, ainsi que 13 comptes dont les paquets étaient téléchargés plus de 50 millions de fois par mois, 40 plus de 10 millions de téléchargements par mois et 282 avec plus de 1 million de téléchargements par mois. Compte tenu du téléchargement des modules par chaîne de dépendances, la compromission de comptes non fiables a pu affecter jusqu'à 52 % de tous les modules sur NPM.

Source : opennet.ru