Try to look again in the SYNOPSIS and DESCRIPTION sections of the ssh man page and see if you can manage to find how to specify a port to connect to the remote host

Using the -p option allows us to specify a port to connect to. Our updated command ends up looking like this :

ssh -p 2220 bandit.labs.overthewire.org

:bulb: It is a good practice to put all option arguments before any non-option argument

Once again, you have to look into the sections SYNOPSIS and DESCRIPTION of the ssh man page.
The argument you are looking for is now one that allows you to log in as a given user on a remote machine.

Using the -l option allows us to specify the user that we want to log into on the remote machine.
Our full command looks like : ssh -p 2220 -l bandit0 bandit.labs.overthewire.org. Once we get the login prompt, we can now enter the password and successfully login to the first level.

Why don't you look into the ls man page to ensure that the file you're looking for is really there?

The command we are looking for is ls. This will allow us to list the directory files and ensure that the file we are looking for is there

Same as before, we can look into the cat man page to get to know the cat utility.

The command we're looking for is cat readme. It will allow us to retrieve the contents of the readme file.

Options can also be numbers

The -1 option is the option we were looking for

However when using the option we previously found we see the following :

bandit2@bandit:~$ ls -1
spaces in this filename
bandit2@bandit:~$ 

which is exactly the same prompt as before. However, as this option allows us to list one file per line, we know for sure that spaces in this filename is actually the name of a unique file.

By looking into the QUOTING section of the gnu bash manual, can you retrieve all the quoting mechanism that are available to us in order to print this file?

There are 3 quoting mechanism that allow us to print this file :

1. By escaping the spaces with the filename : spaces\ in\ this\ filename. As the \ preserves the litteral value of the character immediately following it.

2. By enclosing the filename within simple quotes : 'spaces in this filename'. As the simple quotes preserve the litteral value of all the characters they enclose

3. By enclosing the filename within double quotes : "spaces in this filename". As the double quotes preserve the litteral value of all the characters they enclose, appart from $, ` and \. As the character we need to preserve is the space, we can also use the double quotes to achieve this goal.

man cd doesn't work here. Indeed, the cd builtin is part of the shell you're using (I'll assume you're using bash).

However, you can view the SHELL BUILTIN COMMANDS section of the gnu bash manual.

To effectively change directory to the inhere directory, we need to run the command cd inhere.

Look at the DESCRIPTION section of ls. The option you're looking for should be near the top

The -a or --all is the option you're looking for. It allows to not ignore the entries starting with a ..
This is the output we get after listing all of our directory contents :

bandit3@bandit:~/inhere$ ls --all
.  ..  .hidden
bandit3@bandit:~/inhere$

Now that we know that the file we're are looking for, we can print its content with cat .hidden

Once again, we'll look in the ls man page, but this time we need to have a look in the SYNOPSYS section.

The command ls --all inhere it the command we're looking for. this command will allow us to list the contents of the inhere directory, without moving nor ignoring the hidden files.
Running it gives us the following output :

bandit3@bandit:~$ ls --all inhere
.  ..  .hidden
bandit3@bandit:~$

Look at the starting points section of the find(1) man page.

When looking in the starting points section of the find(1) man page, we see an optional argument named starting-point. This argument allows the user to specify a starting directory when running the find utility. By default, the starting point is . which is the current directory. So, running find inhere allows us to list the contents of the inhere directory

By looking at the section 2 of the gnu findutils documentation can you retrieve a test that tests for regular files?

The option we're looking for is -type, which allows us to test for the type of file we're looking for. We'll give the -type option the f argument to only look for regular files.
The command we're looking for is find inhere -type f.

Look into the file(1) and the section 3 of the gnu findutils documentation, see if there is an ACTION in the find(1) page that could let you execute the file command on the file you retrieved

The ACTION we're looking for is -execdir. We will use the form -execdir command ; as it is safer than the -exec command ; form (see security considerations. As the ; is a metacharacter, we will need to escape it with a \ to pass it to the find command. For the same reason, we'll have to enclose the brackets {} within simple or double quotes

The command we're looking for is : find inhere -type f -execdir file '{}' \;
Here is an output you could get by running this command :

bandit4@bandit:~$ find inhere/ -type f -execdir file "{}" \;
./-file01: data
./-file02: data
./-file08: data
./-file06: data
./-file00: data
./-file04: data
./-file05: data
./-file07: ASCII text
./-file03: data
./-file09: data
bandit4@bandit:~$

We can now run the command cat inhere/-file07 to get the password string

To get you started, if you want to find (no pun intended) by yourself, here are a few informations to get you on the right track.

Here are the find options we'll use to achieve our goal :

• type
• execdir (x2)
• quit (optionnal)

The command is the following :

find inhere/ -type f -execdir bash -c 'file {} | grep text > /dev/null' \; -execdir cat '{}' \; -quit

Here is a step-by-step overview of the command :

1. The first execdir calls execute the command file {} | grep text > /dev/null on each retrieved file in the inhere directory.

The redirection to /dev/null is to ensure that nothing gets printed on stdout, but the important thing here is actually the exit status of the grep command. See bash invocation for informations about the -c option.

2. The second execdir calls cat on the only human-readable file in the inhere directory
3. The quit option allows us to stop the find utility once we found what we're looking for. To understand what it does, you can replace grep by grep -v in the previous command

Try to look in the section 2 of the gnu findutils documentation.

The option we're looking for is described there. It is the size option.
We are going to invoke it like this : -size 1033c.

This time, we still need to look at the section 2 of the gnu findutils documentation. However, we need to look into two different subsections of this section 2 to complete our option.

The option we're looking for is described there. It is the executable option. However, we need our file to not be executable, so we can see in this section that to negate this condition we can use the -not operator.
We are going to invoke our option like this : -not -executable.

Read about the Root Directory

From the reading material, we know that we can designate the root of the server with the character /. The command find / will allow us to search everywhere in the server.

All the options we're looking for are in the section 2 of the gnu findutils documentation

Let's take a look at the section 2.8. In this section we can see the two options :

• user
• group

Thus we can deduce the resulting command : find / -user bandit7 -group bandit6 -size 33c. We just have to cat the resulting file to get the password.

The information we need lies in two different places. Try to look into :

• the section 3 of the gnu bash manual
• the null(4) man page

In the section 3.6.2 of the gnu bash manual, we can learn more about output redirection. I think this isn't written directly (but I may be wrong) in the documentation, but the find utility writtes its error messages to stderr(see here for a more precise documentation about the stderr file). However, we can redirect the output from stderr by redirecting the file descriptor number 2 to a file.
The file we're going to redirect to is the file /dev/null(we could also redirect to /dev/zero as writing to any of these file has the same effect).
Here is the full command find / -user bandit7 -group bandit6 -size 33c 2> /dev/zero. We can then run cat on the file we retrieved.

Looking into the grep man page, figure out how we can retrieve any line containing the word millionth in the file data.txt

By running the command grep millionth data.txt we can retrieve any line containing the word millionth in the file data.txt. The password string will be the second column of that file

To know how to properly use the cut utility, look into the cut documentation page.

By running the line we got through a pipe and transferring its data to cut we can retrieve only the second field.
Here is the full command :

grep millionth data.txt | cut -f 2

Using the uniq gnu documentation, can you figure out what option we need to keep only the input lines that occurs only once?

The option -u is the option we'll need to complete our goal. Let's break down what it does. Here is a quote from the documentation :

The -u option : "Discard the last line that would be output for a repeated input group. When used by itself, this option causes uniq to print unique lines, and nothing else."
First let's try and see what would be the last line outputed for a repeated input group : it is the first line of the group. This means that uniq -u discards the only line which would be outputed for a group. This indeed means that uniq -u only prints the unique lines.

However we know from the same documentation that uniq operates on consecutive lines, thus we need a way to make the lines consecutive to compare them.

By looking into the sort gnu documentation, can you figure out how to sort the input for the uniq filter to work?

It's fairly simple, we don't need any option at all. By running sort data.txt, we will output the result of the sorted output to stdout.

Try to look in the strings(1) man page and find out how to use the strings utility to achieve this goal

We can use the --all option to ensure that all the file is scanned (this should be the default behavior but under certain implementations, the default behavior could be different so this we'll prevent the exploitation of any BFD library vulnerabilities).
Thus, the command we're looking for is strings --all data.txt, which will dump the human-readable strings to stdout.
Now, we just need to grep the character '=' in this output and look for the password string.

Reading the strings(1) man page, can you figure out an option to achieve this goal?

The option we're looking for is the -n option, we'll call it with -33 which means that we're looking for at least 33 characters long strings.

Here is the full command :

strings --all -33 data.txt

This command prints only one line, which contains the password we're looking for.

Using the information you got about ROT13 by reading the wikipedia page and assuming that the base set is the alphabet (first the Uppercase and then the lowercase letters), set that we will represent like this : A-Za-z which represents the string ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz. How would you represent the set of the translated characters by ROT13?

The set of the translated characters can be represented as N-ZA-Mn-za-m which is to be understood as the string NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm

By taking a look at the section 9 of the gnu coreutils documentation, try to see we can use one of the tool described there to achieve the desired outcome.

By reading the section 9.1.2 we can see that the tr utility is the right tool for us. By using it with the two sets of character we deduced in the previous part and by redirecting the input from our data.txt file, we can achieve the desired outcome.
Here is the full command :

tr 'A-Za-z' 'N-ZA-Nn-za-m' < data.txt

Which will output something along the lines : The password is password_string

Using the 3 links to documentation pages, can you figure out how to move to a temporary directory and copy the data.txt file to it?

We will run the following command :

cd "$(mktemp -d)" && cp "$HOME"/data.txt .

This will move us to a temporary created directory and copy the file that lies at '/home/bandit12/data.txt' to the directory we're in.
We are now ready to work with this file.

Looking at the hexdump and the xxd man pages, can you figure out a way to revert data.txt back to its original state?

The command we're going to use is the xxd command. To use it properly and get the original form of the data.txt file, we're going to specify the outfile we want to write to and specify xxd that we want it to operate in reverse mode.
Here is the final command :

xxd -r data.txt outfile

Where outfile may be any name you want to give to your retrieved data.

By trying to extract our outfile a first time, can you figure out what the sequence of actions is? You might need to use the file utility to achieve that goal.

Here is the sequence of actions we need to follow to successfully extract all the data that has been compressed :

1. We need to find the compression method of our file by running the file utility on it.
2. Then, we might need to rename the file we're looking to uncompress to a file with the right extension (as some compression utilities recognize only some specific extensions)
3. We need to extract the file with the right utility and go back to step 1 until we get an ASCII Text file.

If you're stuck at this time, go to the full solution to get the step by step walkthrough.

Using only the man pages of the commands we used in the previous section, can you figure out a way to write a pipeline that does the exact same thing without creating any file?

The command we're looking for is the following :

xxd -r data.txt | gunzip -c | bunzip2 -c | gunzip -c | tar --to-command='/usr/bin/tar -xO' -x | bunzip2 -c | tar -xO | gunzip -c

You can understand all the options that have been added by reading the man pages of all the utilities involved.

Reading the scp man page, can you figure out a way to retrieve the ssh key from the bandit13 user on the overthewire server?

We'll have to run the command while not connected to the remote server, as the scp protocol will connect to the remote server and retrieve the file for us.
From the scp man page, we know the following : "The source and target may be specified as a local pathname, a remote host with optional path in the form [user@]host:[path], or a URI in the form scp://[user@]host[:port][/path]. Local file names can be made explicit using absolute or relative pathnames to avoid scp treating file names containing ‘:’ as host specifiers.". One precision to add is that the path argument is starting from the user's home directory.

Thus we can deduce the structure of the call we have to make :

• For the source, we will specify the URI as follows : scp://bandit13@bandit.labs.overthewire.org:2220/sshkey.private
• For the target, we will specify the local pathname we want to store the file in, let's say : ./bandit14_sshkey

Thus, the command we're looking for is : scp scp://bandit13@bandit.labs.overthewire.org:2220/home/bandit13/sshkey.private ./bandit14_sshkey

By looking into the FILES section of the ssh man page and the chmod gnu documentation page, can you figure out the right file permissions for the private key and set them accordingly?

In the portion describing the file ~/.ssh/id_rsa, we can read that this file should be readable by the user and should not be accessible by others.
Running the stat utility on the file gives us the file permissions of our ssh private key. Here is the output from this command :

  File: bandit14_sshkey
  Size: 1679      	Blocks: 8          IO Block: 4096   regular file
Device: 804h/2052d	Inode: 8913955     Links: 1
Access: (0640/-rw-r-----)  Uid: ( 1001/ Charystag)   Gid: ( 1001/ Charystag)
Access: 2024-06-03 21:05:42.285372019 +0200
Modify: 2024-06-03 21:05:11.765802230 +0200
Change: 2024-06-03 21:05:11.765802230 +0200
 Birth: 2024-06-03 21:05:11.733802682 +0200

We can now see, (helping ourselves from the documentation about file permissions) that this file is readable and writable by the user and readable by the other members of the user's group. As we don't need to write data to the private key file, we can restrict the permissions to the minimum, we'll only allow the current user (us) to write to the file.
The following call to the chmod utility will allow us to achieve our goal : chmod 400 bandit14_sshkey.

Going back into the ssh(1) man page, can you figure out an option that would allow us to use the ssh key we just got to connect to the user bandit14 ?

The option we're looking for is the option -i which allows us to use our identity_file to connect without the need for a password. This is our full command : ssh -p 2220 -l bandit14 -i bandit14_sshkey bandit.labs.overthewire.org

By using the prompt we get when logging in to bandit14 (or any other overthewire user), can you figure out where is the password for bandit14 stored?

Let's start by recalling the instructions for each level :

  This machine might hold several wargames.
  If you are playing "somegame", then:

    * USERNAMES are somegame0, somegame1, ...
    * Most LEVELS are stored in /somegame/.
    * PASSWORDS for each level are stored in /etc/somegame_pass/.

This tells us that the password we're looking for is in the file /etc/bandit_pass/bandit14. Let's run a quick stat on this file to ensure we can read it. Here is the output from this command :

  File: /etc/bandit_pass/bandit14
  Size: 33        	Blocks: 8          IO Block: 4096   regular file
Device: 10301h/66305d	Inode: 517564      Links: 1
Access: (0400/-r--------)  Uid: (11014/bandit14)   Gid: (11014/bandit14)
Access: 2024-06-03 22:30:53.614318247 +0000
Modify: 2023-10-05 06:19:04.167222286 +0000
Change: 2023-10-05 06:19:04.167222286 +0000
 Birth: 2023-10-05 06:19:04.167222286 +0000

As we're logged in as user bandit14, we know we can access this file which contains the 33 bytes password string we need to complete this level.

Using only the description section of the nmap man page, can you figure out how to scan the localhost network in order to see which ports are in use?

The command we're looking for is nmap localhost, which will allow us to scan the network at 127.0.0.1. Here is the output from this command :

bandit14@bandit:~$ nmap localhost
Starting Nmap 7.80 ( https://nmap.org ) at 2024-06-04 10:17 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00022s latency).
Not shown: 993 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
1111/tcp  open  lmsocialserver
1122/tcp  open  availant-mgr
1840/tcp  open  netopia-vo2
4321/tcp  open  rwhois
8000/tcp  open  http-alt
30000/tcp open  ndmps

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
bandit14@bandit:~$

We can see that the port 30000 is open and accepts tcp connections. This tells us that we need to send the password using the tcp protocol.

By using the TALKING TO SERVERS section of the nc(1) man page, can you figure out how to send the password to the server?

nc will have to read the password from stdin to send it to the server, there are a few ways to do so but one command you could run is the following :

nc localhost 30000 < /etc/bandit_pass/bandit14

which redirects stdin from the file containing the pasword for user bandit 14. Once this is done, you should see the following output :

bandit14@bandit:~$ nc localhost 30000 < /etc/bandit_pass/bandit14
Correct!
password_string

bandit14@bandit:~$

where pasword_string is our 33 bytes characters password string.

By looking at the s_client man page and only looking for the fields that talk about connecting to the SSL server, can you figure out a way to open a connection with the server? The server will read all its input from stdin

By running the command openssl s_client localhost:30001 or openssl s_client -connect localhost:30001, you can open a connection with the server.

By looking at the CONNECTED COMMANDS section of the s_client man page, try to understand why we can observe such a behavior and then, look at the OPTIONS section to see if you can retrieve an option that will fix this behavior.

We can observe such behavior because at the end of any file, there is an EOF character that is interpreted by our s_client command as a signal to close the connection. By using the option -ign_eof we can explicitely tell s_client to keep the connection open, and thus receive the password from the server.
Here is our final command :

openssl s_client -ign_eof localhost:30001 < /etc/bandit_pass/bandit15

By lookint at the PORT SCANNING section of the nc man page, can you figure out a way to perform a basic scan of the ports between 31000 and 32000 with nc?

With nc, we can use the following command :

nc -zv localhost 31000-32000 |& grep -v -E '^nc'

Let's break down how it works :

1. nc -zv localhost 31000-32000 tells nc to report the open ports between the port 31000 and 32000, writing verbose output to stderr
2. |& is a metacharacter that is equivalent to 2 >& 1 | which means to redirect stdout and stderr through a pipe (see pipelines in the gnu bash manual for more information)
3. grep -v -E '^nc' uses the regular expression ^nc to mach lines beginning by 'nc' and the -v option uses the inverted match to match only the lines that don't begin with nc (meaning the only lines that didn't report an error).

Here is the output from this command :

bandit16@bandit:~$ nc -zv localhost 31000-32000 |& grep -v -E '^nc'
Connection to localhost (127.0.0.1) 31046 port [tcp/*] succeeded!
Connection to localhost (127.0.0.1) 31518 port [tcp/*] succeeded!
Connection to localhost (127.0.0.1) 31691 port [tcp/*] succeeded!
Connection to localhost (127.0.0.1) 31790 port [tcp/*] succeeded!
Connection to localhost (127.0.0.1) 31960 port [tcp/*] succeeded!
bandit16@bandit:~$

By using the PORT SPECIFICATION AND SCAN ORDER section of the nmap man page, can you figure out a way to perform a basic scan of the ports between 31000 and 32000 with nmap?

With nmap, it is even more simple. We just need to provide the range of ports to scan as nmap is already a port scanner.

Here is the command we're looking for :

nmap localhost -p 31000-32000

Here is the output from this command :

Starting Nmap 7.80 ( https://nmap.org ) at 2024-06-04 14:27 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00013s latency).
Not shown: 996 closed ports
PORT      STATE SERVICE
31046/tcp open  unknown
31518/tcp open  unknown
31691/tcp open  unknown
31790/tcp open  unknown
31960/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

By taking a look at the SERVICE AND VERSION DETECTION section of the nmap man page, can you figure out how to know on which port resides the service we want to communicate with ?

The -sV option is the option we're looking for, it will allow us to identify the service that lies on each port that we're scanning. As the scan doesn't need to be full (as 4 out of 5 of these services will echo back to the sender all the information they receive), we will enable the option --version-light so that the scan takes less time.

The command we're looking for is the following :

nmap -sV --version-light -p 31046,31518,31691,31790,31960 localhost

We could of course, also run this command on the whole set of ports between the range 31000 and 32000 with nmap -sV --version-light -p 31000-32000.

Here is the output from this command (--version-light is an alias for --version-intensity 2):

bandit16@bandit:~$ nmap -sV --version-intensity 2 localhost -p 31046,31518,31691,31790,31960
Starting Nmap 7.80 ( https://nmap.org ) at 2024-06-04 14:38 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00013s latency).

PORT      STATE SERVICE     VERSION
31046/tcp open  echo
31518/tcp open  ssl/echo
31691/tcp open  echo
31790/tcp open  ssl/unknown
31960/tcp open  echo
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port31790-TCP:V=7.80%T=SSL%I=2%D=6/4%Time=665F2708%P=x86_64-pc-linux-gn
SF:u%r(GenericLines,31,"Wrong!\x20Please\x20enter\x20the\x20correct\x20cur
SF:rent\x20password\n")%r(GetRequest,31,"Wrong!\x20Please\x20enter\x20the\
SF:x20correct\x20current\x20password\n")%r(SSLSessionReq,31,"Wrong!\x20Ple
SF:ase\x20enter\x20the\x20correct\x20current\x20password\n")%r(TLSSessionR
SF:eq,31,"Wrong!\x20Please\x20enter\x20the\x20correct\x20current\x20passwo
SF:rd\n");

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 32.61 seconds
bandit16@bandit:~$

We know now that we can use the s_client command to send the password to the server listening at 31790 and retrieve the ssh key to connect to bandit 17.

Searching again into the s_client man page, can you figure out a way to output the ssh_key directly to a file ?

First, we need to create a file to store the private ssh key, we'll create it using the mktemp utility. Then, using the -sess_out option we will be able to output our ssl session (which is the ssh key) directly to the file.

This is what our set of commands look like :

PRIVATE_KEY="$(mktemp)"
openssl s_client -ign_eof -sess_out "$PRIVATE_KEY" localhost:31790 < /etc/bandit_pass/bandit16`

Then we can run echo "$PRIVATE_KEY" to get the name of the file and use the scp command to retrieve the file on our machine.

By looking at the diff man page, can you figure out how to use the diff(1) utility to output the differences between these two files?

To do so, we simply need to run the following command :

diff passwords.old passwords.new

The lines that are different in passwords.old (the first argument) will appear prefixed by the symbol < while the lines different in passwords.new will appear prefixed by a >. The password is the line that is different in passwords.new

Looking more deeply into the diff man page, can you figure out a way to make the output more readable ?

They are a lot more than one answer.

For example, one could use the option -u to print a string at the beginning of the diff output which will look like the one below :

--- passwords.old	2023-10-05 06:19:27.827277353 +0000
+++ passwords.new	2023-10-05 06:19:27.835277371 +0000

which means that all the lines from passwords.old will be prefixed by - and the lines from passwords.new will be prefixed by +. The diff -u output will be the following :

--- passwords.old	2023-10-05 06:19:27.827277353 +0000
+++ passwords.new	2023-10-05 06:19:27.835277371 +0000
@@ -39,7 +39,7 @@
 WFB9ezoSnb146RUbbX6d9Yx2sU46Q8Ax
 JFkUvvpfLmE7KBkAEePwZndBr33oFzh8
 wDn38KGxWKk7dp39odF7fWLT6aljqEsK
-old_password
+new_password
 RKMlN2JZydt4j5rQjJt07GgNqtgnq8dw
 nssByafsRMwebfyRhMWKSqX39xF1l4Hr
 ZlUzDUTd4faumV8wCtJ4CHA788tySKDO

We can then use the new password to go to the following level.

Once again, look into the ssh man page, find a way to execute a command on the remote host instead of an interactive shell.

To do so, we just need to append the command we want to run at the end of our ssh command, it will then be run instead of an interactive shell when we log in into the user bandit18. Our ssh command is the following :

ssh -l bandit18 -p 2220 bandit.labs.overthewire.org cat readme

Because we need to cat the readme file in bandit18 home directory. It will print the password string to sdout and exit.

Using the example of the bandit20-do executable, can you figure out the command to execute to print the bandit20 password to stdout?

When running the example, we can see the following output :

bandit19@bandit:~$ ./bandit20-do id
uid=11019(bandit19) gid=11019(bandit19) euid=11020(bandit20) groups=11019(bandit19)
bandit19@bandit:~$

We can see that our effective user id (euid) is bandit20 when we run this executable, which means that we can do everything that the user bandit20 can do.

By running the stat command on the file /etc/bandit_pass/bandit20 we see the following output :

  File: /etc/bandit_pass/bandit20
  Size: 33        	Blocks: 8          IO Block: 4096   regular file
Device: 10301h/66305d	Inode: 517599      Links: 1
Access: (0400/-r--------)  Uid: (11020/bandit20)   Gid: (11020/bandit20)
Access: 2024-06-04 21:38:04.747961484 +0000
Modify: 2023-10-05 06:19:06.591227890 +0000
Change: 2023-10-05 06:19:06.595227900 +0000
 Birth: 2023-10-05 06:19:06.591227890 +0000

This tells us that the file is only readable by the user bandit20, however thanks to the bandit20-do executable, we are the user bandit20. We can thus cat this file and retrieve the password string.
Here is the final command :

./bandit20-do cat /etc/bandit_pass/bandit20

Using the CLIENT/SERVER MODEL of the nc command, can you figure out a way to set up a server that will listen for incoming connections and send the password to any client that listens to it?

Let's copy the exact same code from the nc man page example. Here is the command we're going to use :

nc -l 1234

We can now notice that we have an open TCP server that listens for incoming connections. However our server is pretty basic (as it does absolutely nothing), however it can communicate through its standard input and output. Let's try to redirect the standard input of the server from a file.

By running the following command :

nc -l 1234 < /etc/bandit_pass/bandit20

We have a server listening on the port 1234 that will send the password for bandit20 to any host that tries to connect ot it.

By using the Helpful Reading Material, can you figure out a way to run our server as a background process so that you can continue communicating with the server using your current terminal session?

To continue communicating with the server using the current terminal session, we need to launch it asynchronously, this means that the exit status of our command will be 0 and that bash won't wait for the completion of your command to give us back the control of our terminal session.

Here is the command we're going to execute.

nc -l 1234 < /etc/bandit_pass/bandit20 &

It will tell bash to run this process as a background process, which will allow us to run our TCP client to retrieve the password for the next level.

We just need to run the executable suconnect and to specify it the right port number.

Here is the output from that command :

bandit20@bandit:~$ ./suconnect 1234
Read: bandit20_pass
Password matches, sending next password
bandit21_pass
[1]+  Done                    nc -l 1234 < /etc/bandit_pass/bandit20
bandit20@bandit:~$

You can see that on the last line, bash reports that the our server in the background has returned as it closes after receiving one connection.

By analysing the files into the /etc/cron.d directory, can you retrieve the contents of the script that runs for the bandit22 user?

Here is the output from the ls command for the /etc/crond.d directory :

bandit21@bandit:~$ ls /etc/cron.d
cronjob_bandit15_root  cronjob_bandit17_root  cronjob_bandit22  cronjob_bandit23  cronjob_bandit24  cronjob_bandit25_root  e2scrub_all  otw-tmp-dir  sysstat
bandit21@bandit:~$

We see that there is a file named cronjob_bandit22 in the directory. Let's cat the contents of this file :

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

This shows us that there is a cronjob running every minute for the user bandit22. We are going to go on and print the contents of the script :

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

This finally tells us that the password for the user bandit22 is stored in the temporary file which name is written in the script and that is readable by everyone.

We can go on and finally retrieve this password to jump to the next level.

Using the useful commands, can you figure out what the script does and in which file it prints the password for the next level?

Let's analyse this script.

• The myname variable hold the output of the command whoami, which prints the username associated with the current user id. As this script is ran by bandit23, we know that the value of the myname variable is bandit23.
• The mytarget variable holds the output of the following pipeline (where myname has been replaced by its value) : echo I am user bandit23 | md5sum | cut -d ' ' -f 1.

The md5sum utility will hash the phrase it receives on standard input and output something following this format :

hashed_phrase filename

with hashed_phrase and filename separated by a space (here filename is - because the file is standard input). Finally, the cut utility will retrieve only the first field (by splitting the fields using the space character), which is the hash of our phrase.

As standard input and standard error are redirected to /dev/null, we won't see the output from the echo command, however we can notice that the password for bandit23 is printed in the file /tmp/hashed_phrase.

Thus, we know that by running the following command :

cat /etc/8ca319486bfbbc3663ea0fbe81326349

we can retrieve the password for the bandit23 user.

Using the useful commands and the helpful reading material, can you figure out what the script does?

We already know from the previous level that the script changes the directory to /var/spool/bandit24/foo as bandit24 is the value contained in the myname variable.

The script then executes as follows :

1. for all the files and the hidden files in the directory, it executes a loop (see Filename Expansion for more explanations about how the patterns are matched).
2. In this loop, if the filename is not '.' or '..', then it does the test that follows.
3. The call to the stat command only prints the username of the owner of the file. So if the owner is bandit23 (which is us), it runs the following command.
4. The call to the timeout utility runs the script for at most 60 seconds and then sends a SIGKILL signal to the script to ensure it stops.
5. Regardless of whether the script was executed or not, the script is removed, which means that the directory ends up being totally empty at the end of the cronjob execution.

Using the previous level, can you design a simple script to print bandit24 password in a way we can retrieve it? Recall that all output is redirected to /dev/null, which means you may have to create a file where bandit24 will be able to write the password to.

For this basic script, we'll copy the model of bandit22. This means that we'll write a simple script that prints the password to a custom file. Here is the script we'll use :

#!/usr/bin/env bash

filename="$(echo Hello my fellow mates | md5sum | cut -d ' ' -f 1)"
cat /etc/bandit_pass/bandit24 > /tmp/${filename}

We're going to store this script in a file called script (but you can use any name you want) and copy this file to the right location, which is /var/spool/bandit24/foo. We will then run a for loop to check for the script presence in this folder (in order to know whether or not the script has executed and to see if it has done what we want)

1. First, we're going to go in a temporary directory (with cd "$(mktemp -d /tmp/hello_fellow_mates.XXXXXXXXXX)") Don't worry about the funny name template, I just though it was funnier that just using tmp everytime
2. Then we are going to write our script to a file called script
3. Then we are going to run the following commands :

cp script /var/spool/bandit24/foo/script
echo -n Waiting for cronjob
while stat /var/spool/bandit24/foo/script >& /dev/null ; do echo -n . ; sleep 1 ; done 
echo -e '\n'cronjob executed

The last part allows us to monitor (using the stat command that returns true if it found the script at the specified location) the script and see when it is executed (thus meaning that we should expect an output).

By reading the File Permissions section of the gnu coreutils documentation, can you figure out how to set the right file permissions for the script to actually execute?

Lets run a quick stat on our script file. We will run the following command :

stat -c '%A Uid: (%u/%U)  Gid: (%g/%G)' script

to print only the relevent information. Here is the output from that command :

-rw-rw-r-- Uid: (11023/bandit23)  Gid: (11023/bandit23)

This tells us no one is allowed to execute the script. As bandit24 is not in the group bandit 23 (see the group man page for more informations about it). We can deduce that bandit24 belongs in the others category.

By running the following command :

chmod o+x script

We can allow the other users to execute the script, thus allowing bandit24 to execute the script. We can then run our precedent set of commands :

cp script /var/spool/bandit24/foo/script
echo -n Waiting for cronjob
while stat /var/spool/bandit24/foo/script >& /dev/null ; do echo -n . ; sleep 1 ; done 
echo -e '\n'cronjob executed

And then, when we run cat /tmp/"$(echo Hello my fellow mates | md5sum | cut -d ' ' -f 1)", we can see the password printed to stdout.

Using what we did before and the Helpful Reading Material, can you figure out a way to write a script that will be able to create a file in our temporary directory? You will have to make another call to chmod to get all the file permissions right.

Here is our script :

#!/usr/bin/env bash

cat /etc/bandit_pass/bandit24 > /tmp/hello_fellow_mates.1JNCwI8su9/bandit24_pass

Let's run a quick stat, but this time on our directory :

bandit23@bandit:/tmp/hello_fellow_mates.1JNCwI8su9$ stat -c '%A Uid: (%u/%U)  Gid: (%g/%G)' .
drwx------ Uid: (11023/bandit23)  Gid: (11023/bandit23)
bandit23@bandit:/tmp/hello_fellow_mates.1JNCwI8su9$

Here we can see that others don't have any right to write to the directory nor to access its files. Let's call chmod on our directory to set the right permissions :

chmod o+wx .

Then, by putting our script back into the /var/spool/bandit24/foo directory, we will see the file bandit24_pass created after the cronjob execution.

By using the nc utility, can you figure out the format of the string you should send the daemon in order to craft your brute-force attack?

Using nc, we can speak with the daemon and run the following tests :

bandit24@bandit:/tmp/abcdef.PtK5$ nc localhost 30002
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.
bandit24_password 0000
Wrong! Please enter the correct pincode. Try again.
bandit24_pasword 0001
Wrong! Please enter the correct pincode. Try again.
^C
bandit24@bandit:/tmp/abcdef.PtK5$ 

Using that information, we know the format of the string we're supposed to send to the daemon to try to bruteforce the password. Let's know try and use this knowledge to craft our brute-force attack.

Using the Brace Expansion, the Looping Constructs and the printf sections of the gnu bash manual, can you figure out a way to generate all the combinations for our attack?

You'll be able to find a lot of solutions following the same pattern all over the internet. Let's try to do something a bit different.

We are going to use a for loop, but not the one that depends on a pattern, the one that depends on an arithmetic expression.

Here is what our loop is going to be :

for (( i=0 ; i < 10000 ; ++i )) ; do printf "%s %04d\n" "bandit24_pass" "$i" ; done

Here is a detail of what our loop does :

1. For all the integers between 0 and 9999 it does the following :
2. It prints the string bandit24_pass alongside the value of the integer (padded with zeros to fit a field width of 4 characters)

Using our newly constructed for loop, can you figure out a way to use nc to retrieve the password?

Here is how we are going to use our for loop to retrieve the password.

for (( i=0 ; i < 10000 ; ++i )) ; do printf "%s %04d\n" "bandit24_pass" "$i" ; done | nc -w 10 localhost 30002

This loop will test all the 10000 strings against the server pin and will be enough to retrieve the password.

The -w option of nc allows to specify a timeout in case the connection becomes idle. If the timeout is reached, the connection will be closed.

Using our command from the last part, would you be able to add a simple check to ensure that the server doesn't test all the attempts at the same time but waits a bit before sending each chunk of tests.

Here is the updated command :

for (( i=0 ; i < 10000 ; ++i )) ; do if (( $i%500 == 0 )) ; then sleep 1 ; fi ; printf "%s %04d\n" "bandit24_pass" "$i" ; done | nc -w 10 localhost 30002

The if check ensure that the server gets time to process the input, ensuring that it won't block after a given amount of requests.

Using the passwd(5) man page, can you figure out a way to retrieve the shell that bandit26 gets when it logs in and to view its contents?

Using the passwd(5) man page, we know that the informations for the bandit 26 user are stored in the /etc/passwd file. This file is readable by everyone so we can print its content and grep only the lines containing bandit26. Here is the command we'll run, alongside its output :

bandit25@bandit:~$ cat /etc/passwd | grep bandit26
bandit26:x:11026:11026:bandit level 26:/home/bandit26:/usr/bin/showtext
bandit25@bandit:~$

We know from the passwd(5) man page that the last field is the bandit26 user's shell : /usr/bin/showtext.

Let's print the contents of this file :

#!/bin/sh

export TERM=linux

exec more ~/text.txt
exit 0

We see here that the script sets one variable TERM and then runs the more utility.

One thing we can already notice is that the showtext executable doesn't take any argument, so we won't be able to ssh our way into bandit26 account running a command like we did in level18 (see how ssh commands are run for more explanations). We'll have to find another way to get in.

By doing some tests with files on your own computer, can you figure out when more is scrollable and where it isn't? Doing so, could you make it scrollable when logging in into bandit26 and find which command to run to get a text editor?

Although it is not very intuitive, you might have noticed that when the window size is smaller than the number of text lines, more becomes scrollable. We're going to use this capability of the more utility to break out of it. Let's minimize our window to less than 6 lines and then ssh into bandit26.

There might be a more elegant solution through the use of a terminal multiplexer like tmux but the idea will basically be the same. I'll provide a solution using tmux(1) once I learn to use it.

We can now enter commands (see more man page for the full list). We are going to use the v command in order to open the vim editor.

We can now bring our window size back to normal.

Using the various remaining commands file of the vim help manual, can you figure out a way to get a shell while in the vim editor?

The command :shell is the one we need. Remember that you need to press <ESC> first to get into normal mode. However, when running it for the first time we can see that nothing seems to happen. The truth is that something really happened in front of our eyes. The shell of the user bandit26 was launched and then exited as it is the showtext executable.

To convince yourself that it really happened, you can minimize the window to less than 6 lines before running the :shell command

We now need to change the default shell for user bandit26 in order to finally get out of that showtext hell.

Using the Vim Documentation Options, can you figure out how to view, then change, the shell we're using when running the :shell command?

The command we're looking for is :set which allows us to view/change settings for the options we specify.

By running :set shell we can view the shell we're using (which in our case outputs /usr/bin/showtext).

To change the shell, we just have to run :set shell=/usr/bin/bash, we can then run :shell and get a shell for the user bandit26.

By doing the first part of the gittutorial and reading the git-clone man page, can you figure out a way to retrieve the repository located at ssh://bandit27-git@localhost/home/bandit27-git/repo ?

Note : You might need to create a temporary directory

Lets first change directory to a temporary directory with cd "$(mktemp -d /tmp/bandit27git.XXXXX)", then we can run the following command :

git clone ssh://bandit27-git@localhost:2220/home/bandit27-git/repo

Remember that we have to specify the port as we're not connecting using the port 22 (ssh default's port) but the port 2220.

We can then enter the password for bandit27-git (which is the password for bandit27) and we see the repository repo appear in our temporary directory.

We can now try to retrieve the password.

Try listing the contents of the directory.

By running cat README.md we can retrieve the password for the next level.

As git stores the whole history of the file modifications, looking at the git-log man page, can you figure out a way to view the history of the git repository?

By running the git-log command, we can see that the commit history talks about missing data that has been added and the commit we're on talks about a memory leak. Our next goal will be to check for differences between the HEAD which is the point we're on in the history (usually after the last commit) and the commit that talks about missing data.

Looking at the git-show man page, can you figure out a way to view the differences between the README at the current commit and the README at the previous commit?

Using the git-show command, we can provide the hash of the commit we want to view

Note : We don't need to provide the full hash and the 5 first characters are usually enough

Let's run the following command in our terminal :

git show f08b9

This will print the last change in the README.md file, thus printing the password string.

By looking at the git-branch man page, can you figure out a way to list all the branches in the repository?

We want to list all the branches of the repository. Let's run the following command :

git branch -a

This will list all the local branches (which is only master at the moment) and all the remote tracking branches. The following command outputs 3 branches : dev, master and sploits-dev. Let's now see if we can retrieve the password in one of these two other branches.

Looking at the git-diff man page, can you figure out a way to view the differences between the master branch and the other branches?

Let's try and run the following command :

git diff remotes/origin/dev

We need to use remotes/origin/dev because the dev branch is not tracked locally. To track the remotes/origin/dev locally you'd have to run git checkout dev first.

When running the following command, we can see that the password is on the dev branch and use it to connect to the next level.

Using the git-tag command, can you figure out how to view all the tags of the git repository?

Let's run the following command :

git tag

This allows us to list all the tags within the git repository. This command outputs a secret tag which seems to be the door that separates us from our password.

Using again the git-show man page, can you find a way to retrieve the informations within the secret tag?

Let's run the following command :

git show secret

This command let's us view the informations that were added during the tag creation. Of course they include this level password, thus allowing us to jump to the next level.

Using the git-add man page and the Gitignore Documentation, can you figure out a way to stage the key.txt file?

When we run git add key.txt, we get the information that the key.txt file has been marked as ignored by git (you can cat the .gitignore file in order to understand why. Thus running the following command :

git add -f key.txt

This allows us to tell git to add the key.txt file even if git has been told to ignore it.

Using the git-commit and the git-push man pages, can you figure out how to push the file to the repository?

Each commit must have a, preferably explicit, commit message. Then after taking our snapshot of the state of the repository, we can then push our set of snapshots to the remote repository. We can use the -m option of git commit to specify the message on the command line.

Here are our two commands :

git commit -m "explicit commit message"
git push

As we followed all the instructions, we get the password for the next level in the response.

By testing and trying to run some commands, can you describe the effects of the uppercase shell and can you see what type of input will be unaffected by the effects of that shell?

Now that we made some tests with the uppercase shell, we can notice that it converts all of our input to uppercase before feeding it to an actual shell. From that, we can deduce that the only input that will stay unaffected by the effect of this shell will be shell variables (as they are usually already uppercase).

Using the special parameters section of the gnu bash manual, can you figure out which variable to use to get a shell?

As the uppercase shell actually converts our input to uppercase before feeding it to an actual shell, the $0 variable contains the name of the shell it invokes. Thus, by running the following command :

$0

We can then get an actual shell and use it to cat the bandit33 password.