A version-control checkout carries far more than the current files: a complete history of every change, the configuration that drives tooling, and, very often, credentials that were committed once and "removed" later but still sit in the object store. Offensive value comes in three directions: reconstructing source and secrets from a metadata directory a web server exposed by accident, reaching a repository server that allows anonymous access, and turning a clone or a push into code execution through the hooks and config the VCS runs automatically.
This area covers the version-control tools themselves. The SaaS code-hosting forges (GitHub, GitLab, Bitbucket) are attacked as vendor-hosted services under 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://
A readable .git/.svn over HTTP routes to the per-tool recovery pages; an open git:// or svn:// service routes to the server-protocol pages; a repository you can clone or push to routes to the hooks and config pages.
Subtopics#
- Git: recovering an exposed
.git, mining secrets from history, the unauthenticatedgit://daemon, and code execution through hooks and clone-time config. - SVN: recovering an exposed
.svnworking copy, and reaching Subversion history and credentials.