Bandit

These are the easiest problems of the wargame prepping us for the reverse engineering and tougher challenges that lie ahead. We have a series of 34 machines to ssh into, and each machine holds the password to the next machine. It is highly recommended to solve the challenges on your own before proceeding to look for the solution. The solutions provided are for educational purposes only.

Useful Resources are(not exhaustive in any sense).

• SED Manual
• Using screen, a terminal multiplexer
• Linux Man pages

Bandit0

Simply cat of the file, which reveals the flag.

Bandit1

The filename has hyphen. So “cat” has to be told the filename is not a aprameter, so it was fed from the stdin using the following command.

cat &lt -

The flag is then revealed.

Bandit2

There are spaces in the filename. Easier than the last one, use cat “spaces in the filename”.

Bandit3

The file is hidden, and seeing the hidden files via

ls -al 

will reveal the name of the file which can be then read

Bandit4

Familiarity with the usage of the find command in UNIX. More information can be found on the man page of the find command. which can be used to even chain executing commands on the results of the find like below The file command gives details about the files in the directory. So? We can pipe the results of the find command to the file command and voila.

man file

For finding executable one can use this, (is certainly one of the cleaner ways to do this)

find -type f | xargs file | grep text

We use the find command to restrict the file size, and specify that we are looking for a file and then pipe it to xargs file (Argument of file command), then using gre[]

## Bandit5

Simple modification of the challenge 4. Only catch is implemented in the size command which cna be used by -size option. The command to be used here is as follows.

find -type f | xargs file | grep text

## Bandit6

We can use the find command to locate the necessary group and username owner of the file.

find / -user bandit7 -group bandit6 -size 33c 2&gt/dev/null

## Bandit7

No find command required, since it is already given to us. We can use awk, or sed to search for strings within the fiel, but in this case simple grep can do the job.

sed -n '10,$ { /millionth/ { =; p; } }' data.txt

## Bandit8

We have to find a non unique line. We can use uniq command, but it only works on adjacent lines so we need to sort. Hence the following chain.

sort data.txt | uniq -u

Bandit9

Find a human readable line within a file (ASCII Text), which begins with “==”. Here we can use the strings command, followed by a grep.

strings data.txt | grep ^==

Bandit10

Simple base64 decode of the data present in data.txt

base64 -d data.txt 

Bandit11

Using sed, which is a beast of a tool. One may use tr tool as well

sed -e "y/${alpha}/${alpha:$rot}${alpha::$rot}/" -e "y/${beta}/${beta:$rot}${beta::$rot}/" data.txt

What sed is basically a stream editor First of all there are 2 stream editor expressions in place.

Bandit12

The challenge basically involves uncompressing a file which has been compressed multiple times, using different forms of compression. One could write a program to uncompress the file automatically based on the compression types. The whole idea is to identify the file compression type , and then uncompress accordingly. Since it is in the hexdump representation of a file, the first step would be to get the file back from the hex representation.</br> Steps

Create a copy of the file and move it to a created directory in /tmp. This is because the directory in which the file is located in does not have write access for the user.

xxd is an utility that helps reverse and generate hexdumps of files.

xxd -revert data &gt datahex

These are the sequence of commands that were performed to uncompress a file. Each one is preceded by checking the file type of the output using the file command.

        zcat revhex &gt data_zcatted
        bzip2 -d data_zcatted
        zcat data_zcatted.out &gt data_zcatted_again
        tar -xvf data_zcatted_again
        tar -xvf data5.bin
        bzip2 -d data6.bin
        tar -xvf data6.bin.out
        zcat data8.bin &gt data8_zcatted

Bandit13

Simple ssh using an already present and generated private RSA key for the next user.

ssh -i sshkey.private bandit14@localhost

Bandit14

This was done by viewing the password of the users contained in the folder /etc/bandit_pass for the current user and submitting it via telnet

Bandit15

The ssh version of the above challenge. The only challenge is to incorporate a new line character after the banner is sent by the server.

openssl s_client -ign_eof -connect localhost:30001

The flag “ign_eof” is used to allow for end of line to be entered to terminate the condition.

Bandit16

Using nmap we can find out a range of open ports that support ssh

nmap  -A -T4 -p 31000-32000 localhost

After we get to know the port on which ssl is running, the tmp directory gets the sshkey.private being returned by the server, which is the private key of user bandit17 The server will be running on some port which is not an echo server. Use openssl to connect to this ssh server in the eof mode as described in Bandit15. On entering the correct password, the server will reply back with an RSA private key for bandit user 17.

Copy the contents, create a file in the tmp directory. Note: Change the permissions of the newly created file to be restrictive of read and write privilleges to only the current user or the ssh will reject the file as being too "unprotected". I set the permission to file to 700.

Bandit17

Simple diff command of the 2 files will pop out the answer.

Bandit18

The machine logs you out as mentioned in the description due to changes in .bashrc which happens when user profile is loaded after a successful login. This can be overcome by chaining a command to ssh to be executed after successful login.

ssh bandit18@localhost "cat readme"

Bandit19

The knowledge of setuid and getuid is useful. The commands basically allows users to execute certain executables as other users or groups and the command is used to set the appropriate bit on the executable. For next level, the executable will allow us to read the bandit20’s pass. Anyone executing the executable will run it as if it were bandit20 user running the executable.

./&gtexecutable name&lt cat /etc/bandit_pass/bandit20

Bandit20

Using the same principles as above, except setup a netcat background process or use 2 parallel terminals. However since parallel terminals will lead to 2 different sessions and we want the output back from a process, I used a terminal multiplexer, like screen. Firstly we create a session using one ssh login. Then we setup a separate instance of screen, by using the tool screen. Once done, we setup a netcat listen as under.

nc -l -p 44444
 

Detach from this screen by pressing CTRL+a,d. Then start another screen, and run the executable to connect to the running netcat shell which will return the pass of user bandit20 to the ssh connection. The need of the multiplexer here is because, if we create a separate ssh session, the sessions will be sperate terminal wise and hence we cannot see any data or information from the other terminal. It will occur not immediately but after a while that we need to have the terminal to somehow split or multiplex but for the same session. This made me look up terminal multiplexers, and also they had hinted the tool in the challenge as well which pushed me in the right direction.

 ./suconnect &ltportnumber&gt 
 

Reattach to the netcat screen using

 screen -r &ltscreenid&gt
 

Doing this will give you the output on the screen which is pass of bandit21

Bandit21

Examining the cronjob we know it is run every minute and , simply we need to examine the script being executed and then we know the directory/filename of the stored password.

Bandit22

Simple variation in which the value of the directory is not hardcoded, we need to run the code with the variable as “bandit23” instead of the current user. The file cannot be executed by any user other than cron and bandit23, so when we can do a line by line execute on the bash shell and recover the directory.

Bandit23

The cron is calling a script (cannot be editied), which is deleting all the scripts in /var/spool after executing them. The trick is to place a script there which fetches the bandit24 password (since cron is of bandit24 it can do so), and place it in “/tmp” in some file. The important thing is that even though cron is executing a script under bandit24, the file created in /tmp will be accessible. The script can be found at bandit23.sh.

Bandit24

Easy as before, instead of a simple script , we need to bruteforce the pins which ranges from 0000 to 9999. We need to write a simple bash or python script to bruteforce a netcat connection. A further improvement which is desired, is to utilize a single instance of netcat. Refer to the code for reference which is in bash. bandit24.sh

Bandit25

By far the most creative challenge of the lot, the problem is we get logged out as soon as we use the ssh key to login. Unlike one of the previous challenges, this is not a .bashrc or a .bash_profile issue. The issue is the shell of the user which is logging us out. We can see the shell of the user by:

cat /etc/passwd

This reveals that the shell of the user is a custom script and its location as well. On reading the custom script, we find that it is a simple more command calling a file.When the more command terminates, exit 0 is called logging us out. Now, more somewhat like less is a scrolling command which loads a page bit by bit on a small window. Once we have this, we have to find a way to halt at more, so that “exit 0” is not hit. We can do this by minimizing our terminal, and then more will proceed step by step. Once it is done, we can break “more” by using “v”.

On pressing v, we are in Vim, we can edit a file by typing :e Then we can simply read the pass by specifying the file path of the password.

Bandit26

This is a continuation of the previous challenge. We can get the password of bandit26, but for getting password of bandit27 , we need to break out of the shell. If we do a simple,:shell, then we get back the original shell with more, making us go back to square one. So , to do this we have to set the shell variable to /usr/bin/bash>. We can do so by doing by <pre> set shell=/usr/bin/bash </pre> Once this is done we can break out of the shell, do a simple ls and get the password of the next user.

Bandit27

The challenges from Bandit27-Bandit31, require the basic know how of how version control systems work, especially git. If you don’t know, then there is no point wasting time to solve these challenges. A basic knowhow will atleast enable one to understand what is happening and why. A simple git cloning will reveal the username and password of the next user. The command is as under.

git clone &ltURL&gt /tmp/&ltsomedirectory&gt

Bandit28

Similar to above but here, this was comitted previously. Using the command git log(inside the directory cloned) after cloning the directory will reveal us the commit history. Select the tag in which the password was removed from the Readme.md file and use the command git show &lttagname&gt.

Bandit29

In this case doing git log will show the commit history but will not show any intersting commits. The hint lies in the Readme.md file itself which says no passwords in production. This hints that we are seeing a different “branch”. Doing a <pre> git show-ref </pre> Then we get to know the commits and references across branches. Again using git show as described above we can get the required commit under “dev” branch which is short for development, revealing to us the password.

Bandit30

This involves a tag with a broken commit, which prevents checkout or cloning. This tag can be viewed by using our friend the git-show command as well as before.

Bandit31

This is a simple add, commit and push. Add the file, commit it then push it. The verbose message from the remote will contain the password

Bandit32

This final challenge is a bit tricky, and there are multiple approaches to solving this which may be far more creative than what I did. Basically we are in a custom shell, which converts everything that we type to upper-case rendering every command useless. We can’t do “ls” or “cd”. Intuitively, this script or shell must have been called by some parent process or script. Using $0 will call the parent script from within. Since “0” and “$” are not alphabets, the shell will let us drop back in to the parent “sh” shell.