Répertoire .git exposé

Qu'est-ce que Répertoire .git exposé?

Un déploiement qui copie l'arborescence de travail dans une racine Web copie .git avec elle. Ce dossier contient chaque validation et chaque version de chaque fichier, pas seulement ce qui est en direct. Quiconque peut en faire la demande peut reconstruire l'intégralité de l'arborescence des sources, y compris les secrets supprimés lors des validations ultérieures. Vous demanderez /.git/ sur un site en direct, exécuterez git-dumper pour reconstruire la source et en lirez un mot de passe de base de données. Ensuite, vous bloquerez le chemin sur le serveur Web, déploierez les artefacts construits au lieu du référentiel et ferez pivoter ce qui a fui.

Ce que vous apprendrez dans Répertoire .git exposé

• Reconnaître un répertoire .git exposé : un déploiement qui envoie l'intégralité du référentiel à la racine Web transforme une URL publique en une divulgation complète de la source et de l'historique.
• Tracez l'attaque depuis une liste /.git/ consultable et un .git/config lisible, jusqu'à un pull git-dumper qui reconstruit l'arborescence source, jusqu'aux secrets récupérés de la configuration validée.
• Comprenez que .git contient l'intégralité de l'historique des validations, de sorte que les informations d'identification qui ont été modifiées ou supprimées lors des validations ultérieures restent récupérables à partir d'un référentiel exposé.
• Appliquez le correctif durable : déployez les artefacts générés plutôt que le référentiel afin que .git n'atteigne jamais la production et effectuez une rotation de chaque identifiant révélé par l'exposition.
• Distinguer l'exposition côté serveur d'un référentiel sur le Web des secrets présents dans l'historique de validation d'un référentiel hébergé et traiter le blocage de l'URL /.git comme une solution provisoire plutôt que comme un correctif complet.

Répertoire .git exposé — Étapes de la formation

1. Évaluez la cible

   Aujourd'hui, Bob cible Verlune, une société d'analyse de produits dont le tableau de bord fonctionne sur app.verlune.io. Il commence là où n'importe qui pourrait, sur le site public, avoir une idée de ce que l'entreprise expédie avant de chercher un moyen d'y entrer. L’application elle-même ne révèle pas grand-chose. Les erreurs intéressantes se situent généralement dans les chemins auxquels un site n’est jamais censé répondre.

2. Un chemin qui ne devrait pas répondre

   Bob demande /.git/ directement sur le même hôte, un chemin qu'un serveur bien configuré n'exposerait jamais. Au lieu d'un 404, le serveur répond par une liste d'annuaire consultable. Les fichiers internes d'un référentiel Git, HEAD , config , objects , se trouvent tous à la racine Web, servis comme n'importe quelle autre page.

3. C'est un véritable référentiel

   Bob clique sur le fichier config dans la liste. Il est relu comme une configuration Git ordinaire : l'origine distante, la branche par défaut, les paramètres utilisateur. Ce n’est pas un fichier égaré que quelqu’un a laissé derrière lui. L'ensemble du référentiel de travail a été envoyé en production, son historique complet est donc accessible en un seul téléchargement.

4. Reconstruire la source

   Bob ne clique pas manuellement sur la liste. Il pointe un outil de dumping vers le dossier exposé, qui parcourt les objets qu'il sert et reconstruit l'arborescence de travail exactement telle qu'elle existe dans le dépôt. En quelques secondes, il dispose du code source complet de l'application Verlune sur sa propre machine, avec l'historique et tout.

5. Informations d'identification dans la source

   Une fois la source reconstruite, Bob ouvre la configuration de la base de données récupérée. Les éléments les plus précieux d’un dépôt divulgué sont rarement le code lui-même, ce sont les secrets commis à ses côtés. Il n’a pas besoin de chercher attentivement.

6. Un mot de passe et une clé

   Le fichier récupéré transmet à Bob deux secrets en direct en texte brut : la chaîne de connexion à la base de données de production, le mot de passe inclus et une clé API pour l'API d'administration. Les deux ont été validés directement dans la source, c'est pourquoi un référentiel exposé les divulgue.

7. Connectez-vous avec les informations d'identification divulguées

   Une fuite d’informations d’identification n’est qu’une théorie jusqu’à ce qu’elle ouvre quelque chose. La configuration récupérée remet à Bob une chaîne de connexion à la base de données complète, un hôte, un nom, un utilisateur et un mot de passe, afin qu'il ouvre un client SQL et se connecte directement à la base de données de production de Verlune avec celui-ci. Pas d'exploit et pas de session volée : la base de données fait confiance au mot de passe fourni par le référentiel.

8. La table des clients est ouverte

   Connecté. Bob exécute la requête évidente et la table des clients de production revient dans son intégralité : noms, e-mails, forfaits et facturation. Il lit les dossiers clients de Verlune directement depuis la base de données, sans aucun compte personnel.

9. Contrôle des connaissances

   Vous venez de voir une seule URL publique transmettre l’intégralité de l’arborescence des sources et ses secrets. Verrouillez pourquoi.

10. L'alerte de surveillance

    Vous possédez le pipeline de déploiement web de Verlune. Du jour au lendemain, le contrôle de surveillance qui surveille les chemins sensibles en production s'est déclenché : il a récupéré .git/config sur app.verlune.io et a obtenu un 200. Les opérations de sécurité vous ont envoyé le résultat par courrier électronique.