Exposed .git Directory Leading to Source Code Disclosure and Hardcoded Credentials

During a web application assessment, I discovered an exposed .git directory that allowed me to download the application's entire source code. By extracting and analysing the git objects, I identified hardcoded credentials that granted admin-level access to the application.

Objective

The engagement was a black-box web application penetration test with the objective of testing and trying to bypass authentication to gain access to the application. Initial reconnaissance included directory enumeration to identify exposed files and directories.

Discovery

While running directory enumeration with feroxbuster, I noticed the application returned a 200 response for /.git/. This indicated the git repository was publicly accessible.

I used git-dumper to download the exposed repository:

git-dumper https://target-redacted.com/.git/ ./output

This retrieved the git objects, but they were stored in compressed format. I wrote a quick bash script to decompress them:

#!/bin/bash

INPUT_DIR="objects"
OUTPUT_BASE="code"
count=1

for file in "$INPUT_DIR"/*; do
    if [[ -f $file ]]; then
        ruby -rzlib -e 'print Zlib::Inflate.new.inflate(STDIN.read)' < "$file" > "${OUTPUT_BASE}${count}"
        ((count++))
    fi
done

echo "Processing completed."

With the objects now in clear text, I used gitleaks to scan for hardcoded secrets:

gitleaks detect --source='./output' --no-git -v

This returned results within seconds, identifying two hardcoded passwords in the source code.

The .git directory was accessible without authentication, exposing the full version control history including all source code files.

Using the discovered passwords with the username admin (an educated guess) granted administrative access to the application.

With access to the full source code, further analysis was possible using automated scanning tools to identify additional vulnerabilities without manually reviewing hundreds of files.

Takeaway

Exposed .git directories remain a common misconfiguration that can expose your entire codebase. Beyond the immediate risk of source code disclosure, developers often leave hardcoded credentials in code, turning a configuration issue into full application compromise.