Une vulnérabilité qui permettait de publier une mise à jour pour n'importe quel package du référentiel NPM

GitHub a divulgué deux incidents dans son infrastructure de référentiel de packages NPM. Le 2 novembre, des chercheurs tiers en sécurité (Kajetan Grzybowski et Maciej Piechota), dans le cadre du programme Bug Bounty, ont signalé la présence d'une vulnérabilité dans le référentiel NPM qui vous permet de publier une nouvelle version de n'importe quel package en utilisant votre compte, qui n'est pas autorisé à effectuer de telles mises à jour.

La vulnérabilité est due à des vérifications d'autorisation incorrectes dans le code des microservices qui traitent les requêtes adressées à NPM. Le service d'autorisation a effectué des vérifications d'autorisation du package en fonction des données transmises dans la demande, mais un autre service qui a téléchargé la mise à jour dans le référentiel a déterminé le package à publier en fonction du contenu des métadonnées du package téléchargé. Ainsi, un attaquant pourrait demander la publication d'une mise à jour de son package, auquel il a accès, mais préciser dans le package lui-même des informations sur un autre package, qui serait éventuellement mis à jour.

Le problème a été résolu 6 heures après que la vulnérabilité a été signalée, mais la vulnérabilité était présente dans NPM plus longtemps que ne le couvrent les journaux de télémétrie. GitHub affirme qu'il n'y a eu aucune trace d'attaques utilisant cette vulnérabilité depuis septembre 2020, mais rien ne garantit que le problème n'a pas été exploité auparavant.

Le deuxième incident s'est produit le 26 octobre. Lors de travaux techniques avec la base de données du service replicate.npmjs.com, la présence de données confidentielles dans la base de données accessible aux requêtes externes a été révélée, révélant des informations sur les noms des packages internes mentionnés dans le journal des modifications. Les informations sur ces noms peuvent être utilisées pour mener des attaques de dépendance sur des projets internes (en février, une attaque similaire a permis l'exécution de code sur les serveurs de PayPal, Microsoft, Apple, Netflix, Uber et 30 autres sociétés).

De plus, en raison du nombre croissant de cas de piratage de référentiels de grands projets et de promotion de codes malveillants via la compromission de comptes de développeurs, GitHub a décidé d'introduire une authentification obligatoire à deux facteurs. Le changement entrera en vigueur au premier trimestre 2022 et s’appliquera aux mainteneurs et administrateurs des packages inclus dans la liste les plus populaires. En outre, il est fait état d'une modernisation de l'infrastructure, dans laquelle une surveillance et une analyse automatisées des nouvelles versions des packages seront introduites pour une détection précoce des modifications malveillantes.

Rappelons que, selon une étude menée en 2020, seuls 9.27 % des mainteneurs de packages 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 les mots de passe compromis qui apparaissaient dans fuites de mots de passe connues. Lors d'un examen de la sécurité des mots de passe, 12 % des comptes NPM (13 % des packages) ont été consultés en raison de l'utilisation de mots de passe prévisibles et triviaux tels que « 123456 ». Parmi les plus problématiques figuraient 4 comptes d'utilisateurs du Top 20 des packages les plus populaires, 13 comptes avec des packages téléchargés plus de 50 millions de fois par mois, 40 avec plus de 10 millions de téléchargements par mois et 282 avec plus d'un million de téléchargements par mois. Compte tenu du chargement des modules le long d'une chaîne de dépendances, la compromission de comptes non fiables pourrait affecter jusqu'à 1 % de tous les modules de NPM.

Source: opennet.ru

Ajouter un commentaire