OverTheWire Wargames bandit => 3

Posted Jan 26, 2025

By Muzammil Shaik 24 min read

OverTheWire is a platform that provides a collection of wargames designed to help individuals enhance their knowledge of cybersecurity. It’s ideal for both beginners and experienced security enthusiasts looking to expand their skill set in a practical and engaging way.

The platform’s wargames are structured to help users progress step-by-step, starting with basic tasks and advancing to more complex challenges. This makes it an excellent tool for learning concepts such as:

Linux/Unix Basics: It introduces beginners to command-line tasks, file manipulation, and system navigation, providing a solid foundation in operating systems.
Networking and Protocols: Challenges related to TCP/IP, HTTP, and other networking protocols teach how to analyze and interact with network traffic, offering insight into penetration testing techniques.
Cryptography: OverTheWire covers fundamental cryptographic concepts, teaching users how to exploit weaknesses in encryption systems and improve their understanding of security protocols.
Web Security: The platform includes practical lessons on common web vulnerabilities such as SQL Injection, Cross-Site Scripting (XSS), and other issues that are crucial for web application security.
Reverse Engineering: Users can dive into reverse engineering challenges to understand how to disassemble and manipulate programs, gaining valuable insight into software vulnerabilities.
Forensics: OverTheWire also helps users build skills in digital forensics by analyzing compromised data, investigating file systems, and extracting hidden information.

Bandit, the most popular wargame on OverTheWire, is a great starting point for beginners. It introduces users to basic security concepts and Linux commands, offering a fun, interactive way to start learning. As players progress through the game, they tackle increasingly challenging puzzles that simulate real-world hacking scenarios.

In essence, OverTheWire offers a unique, hands-on learning experience where users can practice ethical hacking in a safe, controlled environment. Whether you’re looking to break into the world of cybersecurity or deepen your existing knowledge, OverTheWire provides a wealth of challenges to help you sharpen your skills.

This is a continuation from Part 3 of the Bandit Wargame series. If you haven’t checked out Part 2 blog, I highly recommend giving it a read before proceeding, as it covers foundational skills essential for tackling these levels.

Now, let’s pick up where we left off and dive deeper into the challenges, starting from Bandit Level 11. These levels will introduce more advanced concepts, helping you sharpen your Linux skills further.

Let’s get started!

Bandit Level 20 → Level 21

Level Goal

There is a setuid binary in the homedirectory that does the following: it makes a connection to localhost on the port you specify as a commandline argument. It then reads a line of text from the connection and compares it to the password in the previous level (bandit20). If the password is correct, it will transmit the password for the next level (bandit21).

Note: Try connecting to your own network daemon to see if it works as you think

bandit20@bandit:~$ cat /etc/bandit_pass/bandit20
0qXahG8ZjOVMN9Ghs7iOWsCfZyXOUbYO
bandit20@bandit:~$ nc -lvnp 9001
Listening on 0.0.0.0 9001
Connection received on 127.0.0.1 37652
0qXahG8ZjOVMN9Ghs7iOWsCfZyXOUbYO
EeoULMCra2q0dSkYj561DX7s1CpBuOBt

Bandit Level 21 → Level 22

Level Goal

A program is running automatically at regular intervals from cron, the time-based job scheduler. Look in /etc/cron.d/ for the configuration and see what command is being executed.

bandit21@bandit:/etc/cron.d$ cat *
@reboot bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null
* * * * * bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null

bandit21@bandit:/etc/cron.d$ cat /usr/bin/cronjob_bandit22.sh
#!/bin/bash
chmod 644 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv

bandit21@bandit:/etc/cron.d$ cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
tRae0UfB9v0UzbCdn9cY0gQnds9GF58Q

bandit21@bandit:/etc/cron.d$ 

Explanation

The script is a cron job that runs automatically at set intervals.
It performs two actions:
- Sets the file permissions of /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv to 644 (readable by everyone but writable only by the owner).
- Copies the content of the file /etc/bandit_pass/bandit22 (which contains the password for bandit22) into /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv.

Bandit Level 22 → Level 23

Level Goal

A program is running automatically at regular intervals from cron, the time-based job scheduler. Look in /etc/cron.d/ for the configuration and see what command is being executed.

Note: Looking at shell scripts written by other people is a very useful skill. The script for this level is intentionally made easy to read. If you are having problems understanding what it does, try executing it to see the debug information it prints.

bandit22@bandit:~$ cat /usr/bin/cronjob_bandit23.sh
#!/bin/bash

myname=$(whoami)
mytarget=$(echo I am user $myname | md5sum | cut -d ' ' -f 1)

echo "Copying passwordfile /etc/bandit_pass/$myname to /tmp/$mytarget"

cat /etc/bandit_pass/$myname > /tmp/$mytarget

bandit22@bandit:~$ echo "I am user bandit23" | md5sum | cut -d ' ' -f 1
8ca319486bfbbc3663ea0fbe81326349

bandit22@bandit:~$ cat /tmp/8ca319486bfbbc3663ea0fbe81326349
0Zf11ioIjMVN551jX3CmStKLYqjk54Ga
bandit22@bandit:~$

Bandit Level 23 → Level 24

Level Goal

A program is running automatically at regular intervals from cron, the time-based job scheduler. Look in /etc/cron.d/ for the configuration and see what command is being executed.

Note: This level requires you to create your own first shell-script. This is a very big step and you should be proud of yourself when you beat this level!
Note: Keep in mind that your shell script is removed once executed, so you may want to keep a copy around…

bandit23@bandit:$ cat /etc/cron.d/cronjob_bandit24
@reboot bandit24 /usr/bin/cronjob_bandit24.sh &> /dev/null
* * * * * bandit24 /usr/bin/cronjob_bandit24.sh &> /dev/null
bandit23@bandit:$ cat /usr/bin/cronjob_bandit24.sh
#!/bin/bash

myname=$(whoami)

cd /var/spool/$myname/foo
echo "Executing and deleting all scripts in /var/spool/$myname/foo:"
for i in * .*;
do
    if [ "$i" != "." -a "$i" != ".." ];
    then
        echo "Handling $i"
        owner="$(stat --format "%U" ./$i)"
        if [ "${owner}" = "bandit23" ]; then
            timeout -s 9 60 ./$i
        fi
        rm -f ./$i
    fi
done

bandit23@bandit:$

bandit23@bandit:/tmp/t00$ cat payload.sh
#!/bin/bash
cat /etc/bandit_pass/bandit24 > /tmp/t00/passwd

bandit23@bandit:/tmp/t00$ touch passwd && chmod 777 passwd
bandit23@bandit:/tmp/t00$ cp payload.sh /var/spool/bandit24/foo/
bandit23@bandit:/tmp/t00$ cat passwd
gb8KRRCsshuZXI0tUuR6ypOFjiZbf3G8
bandit23@bandit:/tmp/t00$

Explanation

The cron job file (/etc/cron.d/cronjob_bandit24) runs a script (/usr/bin/cronjob_bandit24.sh) as the user bandit24.
The cron job executes every minute (* * * * * bandit24) and on reboot (@reboot bandit24).
The script processes files in /var/spool/bandit24/foo/ and executes them if they are owned by bandit23.
Since we lack permission to read /etc/bandit_pass/bandit24, we created a script (payload.sh) that writes the password to a readable file (/tmp/t00/passwd) and placed it in the monitored directory (/var/spool/bandit24/foo/).
The cron job executed payload.sh, allowing us to retrieve the password.

## Bandit Level 24 → Level 25 Level Goal

A daemon is listening on port 30002 and will give you the password for bandit25 if given the password for bandit24 and a secret numeric 4-digit pincode. There is no way to retrieve the pincode except by going through all of the 10000 combinations, called brute-forcing. You do not need to create new connections each time

bandit24@bandit:/tmp/tmp.89890$ for i in $(seq -f "%04g" 0 9999); do   echo "$(cat /etc/bandit_pass/bandit24) $i"; done >> pass.txt  

bandit24@bandit:/tmp/tmp.89890$ head -n 3 pass.txt && cat pass.txt | wc -l
gb8KRRCsshuZXI0tUuR6ypOFjiZbf3G8 0000
gb8KRRCsshuZXI0tUuR6ypOFjiZbf3G8 0001
gb8KRRCsshuZXI0tUuR6ypOFjiZbf3G8 0002
10000

bandit24@bandit:/tmp/tmp.89890$ cat pass.txt | nc localhost 30002 > out.txt 
bandit24@bandit:/tmp/tmp.89890$ cat out.txt | grep -v "Wrong!"
I am the pincode checker for user bandit25. Please enter the password for user bandit24 and the secret pincode on a single line, separated by a space.
Correct!
The password of user bandit25 is iCi86ttT4KSNe1armKiwbQNmB3YJP3q4

bandit24@bandit:/tmp/tmp.89890$

Explanation

We have generated range of password pincode combination pairs in the pass.txt file, where the password for bandit24 is paired with each 4-digit combination.
The total number of entries in pass.txt was confirmed using cat pass.txt | wc -l, which showed 10,000 entries.
The contents of pass.txt were piped to nc (netcat) to send the password-pincode pairs to a service running on localhost on port 30002
After filtering the responses, the correct password for bandit25 was identified.

Bandit Level 25 → Level 26

Level Goal

Logging in to bandit26 from bandit25 should be fairly easy… The shell for user bandit26 is not /bin/bash, but something else. Find out what it is, how it works and how to break out of it.

Note: if you’re a Windows user and typically use Powershell to ssh into bandit: Powershell is known to cause issues with the intended solution to this level. You should use command prompt instead.

s0773xxkk0MXfdqOfPRVr9L3jJBUOgCZ
~                                                                                                                      "/etc/bandit_pass/bandit26" [readonly] 1L, 33B                                                                                                                            1,1           All
bandit25@bandit:~$

Explanation

In this level, it was crucial to think outside the box to overcome the challenge. Initially, various commands were tried to break out of the restricted shell and gain access, but none of them worked. After several attempts, it became clear that traditional methods wouldn’t work, so the next step was to consult a cheat sheet for insights and alternative approaches to bypass the restrictions.
As the script is executing the more is displaying the banner we need to fully zoom the screen so that the more goes into command line
Once the command line was visible, the next step was to press the v key. Pressing v within the more environment switched the interface into vim mode, a text editor that allows for more interactive control over the terminal. In vim, users have the ability to edit files, navigate within them, and execute commands. To proceed, the file containing the password for the next level could be accessed by entering the command :e /etc/bandit_pass/bandit26. This command opened the password file, revealing the password for bandit26, which could then be used to log in to the next level and continue progressing through the challenge

Bandit Level 26 → Level 27

Level Goal

Good job getting a shell! Now hurry and grab the password for bandit27!

$ ls
bandit27-do  text.txt
$ file bandit27-do
bandit27-do: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=368cd8ac4633fabdf3f4fb1c47a250634d6a8347, for GNU/Linux 3.2.0, not stripped
$ ./bandit27-do cat /etc/bandit\_pass/bandit27
upsNCc7vzaRDx6oZC6GiR6ERwe1MowGB
$ ./bandit27-do cat /etc/bandit_pass/bandit27
upsNCc7vzaRDx6oZC6GiR6ERwe1MowGB
$

Explanation

The bandit26 user cannot log in directly through SSH due to the restricted shell. The shell for the user is set as /usr/bin/showtext as shown in the /etc/passwd entry: bandit26:x:11026:11026:bandit level 26:/home/bandit26:/usr/bin/showtext.
Access to a shell can be gained by exploiting the vim binary using the technique found in GTFOBins. This allows spawning an interactive shell despite the restrictions.
After obtaining shell access, it is possible to inspect the directory and find a file named bandit27-do. This file is a setuid binary that can execute commands as the bandit27 user. The file details can be confirmed using the file command:
The bandit27-do binary can be used to read the contents of /etc/bandit_pass/bandit27, which contains the password for the bandit27 user. The password can be retrieved by running the following command: ./bandit27-do cat /etc/bandit_pass/bandit27.
The output will reveal the password for the next level: upsNCc7vzaRDx6oZC6GiR6ERwe1MowGB.

Bandit Level 27 → Level 28

Level Goal

There is a git repository at ssh://bandit27-git@localhost/home/bandit27-git/repo via the port 2220. The password for the user bandit27-git is the same as for the user bandit27.

Clone the repository and find the password for the next level.

bandit27@bandit:/tmp/tmp.5989459$ git clone "ssh://bandit27-git@localhost:2220/home/bandit27-git/repo"
Cloning into 'repo'...
The authenticity of host '[localhost]:2220 ([127.0.0.1]:2220)' can't be established.
ED25519 key fingerprint is SHA256:C2ihUBV7ihnV1wUXRb4RrEcLfXC5CXlhmAAM/urerLY.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Could not create directory '/home/bandit27/.ssh' (Permission denied).
Failed to add the host to the list of known hosts (/home/bandit27/.ssh/known_hosts).
                         _                     _ _ _
                        | |__   __ _ _ __   __| (_) |_
                        | '_ \ / _` | '_ \ / _` | | __|
                        | |_) | (_| | | | | (_| | | |_
                        |_.__/ \__,_|_| |_|\__,_|_|\__|


                      This is an OverTheWire game server.
            More information on http://www.overthewire.org/wargames

bandit27-git@localhost's password:
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), 286 bytes | 286.00 KiB/s, done.
bandit27@bandit:/tmp/tmp.5989459$ ls
repo
bandit27@bandit:/tmp/tmp.5989459$ cd repo/
bandit27@bandit:/tmp/tmp.5989459/repo$ ls
README
bandit27@bandit:/tmp/tmp.5989459/repo$ cat README
The password to the next level is: Yz9IpL0sBcCeuG7m9uQFt8ZNpS4HZRcN
bandit27@bandit:/tmp/tmp.5989459/repo$

Bandit Level 28 → Level 29

Level Goal

There is a git repository at ssh://bandit28-git@localhost/home/bandit28-git/repo via the port 2220. The password for the user bandit28-git is the same as for the user bandit28.

Clone the repository and find the password for the next level.

bandit28@bandit:/tmp/tmp-67890$ git clone "ssh://bandit28-git@localhost:2220/home/bandit28-git/repo"
Cloning into 'repo'...
bandit28-git@localhost's password:
Receiving objects: 100% (9/9), done.
Resolving deltas: 100% (2/2), done.

bandit28@bandit:/tmp/tmp-67890$ cd repo/
bandit28@bandit:/tmp/tmp-67890/repo$ ls
README.md
bandit28@bandit:/tmp/tmp-67890/repo$ cat README.md
# Bandit Notes
Some notes for level29 of bandit.

## credentials

- username: bandit29
- password: xxxxxxxxxx

bandit28@bandit:/tmp/tmp-67890/repo$ git log
commit 817e303aa6c2b207ea043c7bba1bb7575dc4ea73 (HEAD -> master, origin/master, origin/HEAD)
Author: Morla Porla <morla@overthewire.org>
Date:   Thu Sep 19 07:08:39 2024 +0000

    fix info leak

commit 3621de89d8eac9d3b64302bfb2dc67e9a566decd
Author: Morla Porla <morla@overthewire.org>
Date:   Thu Sep 19 07:08:39 2024 +0000

    add missing data

commit 0622b73250502618babac3d174724bb303c32182
Author: Ben Dover <noone@overthewire.org>
Date:   Thu Sep 19 07:08:39 2024 +0000

    initial commit of README.md

bandit28@bandit:/tmp/tmp-67890/repo$ git checkout 3621de89d8eac9d3b64302bfb2dc67e9a566decd
Previous HEAD position was 817e303 fix info leak
HEAD is now at 3621de8 add missing data

bandit28@bandit:/tmp/tmp-67890/repo$ cat README.md
# Bandit Notes
Some notes for level29 of bandit.

## credentials

- username: bandit29
- password: 4pT1t5DENaYuqnqvadYs1oE4QLCdjmJ7

bandit28@bandit:/tmp/tmp-67890/repo$

Theory

git log shows us the commit log.
git show <commit> shows us the content of a commit (When creating a public repository it is important to be aware of the information you push to it since changes and previous versions are saved. So sensitive data, like passwords, could still be retrieved).

Explanation

The Git repository was cloned using the following command:
git clone "ssh://bandit28-git@localhost:2220/home/bandit28-git/repo".
This command connects to the repository using the specified SSH protocol and port 2220. After cloning, the repository contained a single file named README.md.
Upon inspecting the README.md file using cat README.md, it was discovered that the file contained obfuscated credentials for level 29. These credentials were intentionally hidden in the latest commit.
The commit history of the repository was checked using the git log command. This command displayed the history of commits, including their hashes, authors, and timestamps. Three commits were identified in the log:
- The first commit: Initial commit of the README.md.
- The second commit: Added missing data.
- The third commit: Fixed an information leak.
Each commit was checked individually by using the git checkout <commit-hash> command to switch to a specific commit. The file content in each commit was then examined.
- In the first commit, the file contained no relevant information.
- In the second commit, the credentials for level 29 were revealed in the README.md file as follows:
  1 2 - username: bandit29 - password: 4pT1t5DENaYuqnqvadYs1oE4QLCdjmJ7
- The third commit had the credentials obfuscated.
By analyzing the commit history and accessing previous commits, the hidden credentials were successfully retrieved.

Bandit Level 29 → Level 30

Level Goal

There is a git repository at ssh://bandit29-git@localhost/home/bandit29-git/repo via the port 2220. The password for the user bandit29-git is the same as for the user bandit29.

Clone the repository and find the password for the next level.

bandit29@bandit:/tmp/tmp-0987$ git clone "ssh://bandit29-git@localhost:2220/home/bandit29-git/repo"
Cloning into 'repo'...
The authenticity of host '[localhost]:2220 ([127.0.0.1]:2220)' can't be established.
bandit29-git@localhost's password:
Receiving objects: 100% (16/16), done.
Resolving deltas: 100% (2/2), done.
bandit29@bandit:/tmp/tmp-0987/repo$ cat README.md
# Bandit Notes
Some notes for bandit30 of bandit.

## credentials

- username: bandit30
- password: <no passwords in production!>

bandit29@bandit:/tmp/tmp-0987/repo$ git remote show origin
bandit29-git@localhost's password:
* remote origin
  Fetch URL: ssh://bandit29-git@localhost:2220/home/bandit29-git/repo
  Push  URL: ssh://bandit29-git@localhost:2220/home/bandit29-git/repo
  HEAD branch: master
  Remote branches:
    dev         tracked
    master      tracked
    sploits-dev tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

bandit29@bandit:/tmp/tmp-0987/repo$ git checkout dev
Previous HEAD position was 6ac7796 fix username
branch 'dev' set up to track 'origin/dev'.
Switched to a new branch 'dev'
bandit29@bandit:/tmp/tmp-0987/repo$ cat README.md
# Bandit Notes
Some notes for bandit30 of bandit.

## credentials

- username: bandit30
- password: qp30ex3VLz5MDG1n91YowTv4Q8l7CDZL

Theory:

Git branching is another feature of the version control system. It allows you to split the development into different branches. Specifically, there is a master branch from which the software can be taken and it can be separately worked on. You can change and add features while still maintaining a working master branch. Once the work is done, it can be integrated into the master branch again. This allows for additional version control. You can offer a production branch with usable software, while fixing bugs or adding features in a different development branch.

The basic commands for working with branches are:

git branch: List (-a), create, or delete branches
git checkout /git switch : Switch branches
git merge: Join two or more branches

Explanation

After cloning the Git repository, the README.md file did not contain the password as it mentioned “no passwords in production!”.
The remote repository was inspected using the git remote show origin command, which revealed multiple branches: master, dev, and sploits-dev.
The dev branch was identified as a possible source of the credentials.
By switching to the dev branch using git checkout dev, the password for the next level was found in the README.md file.

Bandit Level 30 → Level 31

Level Goal

There is a git repository at ssh://bandit30-git@localhost/home/bandit30-git/repo via the port 2220. The password for the user bandit30-git is the same as for the user bandit30.

Clone the repository and find the password for the next level.

bandit30@bandit:/tmp/tmp-5678$ git clone "ssh://bandit30-git@localhost:2220/home/bandit30-git/repo"
Cloning into 'repo'...
The authenticity of host '[localhost]:2220 ([127.0.0.1]:2220)' can't be established.
bandit30-git@localhost's password:
Receiving objects: 100% (4/4), done.

bandit30@bandit:/tmp/tmp-5678/repo$ cat README.md
just an epmty file... muahaha
bandit30@bandit:/tmp/tmp-5678/repo$ git tag
secret
bandit30@bandit:/tmp/tmp-5678/repo$ git show secret
fb5S2xb7bRyFmAvQYQGEqsbhVyJqhnDy

Theory:

Git tagging is a way to mark specific points in the history of the repository. One example would be to mark release points of the software. The command to see the tags is git tag. To create a tag the command is git tag -a -m <"tag description/message">. To see more details, like the tag message and commit, you can use the following command: git show .

Explanation

After cloning the Git repository, the README.md file was found to be empty with a humorous message “just an empty file… muahaha”.
Upon inspecting the repository, the git tag command revealed the presence of a tag named secret.
Using git show secret, the password for the next level was revealed as fb5S2xb7bRyFmAvQYQGEqsbhVyJqhnDy.

Bandit Level 31 → Level 32

Level Goal

There is a git repository at ssh://bandit31-git@localhost/home/bandit31-git/repo via the port 2220. The password for the user bandit31-git is the same as for the user bandit31.

Clone the repository and find the password for the next level.

bandit31@bandit:/tmp/mp-1234$ git clone "ssh://bandit31-git@localhost:2220/home/bandit31-git/repo"
Cloning into 'repo'...
The authenticity of host '[localhost]:2220 ([127.0.0.1]:2220)' can't be established.
bandit31-git@localhost's password:
Permission denied, please try again.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
Receiving objects: 100% (4/4), done.


bandit31@bandit:/tmp/mp-1234/repo$ cat README.md
This time your task is to push a file to the remote repository.

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

bandit31@bandit:/tmp/mp-1234/repo$ echo "May I come in?" > key.txt
bandit31@bandit:/tmp/mp-1234/repo$ git add * -f
bandit31@bandit:/tmp/mp-1234/repo$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   key.txt

bandit31@bandit:/tmp/mp-1234/repo$ git commit -m "let me in"
[master b4c589b] let me in
 1 file changed, 1 insertion(+), 7 deletions(-)
bandit31@bandit:/tmp/mp-1234/repo$ git push
Counting objects: 100% (6/6), done.
Delta compression using up to 2 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 511 bytes | 511.00 KiB/s, done.
Total 5 (delta 1), reused 0 (delta 0), pack-reused 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: 3O9RfhqyAlVBEZpVb6LYStshZoqoSx5K
remote:
remote: .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.
remote:
remote:
remote: .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.
remote:
To ssh://localhost:2220/home/bandit31-git/repo
 ! [remote rejected] master -> master (pre-receive hook declined)

Theory Git Ignore is a file with the filename .gitignore. In this file, all file names/extensions that should be ignored by the commit are written. This means if a file which is in the ignore file is created/changed, it will not be part of the commit/repository. Git ignore also allows for wildcards. (For example, : *.txt means all files with the ending .txt will be ignored.).

bandit31@bandit:/tmp/mp-1234$ git clone "ssh://bandit31-git@localhost:2220/home/bandit31-git/repo"
Cloning into 'repo'...
The authenticity of host '[localhost]:2220 ([127.0.0.1]:2220)' can't be established.
bandit31-git@localhost's password:
Permission denied, please try again.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
Receiving objects: 100% (4/4), done.


bandit31@bandit:/tmp/mp-1234/repo$ cat README.md
This time your task is to push a file to the remote repository.

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

bandit31@bandit:/tmp/mp-1234/repo$ echo "May I come in?" > key.txt
bandit31@bandit:/tmp/mp-1234/repo$ git add * -f
bandit31@bandit:/tmp/mp-1234/repo$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   key.txt

bandit31@bandit:/tmp/mp-1234/repo$ git commit -m "let me in"
[master b4c589b] let me in
 1 file changed, 1 insertion(+), 7 deletions(-)
bandit31@bandit:/tmp/mp-1234/repo$ git push
Counting objects: 100% (6/6), done.
Delta compression using up to 2 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 511 bytes | 511.00 KiB/s, done.
Total 5 (delta 1), reused 0 (delta 0), pack-reused 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: 3O9RfhqyAlVBEZpVb6LYStshZoqoSx5K
remote:
remote: .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.
remote:
remote:
remote: .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.
remote:
To ssh://localhost:2220/home/bandit31-git/repo
 ! [remote rejected] master -> master (pre-receive hook declined)

Explanation

After cloning the Git repository, the README.md file specified that the task was to push a file named key.txt with the content “May I come in?” to the remote repository on the master branch.
A new file named key.txt was created with the required content, and the changes were staged using git add * -f.
The status confirmed that the changes were staged and ready to be committed.
The file was committed with the message “let me in” and pushed to the remote repository using git push.
Upon successful push, the remote server returned a message indicating successful validation and revealed the password for the next level: 3O9RfhqyAlVBEZpVb6LYStshZoqoSx5K.

Bandit Level 32 → Level 33

Level Goal

After all this git stuff, it’s time for another escape. Good luck!

>> $0
$ ls -lah
total 36K
drwxr-xr-x  2 root     root     4.0K Sep 19 07:08 .
drwxr-xr-x 70 root     root     4.0K Sep 19 07:09 ..
-rw-r--r--  1 root     root      220 Mar 31  2024 .bash_logout
-rw-r--r--  1 root     root     3.7K Mar 31  2024 .bashrc
-rw-r--r--  1 root     root      807 Mar 31  2024 .profile
-rwsr-x---  1 bandit33 bandit32  15K Sep 19 07:08 uppershell
$ whoami
bandit33
$ cat /etc/bandit_pass/bandit33
tQdtbs5D5i2vJwkO8mEyYEyTL8izoeJ0
$ 

Theory A restricted shell is used to enforce a controlled environment for users, restricting access to certain commands (like cd, exec, and set), limiting the ability to execute scripts or binaries outside of designated directories, and preventing access to sensitive system information. It’s often used in CTF challenges and for users that need to be isolated from the broader system to minimize security risks or to focus on specific tasks.

When logging into an SSH session, the prompt >> indicates that the user is operating in a restricted shell environment. A restricted shell limits what the user can do and restricts access to certain commands and functionalities. The purpose of such an environment is to limit a user’s actions and provide them only with the essential tools to complete specific tasks, often as part of a security or challenge setup, such as in CTF (Capture The Flag) challenges.

The restricted shell, often used in certain scenarios like system hardening, prevents the execution of potentially dangerous or unnecessary commands and can force the user into a particular context or program. In this case, >> is used to signify that the user is likely in a custom shell or controlled environment, which may not offer full bash or shell functionality.

Explanation:

After logging into the SSH session, the >> prompt indicates that the user is in a restricted shell. This is typically set up for certain users to limit the available commands and actions that can be performed.
The prompt >> often suggests that the user is not in a normal shell, but instead in a controlled environment where commands are either restricted or filtered.
The whoami command confirms that the user is bandit33.
The cat /etc/bandit_pass/bandit33 command reveals the password for the next level, tQdtbs5D5i2vJwkO8mEyYEyTL8izoeJ0, which will be used for authentication in the next level.

CTF, community

This post is licensed under CC BY 4.0 by the author.

Bandit Level 20 → Level 21

Bandit Level 21 → Level 22

Bandit Level 22 → Level 23

Bandit Level 23 → Level 24

Bandit Level 25 → Level 26

Bandit Level 26 → Level 27

Bandit Level 27 → Level 28

Bandit Level 28 → Level 29

Bandit Level 29 → Level 30

Bandit Level 30 → Level 31

Bandit Level 31 → Level 32

Bandit Level 32 → Level 33

Trending Tags