Supprimer une clé qui a fait l'objet d'une fuite de votre dépôt ne vous protège pas

En bref : si vous divulguez un secret, modifiez-le immédiatement. Supprimer un fichier, réécrire l'historique des commits Git ou supprimer votre dépôt ne vous protégera pas. Les pirates parcourent régulièrement Internet à la recherche de secrets ; partez donc du principe qu'ils en possèdent déjà une copie. Utilisez Betterleaks ou Aikido détection de secrets pour détecter les secrets divulgués dans vos dépôts, et Aikido Device Protection pour les détecter sur les machines des développeurs.

En mai, les développeurs de LiteLLM ont accidentellement enregistré une clé d'administration dans un dépôt GitHub public. Des pirates ont utilisé ces identifiants pour compromettre leur infrastructure quelques mois plus tard.

Le rapport d'analyse rétrospective de LiteLLM retrace la chronologie des mesures prises pour remédier à la fuite. Une phrase de ce rapport a particulièrement retenu mon attention :

« Environ trois heures plus tard, une modification ultérieure a supprimé le fichier [à l'origine de la fuite], et il a été noté que les clés devaient être révoquées ; toutefois, la modification initiale est restée dans l'historique public du dépôt jusqu'au 22 octobre. »

LiteLLM a détecté la fuite en moins de trois heures. Leur première mesure corrective a consisté à envoyer cette Pull Request, qui se contentait de supprimer le fichier. Quelques mois plus tard, le 22 octobre, ils ont réécrit l'historique Git afin de supprimer les commits à l'origine de la fuite des identifiants.

Ces deux actions, bien que courantes, reflètent des idées fausses répandues chez les développeurs concernant les fuites d’informations confidentielles dans l’historique Git. Aucune des deux mesures prises par LiteLLM n’empêche en réalité quiconque de consulter les données divulguées. En effet, le commit ayant divulgué les identifiants est toujours visible aujourd’hui (ne vous inquiétez pas, ils les ont depuis modifiés !).

La seule façon de remédier définitivement à la fuite d'un identifiant est de le changer. Une fois rendu public, cet identifiant n'est plus un secret et ne le redeviendra plus jamais.

Idées reçues courantes concernant les fuites de secrets dans Git

Les expériences ci-dessous testent chacune une « solution » courante pour remédier aux fuites de secrets dans les dépôts Git :

• Supprimer le fichier
• Réécrire l'historique Git
• Supprimer le dépôt

Aucune de ces mesures ne vous protège totalement contre le risque que des acteurs malveillants découvrent et exploitent un secret que vous auriez divulgué, même si celui-ci n'est resté accessible au public que quelques minutes.

Idée reçue n° 1 : supprimer le fichier

LiteLLM a adopté cette approche dès la découverte de la fuite, ce qui constitue sans doute la réaction la plus courante. Le développeur a identifié une erreur dans son code et l’a donc « corrigée » en supprimant le fichier incriminé lors d’un nouveau commit. Comme nous le verrons ci-dessous, les scanners de données confidentielles analysent l’historique Git et passent au crible les fichiers supprimés.

1. Créez un nouveau dépôt Git local. Validez un fichier README. Puis validez un fichier contenant un secret.

mkdir tmp_repo
cd tmp_repo
git init
echo « # README » > README.md
git add README.md
git commit -m « commit initial »
# fausse clé divulguée
echo « secret_token=ZQ5Cl16U8kmc4uOxS581xDWr » > file.txt
git add file.txt
git commit -m "divulgation d'un secret dans file.txt"

2. Supprime ce fichier. Valide à nouveau.

rm fichier.txt
git add .
git commit -m « suppression d'une information confidentielle exposée dans le fichier file.txt »

3. Effectuez une analyse avec Betterleaks. Vous verrez qu'il détecte un secret dans l'historique Git. (Instructions pour configurer Betterleaks sur la page GitHub.)

betterleaks git .

Idée reçue n° 2 : réécrire l'historique Git

La réaction instinctive suivante consiste généralement à « effacer » la fuite de l’historique Git. LiteLLM s’y est essayé le 22 octobre en effectuant un « force push » d’un historique réécrit qui exclut les commits concernés. À première vue, cela semble fonctionner, puisque ces commits ne sont accessibles depuis aucune branche. Malheureusement, GitHub continue de mettre à disposition les commits « supprimés » à toute personne disposant de leur hachage SHA-1.

1. Notez la valeur SHA-1 du commit au cours duquel vous avez divulgué le secret.

git log --format=%H --grep="divulgation d'un secret dans le fichier file.txt" -1

Remarque : les hachages SHA-1 comportent 40 caractères, ce qui est bien trop long pour être deviné. Cependant, GitHub permet aux utilisateurs de fournir une version abrégée dans son interface utilisateur, qui renvoie au hachage complet de 40 caractères. La version abrégée peut comporter aussi peu que 4 caractères (0-9a-f), ce qui rend ces hachages plus faciles à repérer.

2. Publiez le dépôt local ci-dessus sur GitHub. (Créez le dépôt sur le site web de GitHub si la première commande ne fonctionne pas.)

git remote add origin https://github.com/<github-username>/tmp_repo.git
git branch -M main
git push -u origin main

3. Réinitialisez votre tête Git au premier commit. Effectuez un push forcé vers GitHub.

git reset HEAD~2 --hard
git push --force

Remarque : il existe différentes façons de réécrire l'historique des commits. Il s'agit ici d'une simple démonstration ; nous nous contentons donc de réinitialiser notre dépôt à son tout premier commit, puis d'effectuer un « force push ».

4. Supprimez votre dépôt local.

cd ..
# rm -r tmp_repo # vérifiez bien le nom de votre répertoire avant d'exécuter la commande cette commande

5. Clonez la télécommande.

git clone https://github.com/<user>/tmp_repo.git
cd tmp_repo

6. Consultez l'historique Git de la version clonée. Un seul commit y apparaîtra.

git log

7. Récupérez votre commit « supprimé » directement depuis GitHub. Affichez le fichier « supprimé ».

git fetch origin <sha1_hash_from_step_1>
git checkout <sha1_hash_from_step_1>
cat file.txt

Si vous accédez au commit « supprimé » dans le navigateur, vous verrez apparaître en haut de la page une bannière indiquant « Ce commit n'appartient à aucune branche de ce dépôt… », mais nous pouvons tout de même le voir.

https://github.com/<user>/tmp_repo/commit/<sha1_hash_from_step_1>

Idée reçue n° 3 : supprimer le dépôt

En dernier recours, les développeurs suppriment souvent l'intégralité du dépôt. Malheureusement, cela ne suffit pas non plus. D'une part, vous n'avez aucune visibilité sur les personnes qui ont cloné votre dépôt. D'autre part, si quelqu'un a créé un fork de votre dépôt, GitHub conservera indéfiniment une copie de votre commit « supprimé ».

1. Demande à un ami de créer un fork du dépôt que nous avons créé plus haut.
2. Supprimez votre dépôt.
3. Accédez au commit supprimé (via son hachage) dans la version dérivée de votre ami.

https://github.com/<friend>/tmp_repo/commit/<sha1_hash_from_step_1>

Le commit contenant vos données divulguées restera indéfiniment sur GitHub jusqu'à ce que la dernière branche dérivée soit supprimée.

Et si personne ne l'avait vu ?

Si ces expériences ne suffisent pas à vous convaincre de la nécessité de renouveler régulièrement un identifiant accessible au public, regardez notre collègue Mackenzie divulguer une clé en direct lors d’une conférence, puis constatez combien d’acteurs malveillants ont analysé sa clé en l’espace de quelques minutes seulement. Les chercheurs, les plateformes SaaS/Cloud s et les acteurs malveillants recherchent sans cesse des informations confidentielles. Partez du principe qu’à la seconde où une information est rendue publique, quelqu’un l’a déjà vue.

Changez régulièrement la position de vos clés visibles

La suppression d'un fichier, la réécriture de l'historique et la suppression d'un dépôt laissent tous un secret divulgué accessible. La seule mesure qui protège pleinement votre compte est la rotation des identifiants :

• annuler celui qui a fait l'objet d'une fuite
• en délivrer un nouveau
• mettre à jour partout où l'ancienne version était utilisée

Si la rotation des identifiants permet d'empêcher toute utilisation abusive future, elle ne résout en rien les abus déjà commis, et une clé divulguée peut rester inactive pendant des mois avant que quelqu'un ne la découvre. La clé de LiteLLM est restée active pendant plus de quatre mois avant qu'un pirate ne s'en serve pour récupérer un jeton GitHub et publier une version malveillante.

Une fois que vous avez tourné la clé, vérifiez s'il y a des signes indiquant que l'ancienne clé a déjà été utilisée :

• Les journaux d'utilisation et d'accès propres à la clé ou au jeton
• Commits récents sur la branche principale et toutes les branches protégées
• Modifications apportées à la configuration de l'intégration continue (CI) et du flux de travail, ainsi que les dernières exécutions du pipeline

Si vous ne pouvez pas exclure la possibilité d'une utilisation abusive, considérez cela comme un incident.

Comment « Aikido » peut vous aider

Aikido vous aide à vérifier si des informations confidentielles ont fuité. Les clients bénéficient de la fonctionnalité « détection de secrets » intégrée à la plateforme Aikido , et tout le monde peut utiliser Betterleaks, le moteur open source gratuit qui la fait fonctionner.

Aikido détection de secrets et la protection des appareils

Connectez vos dépôts GitHub, GitLab, Bitbucket ou Azure DevOps, qu'ils soient publics ou privés, et Aikido détection de secrets vérifie s’ils contiennent des clés API, des mots de passe, des jetons et d’autres identifiants exposés. Par défaut, l’outil analyse le code actuel, mais vous pouvez activer la vérification complète de l’historique Git pour détecter les secrets qui ont été ajoutés puis supprimés, comme le fichier supprimé évoqué dans l’idée reçue n° 1.

Le moteur Betterleaks associe des modèles d'identifiants connus à des techniques permettant de détecter des secrets génériques. Pour les types d'identifiants pris en charge, la fonctionnalité « Live Secret Detection » vérifie si un secret divulgué est toujours actif et ajuste la gravité du problème en conséquence. La fonctionnalité « Secrets AutoTriage » utilise le contexte pour distinguer les identifiants réels des valeurs d'exemple ou de test.

Aikido Il signale également les secrets dès les premières phases du développement. Des extensions IDE et un hook « pre-commit » avertissent les développeurs avant qu’un secret ne soit intégré à une validation. Dans le cadre du CI/CD, les « Aikido » peuvent bloquer une compilation ou une « PR » qui en contient un.

Aikido La protection des appareils ajoute une couche de sécurité supplémentaire sur les machines des développeurs. Son agent analyse les fichiers locaux de l'appareil, tels que l'historique du shell, à la recherche de secrets codés en dur. Le contenu des fichiers reste sur l'appareil. Lorsque l'agent détecte un secret, Aikido reçoit le type de secret ainsi que quelques caractères de sa valeur, suffisants pour identifier la découverte.

Betterleaks

Tout le monde peut utiliser Betterleaks de manière autonome. Aikido parraine le projet, qui est disponible gratuitement sous licence MIT. L'auteur original de Gitleaks l'a conçu pour remplacer directement Gitleaks.

Rappel : quel que soit l'outil qui détecte une fuite de secret, procédez à sa rotation. Aikido signale les identifiants actifs et recommande de les faire tourner ; révoquez-les et remplacez-les auprès du service qui les a émis. La suppression du secret de votre dernier commit ne le fait pas disparaître de l'historique Git, comme le montrent les expériences ci-dessus.