Secrets GitHub: les fichiers supprimés présentent toujours des risques

Lucas Morel

En tirant parti des fonctionnalités de contrôle de version de Git, on peut récupérer des fichiers supprimés et le contenu sensible à l’intérieur.

Les fichiers supprimés dans les référentiels publics GitHub pourraient toujours exposer des secrets comme les clés d’API, les jetons et les références, si les acteurs de la menace savaient où et comment chercher.

La chercheuse en cybersécurité Sharon Brizinov a exploité les fonctionnalités de contrôle de la version de Git pour récupérer les secrets exposés de ces fichiers supprimés.

Git, un outil de contrôle de version open source que les développeurs utilisent pour collaborer sur des projets de codage, est exécuté sur le cloud par la plate-forme à rémunération de Github.

« J’ai construit une automatisation qui a cloné et scanné des dizaines de milliers de références publiques Github pour des secrets divulgués », a déclaré Brizinov dans un article de blog. « Pour chaque référentiel, j’ai restauré des fichiers supprimés, trouvé des blobs pendants et déballé les fichiers .pack pour rechercher en eux des (secrets). »

Brizinov a fait 64 000 $ en gains de primes de bogues pour avoir trouvé des dizaines de référentiels appartenant aux sociétés Fortune 500 qui fuyent plus de centaines de secrets de cette façon.

L’histoire de Git conserve des fichiers même après la suppression

Selon la découverte, Git conserve un historique complet des modifications, ce qui signifie que les fichiers supprimés et leur contenu sont toujours accessibles à moins d’être correctement purgés. «Les développeurs oublient souvent que l’histoire du GIT conserve tout, même après que les fichiers soient supprimés du répertoire de travail», a noté Brizinov.

Lorsque les fichiers sont supprimés dans GIT, ils disparaissent de la dernière version mais persistent souvent dans l’historique du référentiel. GIT stocke tous les commits passés – y compris ceux qui ont des fichiers supprimés – dans sa base de données d’objets internes, en gardant des données «pendantes» même si elles ne sont plus liées à une branche.

Brizinov a construit un outil automatisé pour découvrir ces restes cachés. En comparant les commits, en déballant les fichiers internes de Git et en scannant des données non référencées, il a récupéré des fichiers supprimés contenant des secrets exposés.

« Pour collecter tous les fichiers supprimés, j’ai parcouru tous les commits et pour chaque engagement, j’ai comparé (en utilisant) la liste des fichiers avec sa validation parent », a déclaré Briznov. Une fois les fichiers supprimés restaurés, une simple recherche de secrets qui était encore active a été effectuée via une autre automatisation.