Ça fait quelques jours GitHub a révélé deux incidents dans l'infrastructure du référentiel de packages NPM, dont il détaille que le 2 novembre, des chercheurs en sécurité tiers dans le cadre du programme Bug Bounty ont découvert une vulnérabilité dans le référentiel NPM qui permet de publier une nouvelle version de n'importe quel package utilisant même s'il n'est pas autorisé pour effectuer de telles mises à jour.
La vulnérabilité a été causée par des vérifications d'autorisation incorrectes dans le code des microservices qui traitent les demandes au NPM. Le service d'autorisation a effectué une vérification des autorisations sur les packages en fonction des données transmises dans la demande, mais un autre service qui téléchargeait la mise à jour dans le référentiel a déterminé le package à publier en fonction du contenu des métadonnées dans le package téléchargé.
Ainsi, un attaquant pourrait demander la publication d'une mise à jour de son package, auquel il a accès, mais indiquer dans le package lui-même des informations sur un autre package, qui serait éventuellement mis à jour.
Au cours des derniers mois, l'équipe npm a investi dans des améliorations d'infrastructure et de sécurité pour automatiser la surveillance et l'analyse des versions de packages récemment publiées afin d'identifier les logiciels malveillants et autres codes malveillants en temps réel.
Il existe deux catégories principales d'événements de publication de logiciels malveillants qui se produisent dans l'écosystème npm : les logiciels malveillants publiés en raison d'un piratage de compte et les logiciels malveillants que les attaquants publient via leurs propres comptes. Bien que les acquisitions de comptes à fort impact soient relativement rares, par rapport aux logiciels malveillants directs publiés par des attaquants utilisant leurs propres comptes, les acquisitions de comptes peuvent avoir une portée considérable lorsqu'elles ciblent les mainteneurs de packages populaires. Alors que notre temps de détection et de réponse aux acquisitions de packages populaires n'a été que de 10 minutes lors d'incidents récents, nous continuons à faire évoluer nos capacités de détection de logiciels malveillants et nos stratégies de notification vers un modèle de réponse plus proactif.
Le problème il a été corrigé 6 heures après le signalement de la vulnérabilité, mais la vulnérabilité était présente dans NPM plus longtemps que ce que couvrent les journaux de télémétrie. GitHub déclare 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 a eu lieu le 26 octobre. Dans le cadre d'un travail technique avec la base de données du service Replicant.npmjs.com, il a été révélé qu'il y avait des données confidentielles dans la base de données disponibles pour une consultation externe, révélant des informations sur les noms des packages internes mentionnés dans le journal des modifications.
Informations sur ces noms peut être utilisé pour mener des attaques de dépendance sur des projets internes (En février, une telle attaque a permis au code de s'exécuter sur les serveurs de PayPal, Microsoft, Apple, Netflix, Uber et 30 autres sociétés.)
En outre, par rapport à l'incidence croissante de la saisie des dépôts de grands projets et la promotion de codes malveillants via la compromission des comptes de développeurs, GitHub a décidé d'introduire l'authentification obligatoire à deux facteurs. Le changement prendra effet au premier trimestre 2022 et s'appliquera aux mainteneurs et administrateurs des packages inclus dans la liste des plus populaires. En outre, il rend compte de la modernisation de l'infrastructure, qui introduira la surveillance et l'analyse automatisées des nouvelles versions des packages pour la détection précoce des modifications malveillantes.
Rappelons que selon une étude menée en 2020, seuls 9.27 % des gestionnaires 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 des mots de passe compromis qui apparaissent dans des mots de passe connus. .
Lors de la vérification de la force des mots de passe utilisés, 12% des comptes dans NPM (13% des packages) ont été accédés en raison de l'utilisation de mots de passe prévisibles et triviaux tels que "123456". Entre las problemáticas se encontraban 4 cuentas de usuario de los 20 paquetes más populares, 13 cuentas cuyos paquetes se descargaron más de 50 millones de veces al mes, 40 – más de 10 millones de descargas al mes y 282 con más de 1 millón de descargas au mois. Compte tenu de la charge de module le long de la chaîne de dépendances, la compromission des comptes non fiables pourrait affecter jusqu'à 52 % de tous les modules dans NPM au total.
Enfin, si vous souhaitez en savoir plus vous pouvez vérifier les détails dans le lien suivant.