Des chercheurs en sécurité d’Aqua Nautilus ont révélé que des acteurs malveillants pouvaient mener une attaque temporelle contre l’API de npm afin de découvrir des packages privés.
Cette attaque temporelle visant le gestionnaire de packages JavaScript peut fonctionner même lorsque npm renvoie une erreur 404 aux utilisateurs non autorisés ou non authentifiés qui tentent d’interroger le point de terminaison suivant (modèle générique) :
https://registry.npmjs.org/@<scope_name>/<secret_package_name>
Un attaquant malveillant peut envoyer plusieurs requêtes consécutives afin de déterminer si le package existe ou a été supprimé. Une telle attaque temporelle consiste à comparer « le temps nécessaire pour rechercher un package privé qui existe avec celui nécessaire pour rechercher un package privé qui n’existe pas », a écrit.
Les chercheurs ont découvert qu’il fallait environ cinq requêtes consécutives pour constater que le temps de réponse de l’API est nettement plus long lorsque le package existe ou a été supprimé : 648 ms contre 101 ms. Un tel écart permet d’automatiser le processus de découverte en créant une liste de noms de packages potentiels à tester.
Le problème a été signalé au programme de chasse aux bugs de GitHub en mars 2022, mais la réponse de la plateforme n’est pas rassurante : « En raison de ces limitations architecturales, nous ne pouvons pas empêcher les attaques temporelles de déterminer si un package privé donné existe. »
Voir aussi les meilleurs outils de débogage et de sécurité du code
Comment les hackers peuvent exploiter la faille de conception de l’API
La méthode de Kadkoda est assez simple : il a créé un package npm privé sous une « organisation-aléatoire » et y a téléversé quelques fichiers.
Il a ensuite vérifié que le package existait avec un utilisateur authentifié et autorisé (membre de l’organisation). Il a fait de même avec un utilisateur non authentifié, mais n’a pas constaté de différence notable avec une seule requête consécutive. Ce n’est qu’après cinq requêtes consécutives provenant de « divers systèmes » que les résultats sont devenus significatifs :
Ces informations pourraient être exploitées pour divulguer les noms de packages privés et mener diverses attaques malveillantes, comme le typosquatting ou la confusion de dépendances, afin de pirater la chaîne d’approvisionnement logicielle.
Pour y parvenir, les attaquants pourraient utiliser des dictionnaires génériques ou plus personnalisés contenant des noms qui incluent celui de l’organisation. Il n’est pas rare que les équipes de développement appliquent une convention de nommage pour maintenir leur organisation et leur propreté.
Selon les chercheurs d’Aqua, un attaquant pourrait également utiliser des jeux de données publics pour obtenir une liste de packages publics supprimés qui auraient pu être convertis en packages privés.
Ce n’est certainement pas la première fois que npm (et d’autres plateformes) est confronté à de telles menaces, qui mettent de nombreuses organisations en danger (voir Chaîne d’approvisionnement logicielle : une période risquée pour les dépendances).
« Au cours des dernières années, nous avons constaté une augmentation spectaculaire, de plusieurs centaines de points de pourcentage, des attaques visant les chaînes d’approvisionnement », a écrit Kadkoda. « Dans certains cas, l’objectif des acteurs malveillants est d’accéder à des packages ou projets open source et de les empoisonner. À d’autres moments, ils se font passer pour des packages ou projets privés ou publics, en orthographiant volontairement mal leurs noms afin d’inciter des victimes inattentives à télécharger leur package malveillant plutôt que des packages populaires légitimes. »
Comment se protéger contre l’attaque temporelle de npm
Aqua Nautilus recommande d’enregistrer tous les packages privés et publics, une bonne pratique que l’on peut résumer par « connaître sa chaîne d’approvisionnement ».
Les chercheurs ont également déclaré que les équipes de développement et de sécurité devaient rechercher les packages pratiquant le typosquatting, les imitations ou l’usurpation d’identité.
« Vérifiez qu’aucun autre package ne porte le même nom que vos packages privés internes, ont-ils déclaré. Si vous trouvez des packages similaires, assurez-vous qu’ils ne contiennent pas de logiciels malveillants et avertissez les parties prenantes concernées.
« Si vous ne trouvez pas de packages publics similaires à vos packages internes, envisagez de créer des packages publics comme espaces réservés afin d’empêcher ce type d’attaque. »
Comme les grandes plateformes logicielles sont soumises à de fortes contraintes, la correction d’une conception d’API défaillante et d’autres failles de sécurité peut prendre beaucoup de temps, voire être classée comme « ne sera pas corrigée ». Cela ne signifie toutefois pas que les entreprises doivent renoncer à tous les services tiers et tout gérer elles-mêmes en interne.
- L’approche DIY n’est pas toujours gratifiante, car elle reporte la responsabilité en bout de chaîne sans garantir une meilleure sécurité
- Le coût total augmenterait considérablement et pourrait même transformer l’infrastructure en cauchemar de maintenance et de sécurité
Une autre bonne approche consiste à éviter de multiplier les packages privés, ce qui est très tentant pour les équipes de développement mais ne constitue pas toujours la meilleure solution, car de nombreux utilitaires peuvent être regroupés et remaniés. Par définition, plus vous créez de packages privés, plus vous élargissez la surface d’attaque.
De nombreuses équipes commencent par des outils internes qui pourraient devenir d’excellents packages open source publics, mais il n’est pas nécessaire de tout conserver au même endroit. Personne n’a besoin de l’historique complet. Il suffit de créer un dépôt public portant le même nom et de le laisser vide jusqu’au moment de le partager publiquement.
Vous éviterez ainsi les divulgations indésirables via les commits Git également.
Enfin, prévoyez des procédures documentées pour installer et utiliser les environnements de développement et empêcher les développeurs d’installer (et de valider) des packages. L’ajout, la mise à jour ou la suppression de packages nécessite une revue par l’équipe.
À lire ensuite : Une nouvelle initiative open source de sécurité contre les attaques visant les chaînes d’approvisionnement