Un jeton d’accès personnel (PAT) appartenant au directeur de l’infrastructure de la Python Software Foundation (PSF) a été exposé pendant plus d’un an. Ce jeton avait des privilèges administratifs pour les référentiels officiels du langage de programmation Python et de l’index des packages Python (PyPI). Malheureusement, il a été accidentellement inclus dans un fichier binaire compilé publié sur Docker Hub.L'équipe de recherche en sécurité de JFrog a récemment découvert et signalé une fuite de jeton d'accès avec un accès administrateur aux dépôts GitHub de Python, PyPI et Python Software Foundation, qui a été divulguée dans un conteneur Docker public hébergé sur Docker Hub.
En tant que service communautaire, l'équipe de recherche en sécurité de JFrog analyse en permanence les dépôts publics tels que Docker Hub, NPM et PyPI afin d'identifier les paquets malveillants et les fuites de secrets. L'équipe signale toute découverte aux responsables concernés avant que les attaquants ne puissent en tirer parti.
« Bien que nous rencontrions de nombreux secrets qui sont divulgués de la même manière, ce cas est exceptionnel car il est difficile de surestimer les conséquences potentielles s'ils étaient tombés entre de mauvaises mains - il serait possible d'injecter du code malveillant dans les paquets PyPI (imaginez que vous remplaciez tous les paquets Python par des paquets malveillants), et même dans le langage Python lui-même », ont écrit dans un rapport les chercheurs de l'entreprise de sécurité JFrog, qui ont trouvé et signalé le jeton.
L'équipe de recherche en sécurité de JFrog a identifié la fuite et l'a immédiatement signalée à l'équipe de sécurité de PyPI, qui a révoqué le jeton en 17 minutes à peine !
L'incident montre que l'élimination des jetons d'accès du code source uniquement, que certains outils de développement effectuent automatiquement, ne suffit pas à prévenir les failles de sécurité potentielles. Des informations d'identification sensibles peuvent également être incluses dans des variables d'environnement, des fichiers de configuration et même des artefacts binaires à la suite de processus de construction automatisés et d'erreurs commises par les développeurs.
Le jeton d'authentification a été trouvé dans un conteneur Docker, dans un fichier Python compilé - __pycache__/build.cpython-311.pyc
Qu'est-ce qui aurait pu se passer ?
Les conséquences de la découverte de cette fuite de jeton pourraient être extrêmement graves. Le détenteur d'un tel jeton aurait eu un accès administrateur à tous les dépôts de Python, de PyPI et de la Python Software Foundation, ce qui aurait permis de mener une attaque de la chaîne d'approvisionnement à très grande échelle.
Différentes formes d'attaques de la chaîne d'approvisionnement étaient possibles dans ce scénario. L'une d'entre elles consisterait à dissimuler un code malveillant dans CPython, qui est un dépôt de certaines des bibliothèques de base du langage de programmation Python, compilées à partir d'un code C. En raison de la popularité de Python, l'insertion d'un code malveillant qui finirait par se retrouver dans les éléments distribuables de Python pourrait signifier la propagation de votre porte dérobée à des dizaines de millions de machines dans le monde entier !
Vecteur d'attaque de la chaîne d'approvisionnement du langage Python
Un autre scénario possible serait l'insertion d'un code malveillant dans le code Warehouse de PyPI, qui est utilisé pour gérer le gestionnaire de paquets PyPI. Imaginons qu'un attaquant insère un code qui lui donne une porte dérobée vers le stockage de PyPI, lui permettant de manipuler des paquets PyPI très populaires, en y cachant du code malveillant ou en les remplaçant complètement. Bien qu'il ne s'agisse pas de la manière la plus sophistiquée de mener une attaque qui resterait longtemps indétectée, il s'agit certainement d'un scénario effrayant.
Vecteur d'attaque de la chaîne d'approvisionnement PyPI
La fuite du jeton Python est le résultat de la paresse
Ee Durbin, administrateur de PyPI et directeur de l'infrastructure de la Python Software Foundation (PSF), a rédigé un rapport d'incident expliquant comment la fuite s'est produite. La fuite concernait le jeton d'accès du compte personnel de Durbin, qui disposait de privilèges administratifs en raison de son rôle dans l'organisation.
Début 2023, Durbin travaillait sur cabotage-app, un outil basé sur Docker développé par la PSF qui est utilisé pour déployer PyPI et les services associés sur un cluster Kubernetes. Alors qu'il travaillait sur la partie construction de la base de code, il s'est heurté aux limites de débit de l'API que GitHub applique pour l'accès anonyme.
Dans ce qu'il appelle « un acte de paresse », Durbin a décidé de modifier le code source localement pour inclure un jeton d'accès pour son propre compte afin de contourner les limites de taux par défaut et de terminer le travail plus rapidement. Il s'agissait d'une solution rapide, une alternative à la configuration d'une application GitHub locale pour effectuer la construction au lieu d'utiliser l'API GitHub.
Alors que Durbin savait que l'ajout de jetons d'accès personnels (PAT) au code source est une mauvaise pratique de sécurité, la modification ne concernait que sa copie locale de la base de code et n'avait jamais été destinée à être transférée à distance. En fait, le script de construction et de déploiement automatisé était censé annuler les modifications locales, ce qui aurait dû supprimer le jeton.
Ce que Durbin n'avait pas réalisé, c'est que le jeton était également inclus dans les fichiers .pyc (Python compiled bytecode) générés dans le cadre du processus de construction, et que ces fichiers, stockés dans le dossier __pycache__, n'étaient pas configurés pour être exclus de l'image Docker finale téléchargée sur Docker Hub.
Après avoir été informée par JFrog à la fin du mois de juin, l'équipe de sécurité de PyPI a révoqué le jeton et a examiné tous les journaux d'audit de GitHub et l'activité du compte à la recherche d'éventuels signes d'utilisation malveillante du jeton. Aucune preuve d'utilisation malveillante n'a été trouvée. La version de cabotage-app contenant le jeton a été publiée sur Docker Hub le 3 mars 2023 et a été supprimée le 21 juin 2024, soit quinze mois plus tard.
« Cabotage est maintenant entièrement auto-hébergé, ce qui signifie que les constructions de l'application cabotage n'utilisent plus de registre public et que les constructions de déploiement sont initiées à partir de vérifications propres de la source uniquement », a écrit Durbin. « Cela permet d'éviter que des modifications locales ne se retrouvent dans une image construite en dehors des environnements de développement, et de supprimer la nécessité de publier dans des registres publics ».
Durbin a déclaré qu'il évitera à l'avenir de créer des jetons d'accès personnels pour son compte, sauf en cas d'absolue nécessité, car à part ce cas, il ne se souvient pas d'autres cas où un jeton de longue durée de vie a été utile.
« C'est un excellent rappel pour fixer des dates d'expiration agressives pour les jetons d'API (si vous en avez besoin), traiter les fichiers .pyc comme s'il s'agissait de code source, et effectuer des constructions sur des systèmes automatisés à partir d'une source propre uniquement », a-t-il conseillé.
JFrog a félicité l'équipe de sécurité de PyPI pour avoir répondu à son rapport et révoqué le jeton dans un délai impressionnant de 17 minutes. Bien qu'une sécurité parfaite ne soit jamais possible, il est essentiel de disposer d'un point de contact clair pour les problèmes de sécurité et d'un temps de réponse rapide afin de limiter l'impact des incidents de sécurité pour toute organisation.
Conseils aux développeurs
Outre l'analyse des artefacts binaires et des fichiers de configuration à la recherche de secrets potentiels, les développeurs devraient utiliser les nouveaux jetons d'accès personnel à grain fin de GitHub qui ont été introduits il y a deux ans au lieu des jetons classiques. Les nouveaux jetons permettent aux utilisateurs de choisir les niveaux de privilèges et les dépôts spécifiques auxquels ils donnent accès.
« La création d'un "anneau unique" est toujours une mauvaise idée », écrivent les chercheurs de JFrog dans leur rapport. « Nous recommandons vivement d'utiliser cette fonctionnalité, car nous rencontrons fréquemment des situations où un jeton donnant un accès ultime à l'ensemble de l'infrastructure est divulgué dans le cadre d'un projet secondaire ou d'une application temporaire de type 'hello-world'. »
En outre, depuis 2021, les jetons GitHub ont un nouveau format qui inclut un préfixe ghp_ et une somme de contrôle, ce qui facilite leur détection par des outils automatisés. Les anciens jetons GitHub, qui n'ont pas été dépréciés et existent toujours, ne se distinguent pas des hachages SHA1, qui sont également courants dans le code source et ne présentent pas de risque pour la sécurité, et peuvent donc être ignorés par les scanners. Il est fortement conseillé aux développeurs de passer au nouveau format de jeton.
Conclusion
La fuite de jeton GitHub Python nous rappelle que la sécurité est un aspect essentiel du développement logiciel. En suivant les bonnes pratiques et en restant vigilants, nous pouvons protéger nos projets et nos utilisateurs contre de telles vulnérabilités. Bien sûr, le risque zéro n'est que chimère, mais appliquer de bonnes pratiques contribue à renforcer la sécurité.
Sources : JFrog, Ee Durbin
Et vous ?
Pensez-vous que les développeurs accordent suffisamment d’attention à la sécurité des secrets et des jetons d’accès dans leurs projets ? Quelles mesures supplémentaires pourraient être prises pour éviter de telles fuites de jetons à l’avenir ? Pensez-vous que les fichiers binaires devraient être systématiquement vérifiés pour la présence de secrets et de jetons ? Pourquoi ou pourquoi pas ? Comment percevez-vous la responsabilité du directeur de l’infrastructure de la PSF dans cette fuite de jeton ? Avez-vous déjà rencontré des problèmes de sécurité liés à des secrets ou des jetons dans vos propres projets ? Comment les avez-vous résolus ?