Le dossier qui s'est livré tout seul : un répertoire .git exposé
Le défi
Verdanta déploie sa boutique en lançant git pull sur le serveur web, ce qui est propre jusqu'à ce qu'on remarque que tout le répertoire .git se trouve dans la racine web, servi à quiconque le demande. Un dépôt n'est pas qu'un code source : il garde en mémoire la façon dont il communique avec son origin. Depuis la machine de recon, confirmez que le répertoire est exposé et lisez le fichier qui transforme un déploiement négligent en identifiant volé. Indiquez le token de déploiement qu'il divulgue.
Ce que tu vas apprendre
- Confirmer l'exposition d'un répertoire .git via HTTP
- Lire .git/config et trouver l'URL du remote origin
- Reconnaître des identifiants intégrés dans une URL de clonage comme un secret divulgué
- Expliquer pourquoi un .git exposé divulgue bien plus qu'un seul fichier
- Indiquer comment déployer sans placer .git dans la racine web
Compétences testées
Prérequis
- Utilisation de curl
- Ce qu'est un remote git
Comment ça marche
Déployer en lançant git pull sur le serveur est pratique, mais cela laisse tout le répertoire .git à côté du site. Si ce répertoire se trouve dans la racine web, le serveur livre ses fichiers à quiconque les demande, sans aucune authentification.
.git/config enregistre le remote origin. Quand un dépôt a été cloné en HTTPS avec un nom d'utilisateur et un mot de passe dans l'URL, git écrit cette URL, secret compris, directement dans config. Une seule requête renvoie l'identifiant de déploiement.
C'est pire qu'un seul fichier : .git/objects et les packs permettent à un attaquant de reconstruire tout l'historique, et de récupérer chaque secret déjà commité puis supprimé, chaque chemin interne et chaque version antérieure du code.
Erreurs fréquentes
- S'arrêter à
.git/HEAD. Il confirme l'exposition mais ne donne que le nom de la branche ; l'identifiant se trouve dansconfig. - Lire la racine du site. La page d'accueil est propre ; la fuite se trouve sous
/.git/. - Répondre avec le nom d'utilisateur ou l'hôte.
verdanta-cietgit.verdanta.examplesont du contexte ; le token est la valeur après les deux-points. - Croire qu'il faut tout l'historique. Ici un seul fichier suffit, même si l'historique est lui aussi récupérable.
Comment s'en protéger
Gardez le dépôt hors de l'arborescence servie et renouvelez ce qui a fuité.
- Déployez à partir d'un artefact construit ou d'un export
git archive, ou gardez le checkout de travail en dehors du document root. Ne servez jamais.git. - Bloquez l'accès aux répertoires et fichiers commençant par un point au niveau du serveur web, en défense en profondeur.
- N'intégrez pas d'identifiants dans l'URL d'un remote. Utilisez un credential helper ou une deploy key, et renouvelez tout token qui a déjà été écrit dans une URL.
- Considérez un identifiant qui a atteint
.git/configcomme déjà public.