📤 OverTheWire Bandit Level 32: Git Push Operations and Bypassing .gitignore

Level 32 introduces Git push operations and .gitignore files—teaching you how to add, commit, and push files to a remote repository, and how to work around .gitignore restrictions when necessary. This level combines Git workflow knowledge with understanding how Git ignores files.

Level 32 teaches you:

• Understanding Git push workflow
• Working with .gitignore files
• Bypassing .gitignore restrictions
• Adding, committing, and pushing files
• Understanding Git server responses

If you've made it this far, you understand Git cloning, history, branches, and refs. Now you're learning about Git push operations—a fundamental part of Git workflows that can also reveal information in server responses.

---

🎯 The Objective

After logging into bandit31, your goal is to find the password for Level 32. There's a Git repository at ssh://bandit31-git@localhost/home/bandit31-git/repo. The password for the user bandit31-git is the same as for the user bandit31.

What Level 32 teaches:

• Understanding Git push workflow
• Working with .gitignore files
• Bypassing .gitignore restrictions
• Adding, committing, and pushing files
• Understanding server responses

The challenge: The README file contains instructions to push a specific file (key.txt with content "May I come in?") to the remote repository. However, .gitignore is blocking the file. You need to bypass this restriction and push the file to receive the password in the server response.

---

🔍 Understanding the Problem

Let's start by connecting to Level 31:

sshpass -p `cat bandit31` ssh bandit31@bandit.labs.overthewire.org -p 2220

Once connected, let's clone the repository:

mkdir -p /tmp/m1k3
cd /tmp/m1k3
git clone ssh://bandit31-git@localhost/home/bandit31-git/repo
cd repo

The problem: The README contains instructions to push a file, but .gitignore is preventing you from adding it. You need to work around this restriction.

---

🧠 Understanding Git Push and .gitignore

Here's what's happening: Git uses .gitignore to prevent certain files from being tracked. However, you can bypass this restriction to push files when necessary.

How Git Push Works

Git push workflow:

1. Modify files — Create or edit files
2. Stage changes — git add files to staging area
3. Commit changes — git commit creates a snapshot
4. Push changes — git push sends commits to remote repository

Why this matters:

• Push operations send data to remote servers
• Server responses can contain information
• Push hooks can execute server-side code
• Understanding push workflow is essential

Understanding .gitignore

.gitignore tells Git which files to ignore:

• Prevents files from being tracked
• Uses pattern matching
• Can ignore specific files or patterns
• Helps keep repositories clean

Common patterns:

• *.txt — Ignore all .txt files
• key.txt — Ignore specific file
• /tmp/ — Ignore directory
• *.log — Ignore file extensions

In Level 32: .gitignore is configured to ignore key.txt, preventing you from adding it.

Bypassing .gitignore

Methods to bypass .gitignore:

1. Remove .gitignore — Delete the file (if you have permission)
2. Use -f flag — Force add with git add -f
3. Modify .gitignore — Remove the pattern (if you have permission)

In Level 32: Removing .gitignore is the straightforward approach.

Understanding Server Responses

Git push responses can contain:

• Success messages
• Error messages
• Hook output
• Server-side script output
• Passwords or flags (in CTF scenarios)

In Level 32: The push response contains the password for the next level.

---

📋 Step-by-Step Walkthrough

Step 1: Connect to Level 31

sshpass -p `cat bandit31` ssh bandit31@bandit.labs.overthewire.org -p 2220

Step 2: Get the Password Ready

You'll need the bandit31 password for the Git clone:

cat /etc/bandit_pass/bandit31

Copy this password.

Step 3: Create Temporary Directory and Clone

mkdir -p /tmp/m1k3
cd /tmp/m1k3
git clone ssh://bandit31-git@localhost/home/bandit31-git/repo
cd repo

When prompted, paste the bandit31 password.

Step 4: Read the README File

cat README.md

What you'll see:

This is a repo for bandit32. You need to push a file to the remote repository.

Details:
   File name: key.txt
   Content: 'May I come in?'
   Branch: master

The instructions: Create key.txt with content "May I come in?" and push it to the master branch.

Step 5: Create the key.txt File

Let's create the file with the required content:

echo "May I come in?" > key.txt

Or use a text editor:

nano key.txt
# Type: May I come in?
# Save and exit (Ctrl+X, Y, Enter)

Step 6: Try to Add the File

Let's try to add the file:

git add key.txt

What you'll see:

The following paths are ignored by one of your .gitignore files:
key.txt
Use -f if you really want to add them.

The problem: .gitignore is blocking the file.

Step 7: Check the .gitignore File

Let's see what's in .gitignore:

cat .gitignore

What you'll see: Likely contains key.txt or *.txt pattern.

Step 8: Remove .gitignore

Since we need to push the file, let's remove .gitignore:

rm .gitignore

Why this works: Without .gitignore, Git won't ignore key.txt anymore.

Step 9: Alternative: Force Add (If Removing Doesn't Work)

If removing .gitignore doesn't work, try force adding:

git add -f key.txt

Note: In Level 32, removing .gitignore is the intended solution.

Step 10: Add the File Again

Now that .gitignore is removed, let's add the file:

git add key.txt

What you'll see: No error this time! The file is staged.

Step 11: Commit the File

Let's commit the file:

git commit -m "Add key.txt"

What you'll see:

[master abc123] Add key.txt
 1 file changed, 1 insertion(+)
 create mode 100644 key.txt

Step 12: Push to Remote Repository

Now let's push to the remote repository:

git push origin master

What you'll see:

Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 280 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: ### Attempting to validate files... ####
remote: 
remote: .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.
remote: 
remote: Well done! Here is the password for the next level:
remote: 
remote: [PASSWORD_HERE]
remote: 
remote: .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.

The key: The password is in the push response!

Step 13: Extract the Password

From the git push output, find the password. It should be clearly displayed in the server response.

Step 14: Save the Password

Copy the password and save it:

On Linux/macOS:

echo "PASSWORD_HERE" > bandit32

On Windows (PowerShell):

"PASSWORD_HERE" | Out-File -FilePath bandit32 -NoNewline

Step 15: Connect to Level 32

sshpass -p `cat bandit32` ssh bandit32@bandit.labs.overthewire.org -p 2220

---

💡 Understanding Git Push in Depth

Let's dive deeper into Git push concepts:

Git Push Workflow

The complete workflow:

1. Working directory — Where you edit files
2. Staging area — Where git add puts files
3. Local repository — Where git commit stores snapshots
4. Remote repository — Where git push sends commits

Why each step matters:

• git add — Stages changes for commit
• git commit — Creates a snapshot
• git push — Sends commits to remote
• Server processes push and responds

Understanding .gitignore Patterns

Common .gitignore patterns:

• filename — Exact filename match
• *.ext — All files with extension
• directory/ — Entire directory
• **/pattern — Recursive pattern matching

Why .gitignore exists:

• Prevents committing sensitive files
• Keeps repository clean
• Avoids tracking build artifacts
• Reduces repository size

Bypassing .gitignore:

• Remove the file (if you have permission)
• Use git add -f to force add
• Modify .gitignore to remove pattern

Understanding Server Responses

Git push triggers server-side actions:

• Pre-receive hooks — Validate before accepting
• Update hooks — Process after accepting
• Post-receive hooks — Actions after push completes
• Server scripts — Custom processing

In Level 32: The server has a hook that validates the pushed file and responds with the password.

---

🔒 Real-World Context

Why does this matter in penetration testing?

Git push operations and server responses can reveal information:

1. Information Disclosure in Push Responses

In real assessments, you might:

• Push files to test repositories
• Analyze server responses
• Look for error messages
• Extract information from hooks

The technique: Same as Level 32—push files and analyze server responses for information disclosure.

2. Common Git Server Security Issues

Information disclosure:

• Passwords in error messages
• Stack traces in responses
• Internal paths in errors
• Credentials in hook output

Why it's dangerous:

• Push responses are visible to users
• Error messages can leak information
• Hook output might contain secrets
• Server responses can reveal internals

3. Real-World Examples

Common scenarios:

• Git server returns password in push response
• Error messages reveal internal paths
• Hook scripts output sensitive information
• Server responses leak configuration details

The skill you're learning: How to interact with Git servers and extract information from responses. This is essential for:

• Finding exposed credentials
• Understanding server behavior
• Discovering sensitive information
• Security auditing

---

🛠️ Alternative Methods

Here are different ways to approach Level 32:

Method 1: Remove .gitignore (Recommended)

rm .gitignore
git add key.txt
git commit -m "Add key.txt"
git push origin master

Pros: Simple and straightforward Cons: Requires write access to repository

Method 2: Force Add with -f

git add -f key.txt
git commit -m "Add key.txt"
git push origin master

Pros: Doesn't require removing .gitignore Cons: Might not work if server validates .gitignore

Method 3: Modify .gitignore

# Edit .gitignore to remove key.txt pattern
nano .gitignore
git add key.txt
git commit -m "Add key.txt"
git push origin master

Pros: More surgical approach Cons: More complex, requires editing

For Level 32, use Method 1 — it's the most straightforward and intended solution.

---

🚨 Common Mistakes

Mistake 1: Not Reading the README

Wrong: Creating the file without reading instructions, missing the exact content requirement.

Right: Read README.md carefully—it specifies the exact filename, content, and branch.

Why: CTF levels often have specific requirements. "May I come in?" must be exact, including quotes.

Mistake 2: Not Understanding .gitignore Error

Wrong: Seeing .gitignore error and giving up, not knowing how to bypass it.

Right: Understand that .gitignore can be bypassed by removing it or using -f flag.

Why: .gitignore is a convenience feature, not a security mechanism. It can be bypassed.

Mistake 3: Forgetting to Commit

Wrong: Adding the file but forgetting to commit before pushing.

Right: Remember the workflow: add → commit → push.

Why: git push only sends committed changes. Uncommitted changes aren't pushed.

Mistake 4: Not Reading Push Response

Wrong: Pushing successfully but not reading the server response.

Right: Always read Git server responses—they often contain important information.

Why: In Level 32, the password is in the push response. Missing it means starting over.

Mistake 5: Wrong Branch

Wrong: Pushing to wrong branch (e.g., main instead of master).

Right: Check README instructions—it specifies master branch.

Why: Server hooks might only validate pushes to specific branches.

---

💻 Practice Exercise

Try these to reinforce what you learned:

1. Understand Git workflow:

   git status
   git add <file>
   git commit -m "message"
   git push origin master
   

2. Work with .gitignore:

   cat .gitignore
   git add -f <file>
   

3. Understand push responses:

   git push origin master
   # Read the output carefully
   

---

🎓 Understanding Git Workflow Security

This level introduces Git workflow security concepts:

Why Git Workflow Matters

Security implications:

• Push operations send data to servers
• Server responses can contain information
• Hooks can execute server-side code
• Understanding workflow helps find vulnerabilities

Best Practices

For secure Git operations:

• Validate all push operations server-side
• Don't return sensitive information in responses
• Use proper authentication and authorization
• Review hook scripts for security issues

If you're testing:

• Analyze server responses carefully
• Look for information disclosure
• Test different push scenarios
• Check hook behavior

The skill you're learning: How to interact with Git servers and extract information from responses. This is essential for:

• Security auditing
• Penetration testing
• Understanding Git security
• Finding exposed credentials

---

🔗 What's Next?

Level 33 will likely introduce new concepts or continue building on Git operations.

Before moving on, make sure you:

• ✅ Understand Git push workflow
• ✅ Can work with .gitignore files
• ✅ Know how to bypass .gitignore restrictions
• ✅ Can add, commit, and push files
• ✅ Know to read server responses carefully

---

📚 Key Takeaways

After completing Level 32, you should understand:

1. Git push workflow — Add → Commit → Push
2. .gitignore files — How Git ignores files
3. Bypassing .gitignore — Removing file or using -f flag
4. Server responses — Why they matter and what they can contain
5. Information disclosure — How push responses can reveal secrets

---

🎯 Quick Reference

Concept	Explanation	Example
git add	Stage files	git add key.txt
git commit	Create snapshot	git commit -m "message"
git push	Send to remote	git push origin master
.gitignore	Ignore patterns	key.txt or *.txt
git add -f	Force add	git add -f key.txt

---

🔍 Advanced: Understanding Git Hooks

If you want to go deeper, here's Git hooks:

Git Hook Types

Server-side hooks:

• pre-receive — Runs before accepting push
• update — Runs for each branch update
• post-receive — Runs after push completes

Why hooks matter:

• Can validate pushed content
• Can execute custom scripts
• Can return information to user
• Can be a security concern if misconfigured

Finding Secrets in Hooks

Techniques:

• Analyze hook responses
• Look for information disclosure
• Test different push scenarios
• Check hook script behavior

In Level 32: The server has a hook that validates the pushed key.txt file and responds with the password when validation succeeds.

---

Questions about Level 32, Git push operations, or .gitignore? Reach out directly:

• Email: m1k3@msquarellc.net
• Phone: (559) 670-3159
• Schedule: Book a free consultation

---

M Square LLC
Cybersecurity | Penetration Testing | No-Nonsense Advice