Le plus grand registre de logiciels de packages Node.js, npm, a révélé plusieurs failles de sécurité qui ont été identifiées et corrigées récemment.
La première faille concerne la fuite de noms de packages npm privés sur le serveur ‘réplique’ de npmjs.com, dont les flux sont consommés par des services tiers.
Alors que la deuxième faille permet aux attaquants de publier de nouvelles versions de tout package npm existant dont ils ne possèdent pas ou n’ont pas les droits, en raison de contrôles d’autorisation inappropriés.
Les noms de packages npm privés ont été divulgués
Cette semaine, la société mère de npm, GitHub, a révélé deux failles de sécurité qui ont été identifiées et résolues dans le registre npm entre octobre et ce mois-ci.
Le premier est une fuite de données sur le serveur de réplication de npmjs, causée par une « maintenance de routine ». La fuite a exposé une liste de noms de packages npm privés, mais pas le contenu de ces packages pendant la fenêtre de maintenance.
« Pendant la maintenance de la base de données qui alimente la réplique publique npm à répliquer.npmjs.com, des enregistrements ont été créés qui pourraient exposer les noms de packages privés », déclare Mike Hanley, responsable de la sécurité de GitHub dans un article de blog.
« Cela a brièvement permis aux consommateurs de répliquer.npmjs.com pour potentiellement identifier les noms de packages privés en raison d’enregistrements publiés dans le flux de modifications public. Aucune autre information, y compris le contenu de ces forfaits privés, n’a été accessible à aucun moment. »
Notez que bien que le contenu des packages privés n’ait pas été exposé, la connaissance des noms des packages privés est suffisante pour que les acteurs malveillants mènent des attaques ciblées de confusion de dépendance et de typosquatting de manière automatisée, comme nous l’avons vu à maintes reprises.
La fuite concerne spécifiquement les bibliothèques npm privées étendues qui ressemblent à « @propriétaire/paquet » et ont été créés avant le 20 octobre. Les noms de ces bibliothèques ont été exposés « entre le 21 octobre 13:12:10Z UTC et le 29 octobre 15:51:00Z UTC », selon GitHub.
La fuite de données a été identifiée par GitHub le 26 octobre et le 29, tous les enregistrements contenant des noms de packages privés ont été supprimés de la base de données de réplication du npm. Bien que GitHub prévienne que malgré cela, le répliquer.npmjs.com le service est consommé par des tiers qui peuvent donc continuer à en conserver une copie ou « avoir répliqué les données ailleurs ».
Pour éviter qu’un tel problème ne se reproduise, GitHub a apporté des modifications à son processus de génération de la base de données de réplication publique, ce qui devrait éliminer la possibilité de fuite de noms de packages privés à l’avenir.
Une faille pourrait permettre la publication non autorisée de nouvelles versions
De plus, GitHub a révélé un bug sérieux qui pourrait « permettre à un attaquant de publier de nouvelles versions de n’importe quel package npm en utilisant un compte sans autorisation appropriée ».
Cette vulnérabilité était due à des contrôles d’autorisation et à une validation de données inappropriés entre plusieurs microservices qui traitent les demandes adressées au registre npm.
« Dans cette architecture, le service d’autorisation validait correctement l’autorisation de l’utilisateur pour les packages en fonction des données transmises dans les chemins d’URL de demande. Cependant, le service qui effectue les mises à jour sous-jacentes des données du registre a déterminé quel package publier en fonction du contenu du fichier de package téléchargé « , explique Hanley.
« Cette divergence a fourni un moyen par lequel les demandes de publication de nouvelles versions d’un package seraient autorisées pour un package, mais seraient en fait effectuées pour un package différent et potentiellement non autorisé. Nous avons atténué ce problème en assurant la cohérence à la fois entre le service de publication et service d’autorisation pour s’assurer que le même package est utilisé à la fois pour l’autorisation et la publication. »
Des chercheurs Kajetan Grzybowski et Maciej Piechota ont été crédités pour avoir signalé la faille de manière responsable via GitHub programme de prime de bug de sécurité.
Et, jusqu’à présent, il semble qu’il n’y ait aucune preuve d’exploitation. La vulnérabilité existait dans le registre npm « au-delà de la période pour laquelle nous avons la télémétrie pour déterminer si elle a déjà été exploitée de manière malveillante », mais il y a une certaine assurance.
GitHub a déclaré avec une grande certitude que la vulnérabilité n’a pas été exploitée de manière malveillante depuis au moins septembre 2020, soit à peu près au moment où la télémétrie est devenue disponible.
« Nous avons rapidement validé le rapport, commencé nos processus de réponse aux incidents et corrigé la vulnérabilité dans les six heures suivant la réception du rapport », déclare GitHub.
npm exigera une authentification à deux facteurs à partir de 2022
Les deux annonces interviennent peu de temps après que les bibliothèques npm populaires, « ua-parser-js », « coa » et « rc » aient été détournées dans une série d’attaques visant à infecter les consommateurs de logiciels open source avec des chevaux de Troie et des crypto-mineurs.
Ces attaques ont été attribuées à la compromission des comptes npm [1, 2] appartenant aux mainteneurs derrière ces bibliothèques. Aucun des responsables de ces bibliothèques populaires n’avait activé l’authentification à deux facteurs (2FA) sur leurs comptes, selon GitHub.
Les attaquants qui parviennent à pirater les comptes npm des responsables peuvent publier de manière triviale de nouvelles versions de ces packages légitimes, après les avoir contaminés par des logiciels malveillants.
En tant que tel, pour minimiser la possibilité que de tels compromis se reproduisent dans un avenir proche, GitHub commencera à exiger des mainteneurs npm pour activer 2FA, au cours du premier trimestre 2022.
En ce qui concerne les cas où des logiciels malveillants de typosquattage et de confusion de dépendance sont publiés sur npm à partir d’un compte appartenant à un attaquant, plutôt que d’un compte piraté, GitHub continue d’investir dans des ressources et des améliorations de sécurité pour automatiser la détection de logiciels malveillants en temps réel dans les versions nouvellement publiées des packages npm. .