Un checkout de contrôle de version transporte bien plus que les fichiers actuels : un historique complet de chaque changement, la configuration qui pilote l'outillage et, très souvent, des identifiants qui ont été commités une fois puis « retirés » plus tard mais qui restent toujours dans le store d'objets. La valeur offensive vient de trois directions : reconstruire le code source et les secrets depuis un répertoire de métadonnées qu'un serveur web a exposé par accident, atteindre un serveur de dépôt qui autorise l'accès anonyme, et transformer un clone ou un push en exécution de code via les hooks et la config que le VCS exécute automatiquement.
Ce domaine couvre les outils de contrôle de version eux-mêmes. Les forges d'hébergement de code en SaaS (GitHub, GitLab, Bitbucket) sont attaquées comme des services hébergés par un fournisseur sous Online > Forges.
Triage#
# A web root that leaked its VCS metadata directory
curl -s -o /dev/null -w '%{http_code}\n' https://<target>/.git/HEAD # 200 => exposed .git
curl -s -o /dev/null -w '%{http_code}\n' https://<target>/.svn/wc.db # 200 => exposed .svn (>=1.7)
# A reachable repository server
nmap -p9418,3690 -sV <target> # 9418 git:// 3690 svn://
Un .git/.svn lisible via HTTP mène aux pages de récupération propres à chaque outil ; un service git:// ou svn:// ouvert mène aux pages de protocole serveur ; un dépôt que vous pouvez cloner ou vers lequel vous pouvez pousser mène aux pages de hooks et de config.
Sous-thèmes#
- Git : récupérer un
.gitexposé, miner les secrets de l'historique, le démongit://non authentifié et l'exécution de code via les hooks et la config au moment du clone. - SVN : récupérer une copie de travail
.svnexposée, et atteindre l'historique et les identifiants Subversion.