Blootgestelde .git-directory

Wat is Blootgestelde .git-directory?

Een implementatie die de werkboom naar een webroot kopieert, kopieert .git ermee. Die map bevat elke commit en elke versie van elk bestand, niet alleen wat live is. Iedereen die erom kan vragen, kan de hele bronboom opnieuw opbouwen, inclusief de geheimen die in latere commits zijn verwijderd. Je vraagt ​​/.git/ aan op een live site, voert git-dumper uit om de broncode te reconstrueren en leest er een databasewachtwoord uit. Vervolgens blokkeert u het pad op de webserver, implementeert u ingebouwde artefacten in plaats van de repository en roteert u wat is gelekt.

Wat je leert in Blootgestelde .git-directory

• Herken een blootgestelde .git-map: een implementatie die de hele repository naar de webroot verzendt, verandert een openbare URL in een volledige openbaarmaking van de bron en geschiedenis
• Traceer de aanval van een doorzoekbare /.git/-lijst en een leesbare .git/config, naar een git-dumper-pull die de bronboom reconstrueert, naar geheimen die zijn hersteld uit de vastgelegde configuratie
• Begrijp dat .git de volledige commitgeschiedenis bevat, zodat inloggegevens die bij latere commits zijn gewijzigd of verwijderd, herstelbaar blijven vanuit een blootgestelde repository
• Pas de duurzame oplossing toe: implementeer ingebouwde artefacten in plaats van de repository, zodat .git nooit de productie bereikt, en roteer alle referenties die de blootstelling onthulde
• Maak onderscheid tussen de blootstelling aan de serverzijde van een repository via internet en geheimen die zich in de commitgeschiedenis van een gehoste repository bevinden, en behandel het blokkeren van de /.git-URL als een noodoplossing in plaats van als een volledige oplossing

Blootgestelde .git-directory — Trainingsstappen

1. Maak het doel groter

   Vandaag richt Bob zich op Verlune, een productanalysebedrijf waarvan het dashboard draait op app.verlune.io. Hij begint waar iedereen dat zou doen, op de openbare site, om een idee te krijgen van wat het bedrijf verzendt voordat hij een manier zoekt om binnen te komen. De app zelf geeft weinig weg. De interessante fouten bevinden zich meestal in de paden die een site nooit wilde beantwoorden.

2. Een pad dat niet zou moeten antwoorden

   Bob vraagt /.git/ rechtstreeks op dezelfde host aan, een pad dat een goed geconfigureerde server nooit zou blootleggen. In plaats van een 404 antwoordt de server met een doorzoekbare directorylijst. De interne bestanden van een Git-repository, HEAD , config , objects , bevinden zich allemaal in de webroot en worden net als elke andere pagina bediend.

3. Het is een echte bewaarplaats

   Bob klikt op het config -bestand in de lijst. Het leest terug als een gewone Git-configuratie: de externe oorsprong, de standaardbranch, de gebruikersinstellingen. Dit is geen verdwaald dossier dat iemand heeft achtergelaten. De hele werkende repository is naar productie verzonden, dus de volledige geschiedenis is één download verwijderd.

4. Reconstrueer de bron

   Bob klikt niet met de hand door de lijst. Hij richt een dumptool op de blootgestelde map, die de objecten die hij bedient doorloopt en de werkboom precies opnieuw opbouwt zoals deze in de repository bestaat. Binnen enkele seconden heeft hij de volledige bron van Verlune's app op zijn eigen machine, met geschiedenis en zo.

5. Referenties in de bron

   Nu de bron opnieuw is opgebouwd, opent Bob de herstelde databaseconfiguratie. De meest waardevolle dingen in een gelekte repository zijn zelden de code zelf; het zijn de geheimen die ernaast worden vastgelegd. Hij hoeft niet hard te kijken.

6. Een wachtwoord en een sleutel

   Het herstelde bestand overhandigt Bob twee live geheimen in platte tekst: de verbindingsreeks van de productiedatabase, inclusief wachtwoord en een API-sleutel voor de admin-API. Beide zijn rechtstreeks in de bron opgenomen, wat de reden is dat een blootgestelde repository ze lekt.

7. Maak verbinding met de gelekte inloggegevens

   Een gelekt credential is slechts een theorie totdat het iets opent. De herstelde configuratie geeft Bob een volledige databaseverbindingsreeks, host, naam, gebruiker en wachtwoord, dus hij opent een SQL-client en maakt daarmee rechtstreeks verbinding met de productiedatabase van Verlune. Geen exploit en geen gestolen sessie: de database vertrouwt op het wachtwoord dat de repository heeft weggegeven.

8. De klantentafel is geopend

   Verbonden. Bob voert de voor de hand liggende zoekopdracht uit en de tabel met productieklanten komt volledig terug: namen, e-mails, plannen en facturering. Hij leest de live klantgegevens van Verlune rechtstreeks uit de database, zonder dat hij zelf een account heeft.

9. Kennis check

   Je hebt zojuist gezien hoe een enkele openbare URL de hele bronboom en zijn geheimen overhandigde. Leg vast waarom.

10. Het monitoringalarm

    U bent eigenaar van de webimplementatiepijplijn van Verlune. Van de ene op de andere dag werd de monitoringcontrole die waakt over gevoelige paden tijdens de productie geactiveerd: hij haalde .git/config op app.verlune.io op en kreeg een 200. Beveiligingsoperaties stuurden je de bevindingen per e-mail.