34 posts tagged with "bandit"

Login: ssh bandit19@bandit.labs.overthewire.org -p 2220
Password: cGWpMaKXVwDUNgPAVJbWYuGHVn9zl3j8

task​

The password for the next level is stored in /etc/bandit_pass/bandit20. To access it, you must use a SetUID binary located in the home directory called bandit20-do.

theory lil bit​

1. SetUID (Set User ID): This is a special type of file permission in Unix-like systems. When an executable with the SetUID bit is run, it executes with the privileges of the file's owner rather than the person running it.
2. bandit20-do: In this level, this binary is owned by bandit20. Because it has the SetUID bit set, any command we pass to it will be executed as the bandit20 user.
3. Privilege Escalation: This is a classic example of using a legitimate (but powerful) utility to perform actions your current user isn't allowed to do—like reading a password file restricted to the next level's user.

solution​

bandit19@bandit:~$ ls
bandit20-do
bandit19@bandit:~$ ./bandit20-do
Run a command as another user.
  Example: ./bandit20-do whoami
bandit19@bandit:~$ ./bandit20-do whoami
bandit20
bandit19@bandit:~$ ./bandit20-do cat /etc/bandit_pass/bandit20
0qXahG8ZjOVMN9Ghs7iOWsCfZyXOUbYO

`

Login: ssh bandit20@bandit.labs.overthewire.org -p 2220
Password: 0qXahG8ZjOVMN9Ghs7iOWsCfZyXOUbYO

task​

There is a SetUID binary in the home directory that connects to localhost on a specified port. It reads the current password from the connection and, if correct, sends back the password for the next level.

theory lil bit​

1. nc (netcat): Often called the "Swiss-army knife" of networking. We use it here to set up a listening server (-l) on a specific port (-p).
2. suconnect binary: This program acts as a client. It expects to find a service listening on the port you provide. Once connected, it waits for the current level's password to be sent to it.
3. Multitasking/Backgrounding: Since both the listener (nc) and the client (suconnect) need to run at the same time on the same machine, you either need two SSH sessions or to run the listener in the background using &.

solution​

To solve this, we need two separate terminal instances or a way to run processes in parallel.

Terminal 1 (Setting up the listener): We tell netcat to listen on port 4444. Once the connection is established, we will paste the current password.

bandit20@bandit:~$ nc -lvnp 4444
Listening on 0.0.0.0 4444

Terminal 2 (Executing the client): While Terminal 1 is listening, we run the provided binary and point it to our listening port.

bandit20@bandit:~$ ./suconnect 4444

Back in Terminal 1: The connection will be received. You must then manually type or paste the password for Level 20. If it matches what the binary expects, it will send the Level 21 password back to you.

Connection received on 127.0.0.1 54086
0qXahG8ZjOVMN9Ghs7iOWsCfZyXOUbYO
EeoULMCra2q0dSkYj561DX7s1CpBuOBt

`

Login: ssh bandit21@bandit.labs.overthewire.org -p 2220
Password: EeoULMCra2q0dSkYj561DX7s1CpBuOBt

task​

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

theory lil bit​

1. Cron: A time-based job scheduler in Unix-like operating systems. It enables users to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals.
2. /etc/cron.d/: This directory contains system-wide cron jobs. Each file here usually specifies the user that runs the command and the command itself.
3. Shell Scripts (.sh): These are text files containing a series of commands. When executed, the system runs each command in the file one by one.
4. Redirection (>): In the script, you will see cat file > /tmp/.... This takes the content of the password file and writes it into a temporary file that is readable by others.

solution​

# Navigate to the cron configuration directory
bandit21@bandit:~$ cd /etc/cron.d
bandit21@bandit:/etc/cron.d$ ls
cronjob_bandit22

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

# Read the script being executed by the cron job
bandit21@bandit:/etc/cron.d$ cat /usr/bin/cronjob_bandit22.sh
#!/bin/bash
chmod 644 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv

# Since the script runs every minute, the password is already in the temp file
bandit21@bandit:/etc/cron.d$ cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
tRae0UfB9v0UzbCdn9cY0gQnds9GF58Q

`

Login: ssh bandit22@bandit.labs.overthewire.org -p 2220
Password: tRae0UfB9v0UzbCdn9cY0gQnds9GF58Q

task​

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

theory lil bit​

1. Shell Variables: In the script, $myname is a variable. When the cron job runs for bandit23, the script sets myname to "bandit23".
2. MD5 Hashing: The command md5sum creates a unique 32-character fingerprint (hash) of a string. In this level, the script uses the hash of a specific string as a hidden filename in /tmp.
3. Command Substitution: Using $(command) allows the output of one command to be stored in a variable or used inside another string.
4. Logic: To find the password, we don't need to run the script. We just need to figure out what the filename would be when the user is bandit23, and then read that file.

solution​

# Navigate to the cron directory and check the script
bandit22@bandit:~$ cd /etc/cron.d
bandit22@bandit:/etc/cron.d$ cat cronjob_bandit23
* * * * * bandit23 /usr/bin/cronjob_bandit23.sh &> /dev/null

# Analyze the script logic
bandit22@bandit:/etc/cron.d$ 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

# Replicate the logic for bandit23 to find the hidden filename
bandit22@bandit:/etc/cron.d$ echo I am user bandit23 | md5sum | cut -d ' ' -f 1
8ca319486bfbbc3663ea0fbe81326349

# Read the resulting file from the /tmp directory
bandit22@bandit:/etc/cron.d$ cat /tmp/8ca319486bfbbc3663ea0fbe81326349
0Zf11ioIjMVN551jX3CmStKLYqjk54Ga

`

Bandit 17 to 18​

login : ssh -i sshkey17.private -p 2220 bandit17@bandit.labs.overthewire.org
password : (Uses the RSA private key retrieved in the previous level)

Task​

There are 2 files in the home directory: passwords.old and passwords.new. The password for the next level is in passwords.new and is the only line that has been changed between passwords.old and passwords.new.

Quick theory​

When you need to compare the contents of two text files line-by-line, the standard Linux utility is diff. It analyzes both files and outputs the specific lines that differ.

• < indicates lines unique to the first file specified in the command.
• > indicates lines unique to the second file specified in the command.

Tools you’ll use:
diff → compares files line by line and prints the differences.
grep → searches for specific patterns within a file (used here to verify which file contained which string).

Solution​

bandit17@bandit:~$ diff passwords.new passwords.old
42c42
< x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO
---
> pGozC8kOHLkBMOaL0ICPvLV1IjQ5F1VA

bandit17@bandit:~$ grep x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO passwords.new
x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO

bandit17@bandit:~$ grep pGozC8kOHLkBMOaL0ICPvLV1IjQ5F1VA passwords.new
bandit17@bandit:~$  

By running diff passwords.new passwords.old, the output immediately reveals the discrepancy at line 42. Because passwords.new was the first file passed to the command, the string preceded by < (x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO) is the line unique to the new file.

To be absolutely certain, we used grep to search for both strings in passwords.new. The string x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO returns a match, confirming it is the updated password for Bandit18.

`

Login: ssh bandit18@bandit.labs.overthewire.org -p 2220
Password: hga5tuuCLF6fFzBgnYw9cB3Srx9_no_a (from Level 17)

task​

The password for the next level is stored in a file called readme in the home directory. However, someone has modified .bashrc to log you out immediately when you log in via SSH.

theory lil bit​

1. SSH Command Execution: Normally, when you SSH, the server starts an interactive shell. However, you can append a command at the end of your SSH string (e.g., ssh user@host command). The server will execute that single command and return the output without initiating a full login shell, effectively bypassing the .bashrc logout script.
2. .bashrc: This is a script file that runs every time an interactive shell is started. In this level, it contains a command like exit or logout, which is why your connection closes immediately upon a standard login.
3. Pseudo-terminal (-t): Sometimes, if a command requires an interactive interface but is being blocked, forcing a terminal allocation with -t can help, or explicitly calling a different shell like /bin/bash --norc (though standard command execution is usually enough).

solution​

Method 1: Direct Command Execution​

By appending the command to the end of the SSH login, we bypass the interactive login shell entirely.

# List files to confirm the target
ssh bandit18@bandit.labs.overthewire.org -p 2220 ls
# Output: readme

# Read the file directly
ssh bandit18@bandit.labs.overthewire.org -p 2220 cat readme
# Output: cGWpMaKXVwDUNgPAVJbWYuGHVn9zl3j8

Method 2: Requesting a Shell​

You can force SSH to start a specific shell instead of the default one, which may avoid the triggers in the user's standard profile.

# Force a bash shell
ssh bandit18@bandit.labs.overthewire.org -p 2220 /bin/bash
ls
readme
cat readme
cGWpMaKXVwDUNgPAVJbWYuGHVn9zl3j8

`

Login: ssh bandit12@bandit.labs.overthewire.org -p 2220
Password: 7x16WNeHIi5YkIhWsfFIqoognUTyj9Q4

task​

The password for the next level is stored in the file data.txt, which is a hexdump of a file that has been repeatedly compressed. For this level, it is helpful to create a directory under /tmp in which you can work.

theory lil bit​

1. xxd: A tool that creates a hexdump of a given file or standard input. It can also do the reverse, which is what we need here using the -r flag to turn a hexdump back into a binary file.
2. file: This command is your best friend here. It determines the file type by looking at the "magic bytes" (header) of the file, telling you if it's a Gzip, Bzip2, or Tar archive.
3. Decompression Commands:
   • gzip/gunzip: Handles .gz files.
   • bzip2/bunzip2: Handles .bz2 files.
   • tar: Handles .tar files using -xf (extract file).
4. Workflow: The process is iterative: check the file type with file, rename it to have the correct extension, decompress it, and repeat until you get ASCII text.

solution​

# Create a working directory
bandit12@bandit:~$ mktemp -d
/tmp/tmp.50qnmYRfkb
bandit12@bandit:~$ cd /tmp/tmp.50qnmYRfkb
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ cp ~/data.txt .

# Reverse the hexdump
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ xxd -r data.txt > binary

# Repeated decompression based on 'file' command output
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file binary
binary: gzip compressed data...
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ mv binary b.gz && gunzip b.gz

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file b
b: bzip2 compressed data...
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ mv b file.bz2 && bunzip2 file.bz2

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file file
file: gzip compressed data...
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ mv file file.gz && gunzip file.gz

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file file
file: POSIX tar archive (GNU)
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ tar -xf file

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file data5.bin
data5.bin: POSIX tar archive (GNU)
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ tar -xf data5.bin

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file data6.bin
data6.bin: bzip2 compressed data...
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ mv data6.bin data.bz2 && bunzip2 data.bz2

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file data
data: POSIX tar archive (GNU)
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ tar -xf data

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file data8.bin
data8.bin: gzip compressed data...
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ mv data8.bin hello.gz && gunzip hello.gz

# Final Result
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file hello
hello: ASCII text
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ cat hello
The password is FO5dwFsc0cbaIiH0h8J2eUks2vdTDwAn

`

Login: ssh bandit13@bandit.labs.overthewire.org -p 2220
(you already logged in as bandit13 and found sshkey.private in the home directory)

Task

You are given a private SSH key file (sshkey.private) in the bandit13 home directory. Use that key locally to connect to the bandit14 account. After you successfully ssh to bandit14, read the file /etc/bandit_pass/bandit14 to get the next level password.

Quick solution (commands)​

# copy the private key from the remote host to your local machine
scp -P 2220 bandit13@bandit.labs.overthewire.org:sshkey.private .

# secure the key locally (OpenSSH requires strict permissions)
chmod 600 sshkey.private

# use the key to login as bandit14
ssh -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org

# once logged in as bandit14, read the password for the next level
cat /etc/bandit_pass/bandit14

Theory (a bit more — why this works)​

1. Public-key SSH authentication

   • Instead of a password, SSH can use an asymmetric key-pair: a private key (which you keep secret) and a public key (stored on the server).
   • If the server has the corresponding public key in the authorized_keys of an account, SSH proves you own the private key and logs you in as that account.
   • In this level you were given the private key for bandit14. Possessing that key is equivalent to having the password for bandit14 (for authentication purposes).

2. scp

   • scp copies files over SSH. The -P 2220 option tells scp to use port 2220 (Bandit uses that port).
   • Example: scp -P 2220 bandit13@...:sshkey.private . copies sshkey.private from the remote bandit13 home to your current local directory.

3. File permissions matter

   • OpenSSH refuses to use private key files that are readable by group or others. If a private key file is group/world-readable SSH prints a warning like:

     Permissions 0640 for 'sshkey.private' are too open.
     

   • The correct permission for private keys is `` (-rw-------) so that only the file owner can read/write it. 700 (-rwx------) also works but is non-standard (private keys usually don't need execute bit).
   • Use chmod 600 sshkey.private to fix permissions.

4. Windows line endings

   • If the key was moved through Windows or edited with a Windows editor, it may contain CRLF ( ) line endings. SSH expects Unix LF ( ). Convert with dos2unix or a tr command if needed.

5. Troubleshooting

   • If SSH refuses to authenticate, add verbose output to see why:

     ssh -vvv -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org
     

     Look for messages about Offering public key and Authentication succeeded or Permission denied.
   • If you still get Permission denied (publickey), confirm:
     • The key file content is intact (no accidental edits).
     • File permissions are 600 and ownership is your user.
     • You used the correct user (bandit14) and port (2220).

6. ssh-agent alternative

   • Instead of passing -i every time, add the key to your agent (keeps it in memory):

     ssh-add sshkey.private
     ssh -p 2220 bandit14@bandit.labs.overthewire.org
     

Full explained session (step-by-step)​

1. On the remote server (bandit13) — you discovered the key:

bandit13@bandit:~$ ls
sshkey.private

2. From your local machine — copy the key here for use:

scp -P 2220 bandit13@bandit.labs.overthewire.org:sshkey.private .
# you will be prompted for the bandit13 password

3. Secure the key file

# make it readable only by you
chmod 600 sshkey.private
# verify
ls -l sshkey.private
# output should look like: -rw------- 1 youruser yourgroup 1675 Sep 19 12:34 sshkey.private

4. Attempt SSH using the key

ssh -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org

• On first connect you'll likely be asked to accept the host fingerprint — answer yes.
• If the key works you'll be dropped into a shell as bandit14.

5. Read the next-level password

cat /etc/bandit_pass/bandit14
# this prints the password you need for the next level

Example (what you might see)​

$ scp -P 2220 bandit13@bandit.labs.overthewire.org:sshkey.private .
bandit13@bandit.labs.overthewire.org's password:
sshkey.private                          100% 1675   1.6KB/s   00:00

$ chmod 600 sshkey.private
$ ssh -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org
The authenticity of host '[bandit.labs.overthewire.org]:2220 ([IP]:2220)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
Welcome to bandit...
$ cat /etc/bandit_pass/bandit14
<the-password-for-bandit15>

Cleanup & security reminder​

• This is a game environment, but in real life never share private keys publicly (e.g., push them to GitHub). Remove keys from your local machine when you no longer need them:

shred -u sshkey.private   # securely delete
# or simply: rm sshkey.private

• If you ever suspect a private key has been exposed, revoke it on the server (remove the corresponding public key from ~/.ssh/authorized_keys) and generate a new key pair.

If you want, I can:

• shorten this into a one-page README.md suitable for GitHub, or
• create a small diagram explaining public/private key flow, or
• add the exact ssh -vvv debugging output to the doc (if you paste your session output).

Tell me which you prefer and I will update the file.

`

Bandit Level 14 → 15​

Login : ssh bandit14@bandit.labs.overthewire.org -p 2220​

password : MU4VWeTyJk8ROof1qqmcBPaLh7lDCPvS​

Task​

Send the current password to a service listening on port 30000 on localhost. The service will respond with the password for the next level.

Quick theory​

The current password for your level is stored in /etc/bandit_pass/bandit14. nc (netcat) can open a TCP connection and send data: echo "<password>" | nc localhost 30000 The service expects the correct current password on stdin and prints the next-level password when correct.

Solution​

Read the current password and send it to the service:

bandit14@bandit:~$ cat /etc/bandit_pass/bandit14
MU4VWeTyJk8ROof1qqmcBPaLh7lDCPvS

bandit14@bandit:~$ echo "MU4VWeTyJk8ROof1qqmcBPaLh7lDCPvS" | nc localhost 30000
Correct!
8xCjnmgoKbGLhHFAZlGE5Tmu4M2tKJQo

(If you get Wrong! Please enter the correct current password., double-check you sent the exact contents of /etc/bandit_pass/bandit14 including case and with no extra whitespace.)

`

Bandit Level 15 → 16​

Login : ssh bandit15@bandit.labs.overthewire.org -p 2220​

Password : 8xCjnmgoKbGLhHFAZlGE5Tmu4M2tKJQo​

Task​

Send the current password for bandit15 to a service listening on localhost:30001. This time, the service requires an SSL/TLS connection. If the password is correct, the server will return the next password.

Quick theory​

openssl s_client -connect host:port lets us establish an SSL/TLS connection to a given service. Adding -quiet suppresses certificate and debug output, making it easier to see just the server response. We can provide the password directly using input redirection <<< "password" or piping echo "password" | openssl ....

bandit15@bandit:~$ openssl s_client -connect localhost:30001 -quiet <<< "8xCjnmgoKbGLhHFAZlGE5Tmu4M2tKJQo"

Can't use SSL_get_servername
depth=0 CN = SnakeOil
verify error:num=18:self-signed certificate
verify return:1
depth=0 CN = SnakeOil
verify return:1
Correct!
kSkvUpMQ7lBYyCM4GBPvCvT1BfWRy0Dx

`