Clé AWS divulguée : pourquoi masquer le fichier ne suffit pas
Le défi
Une équipe affirme avoir retiré un secret de son dépôt public. Ouvrez les sources et corrélez-les : le fichier de configuration actuel semble nettoyé, mais l'historique des commits et une ancienne sauvegarde racontent une autre histoire. Trouvez l'identifiant de clé d'accès AWS toujours exposé et soumettez-le.
Ce que tu vas apprendre
- Comprendre que masquer un fichier dans un nouveau commit ne supprime pas le secret de l'historique
- Utiliser git log pour retrouver les anciennes révisions d'un fichier
- Afficher un fichier à un commit précis pour récupérer une valeur supprimée
- Corréler une sauvegarde publique sur un paste avec l'historique du dépôt
- Comprendre que la rotation, et non le masquage, est la véritable remédiation
Compétences testées
Prérequis
- Notions de base de git (commits, log, révisions de fichiers)
- Savoir reconnaître l'apparence d'un identifiant de clé d'accès AWS
Comment ça marche
Le contrôle de version est conçu pour être en ajout seul : chaque modification devient un nouveau commit qui s'empile sur les précédents, et l'ancien contenu reste accessible. C'est pourquoi supprimer un secret d'un fichier et commiter cette suppression n'apporte presque aucune sécurité : le commit précédent, avec le secret en clair, est toujours présent dans l'historique que reçoit quiconque clone le dépôt. Les attaquants comme les scanners de sécurité savent qu'il faut d'abord regarder dans l'historique.
Ici, le config.yml actuel affiche des valeurs REDACTED et un commentaire affirmant que les secrets ont été déplacés vers des variables d'environnement dans le commit 4f1a. Le git log révèle ce nettoyage et renvoie au commit initial d33a5f1. L'exécution de git show d33a5f1:config.yml affiche le fichier d'origine, où l'identifiant de clé d'accès AKIA5TQQ3NLEAKED1 est codé en dur en clair. Un Pastebin public intitulé 'prod env backup' confirme indépendamment le même identifiant de clé et reste indexé par les moteurs de recherche, si bien que la fuite existe à deux endroits en même temps.
Le tableau OSINT vous présente chaque artefact sous forme de carte. Le fichier actuel est un leurre : il est réellement nettoyé. La réponse n'apparaît qu'en lisant l'ancienne révision et en la recoupant avec le paste, tous deux affichant AKIA5TQQ3NLEAKED1.
Erreurs fréquentes
- Faire confiance au fichier actuel. Le
config.ymlen cours est masqué ; le secret se trouve dans l'historique, pas dans l'arbre de travail. - Croire le commentaire 'déplacé vers des variables d'environnement'. Ce commentaire décrit le dernier commit, pas ce qui subsiste dans les commits plus anciens.
- Ignorer git log. Sans lister les commits précédents, on ne trouve jamais la révision initiale qui contient la clé.
- Soumettre la clé secrète au lieu de l'identifiant de clé d'accès. La question demande l'identifiant de clé d'accès
AKIA....
Comment s'en protéger
La seule réponse sûre face à un secret commité est de le considérer comme compromis et de le faire tourner immédiatement : masquer le fichier ne sert à rien, car l'ancien commit et tout paste ou miroir conservent toujours la valeur. C'est l'exposition, pas la suppression, qui compte.
- Faites tourner et révoquez la clé divulguée dans AWS IAM dès qu'elle est découverte.
- Purgez le secret de l'historique (filter-repo / BFG) et faites un force-push, mais faites d'abord la rotation : la réécriture de l'historique n'atteint ni les clones, ni les forks, ni les pastes.
- Ajoutez un scanner de secrets en pre-commit et une analyse en CI pour que les clés ne soient jamais commitées.
- Utilisez des identifiants à courte durée de vie ou un gestionnaire de secrets plutôt que de coder les clés en dur.