Lion Cipher Lab
Recover source and secrets from an exposed .git directory, then lock it down
- Penetration Testing / Red Team
- Intermediate
- ~60 min
- Free · no account required
Why it matters
This is one of those findings that sounds obscure and turns out to be everywhere. A team sets up a server, they `git clone` the project straight into the web directory to deploy it, and they never think about the hidden `.git` folder that came along for the ride. That folder is now served to the whole internet -- and because git keeps the complete history of the project inside it, an attacker does not get one leaked file, they get the entire source code, every configuration file, and crucially every secret that was ever committed, including ones a developer thought they had deleted. Scanners…
What you'll learn
- recognising the single tell that a web server is leaking its version-control directory: `GET /.git/HEAD` returns a `ref: refs/heads/...` line instead of a 404
- understanding WHY this is catastrophic: git stores the entire project history inside `.git`, so an exposed `.git` is not one file leaking -- it is every file, every past version, and every secret ever committed
- reconstructing a whole source tree from an exposed `.git` directory two ways: with the git-dumper tool for speed, and by hand with git plumbing so you understand what the tool does
- reading git's internal storage well enough to explain it: objects (blobs, trees, commits) addressed by their SHA-1 hash, refs, the index, packfiles, and HEAD
- proving the deeper danger: a secret that was committed and then 'removed' in a later commit is still fully recoverable from history with `git log -p` or by grepping across every commit
- the correct, ordered remediation: stop deploying the repo itself, block `.git` at the web server, and -- the non-negotiable step -- ROTATE any secret that was ever exposed, because blocking access does not un-leak what already leaked
- writing the actual web-server rules that deny access to dotfiles/.git (nginx and Apache), and re-measuring that `/.git/HEAD` now returns 404/403
- the judgment of why purging a secret from history (git filter-repo / BFG) is necessary but not sufficient on its own -- rotation comes first because you must assume the old value is already in someone's hands
- placing the exposure on the standard references -- CWE-527 (Exposure of Version-Control Repository) and CWE-540 (Information Exposure Through Source Code) -- and the OWASP testing step it maps to (reviewing web-server metafiles for information leakage)
Steps in this lab
- The problem in one breath, and why history is the sting
- Build the vulnerable target: a repo with a 'deleted' secret
- Serve it like a misconfigured deploy
- Discovery — the one request that confirms it
- Reconstruct it the fast way — git-dumper
- Reconstruct it by hand — so you know what the tool did
- The payoff — recover the 'deleted' secret from history
- HARDEN — block .git at the web server, then re-measure
- The remediation in the RIGHT order — and the honest limits