Hi! I'm Karthik Rajkumar, and this markdown file is a documentation of the problems I have to solve in order to advance in OverTheWire's Bandit course.
The 0th level of the Bandit course is a simple one. Log into the bandit remote server via SSH. This was a bit tricky to me since I had no prior experience with SSH (I knew the meaning and purpose it had, but never worked with it). One youtube video later however caught me up to speed and I managed to log in successfully, via OpenSSH on my Windows machine.
Now I had to access level 1, via a password found in level 0. It was contained in a readme text file, and was easy enough to open via the cat command. I had prior experience using bash commands from a Version Control course i took in my 1st year (I don't think I ever completed it though... haha...).
After logging into level 2, the password for the next level was contained in a dashed filename. For a character like this, I had to preceded the filename with a './' to open it.
Now the password for the next level was contained in a filename with spaces in it! Easily accessed by just wrapping the name in double quotes when using cat.
Now there was no file but a directory called "inhere". Moving into the aforementioned directory, I found... nothing. It must be a hidden file then, so I used the ls command with the option -a to list all files, including hidden ones. Reading the hidden file, I got the next level's password.
Now there was a bunch of files, but only one of them was human-readable text ; the one with the password. I could cat each file, but that would be tedious... so i decided to use the file command, to see what files were of what type!
Oh wow. Now there were a BUNCH of directories in the inhere directory, and each sub-directory had a bunch of files! However we know the properties of the file that has the password we need :
- Human-readable
- 1033 bytes in size
- non-executable
So, utilizing the find command, we can get the file we want. Let's try searching for a file of 1033 bytes in size.
Bingo.
The instructions said that the password was stored somewhere in the server. So, i used the following command to search for the file.
Let's break this command down.
find / : The command we use the find files. The slash indicates to search the root directory and all sub-directories for the file.
-size 33c : To specify the file we want is 33 bytes in size.
-user bandit7 : To specify the file we want is owned by user bandit7
-group bandit6 : To specify that the file is owned by group bandit6
2>/dev/null : This part of the command re-directs all error outputs to a folder /dev/null, basically a trash folder where data is discarded. This is done so we don't get a mountain of error outputs we have to sift through.
Now, let's execute the command.
Nice.
The password for the next level is stored in the file data.txt next to the word millionth. This data.txt has hundreds of lines! We cannot hope to scroll and try to find it, so let's utilize the strings and grep commands.
strings prints out sequences of printable characters in the targeted file, and grep can find us certain sequences according to the pattern we give it.
the '|' in between the two commands is a pipe. Piping allows us to direct outputs of commands into other commands. This means the Sequences of data.txt procured by the strings commands is sent to the grep command, which gives us the sequence with the word "millionth" in it.
The file data.txt in this level has many sequences of characters, any of which could be the password. However, we're told that the password only repeats once! So, lets utilize the sort and uniq commands this time.
sort, sorts the lines of data.txt. We do this because only then will the uniq command work. The uniq -u command returns us only unique lines in a sorted text file.
Now we have a data.txt again. This time, it's a jumble of readable characters and binary data. We're told that the password is in one of the readable strings, preceded by a number of "=". For this we need to use strings and grep again.
The data.txt file is containing the password. However, it's encoded in base64. So, we need to use the Base64 command, with the -d option for decoding.
The password for the next level is stored in the file data.txt, where all lowercase (a-z) and uppercase (A-Z) letters have been rotated by 13 positions. This is also the principle of ROT13, a cypher that shifts each letter of a sequence by 13 characters. This means if we apply ROT13 twice, we get the original sequence, since the alphabet is 26 characters long.
We can use the tr command here to apply ROT13.
The tr command can translate characters. Here, tr [a-z] [n-za-m] shifts each character 13 places to the right. If a character is after n, then it is mapped to the second half of the second argument (a-m).
However, it seems I didn't account for the uppercase characters... Let's fix that.
Alright!
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.
First of all, I might have to make a lot files. So I will create a temporary directory under /tmp to not clutter things up.
Then, I'll copy the data.txt file to this temporary directory.
Now let's start actually working on this file. First of all, we know it's a hex dump. So we have to revert this hexdump, using the xxd command with the -r option, for reverting, and send the output into a separate file.
Now we have this mess... Let's see what it actually is, using the file command.
It's gzip compressed data. Let's use the gzip command to unzip it, by using the -d option for decompressing. But first, we have to rename the file to have a .gz extension, otherwise gzip can't recognize it as a gzip compressed file.
Alright, now what file type is it this time?
It's bzip2, another compression method. For bzip2 compressed data, we need to use bzip -d to decompress it. But once again, we have to rename the file to have a .bz2 extension.
What file type now? It's gzip again!
And what type of file do we have now? Gzip? Bzip2?
Neither! It's a tar archive. Let's use tar -xf to extract the data from it. The -f is used to force the command, the -x to signify extraction.
From this point onwards, it's gzip, bzip2 and tar archives within each other. For brevity's sake I am simply showing you the remaining commands I've used.
This time, there's no data.txt... there's a ssh private key. We can log into remote machines with SSH in two ways ; with a password, or with a key. So what we have to do here is log into bandit14 with the ssh key instead of a password.
But first, we need to get that key onto the computer we are using! And for that, we need the scp command.
scp allows us to transfer files over the internet via ssh.
This is the gist of what this command exactly does:
It connects to port 2220 of bandit13@bandit.labs.overthewire.org, and then searches for a file "sshkey.private" to send to a location in my local machine.
We still require the password we found in the previous level to complete the transfer.
Now that we have the key on our local machine, we can log into bandit14 via key authentication.
The password for the next level can be retrieved by submitting the password of the current level to port 30000 on localhost.
localhost essentially refers to the computer you are using. (It's interchangable with 127.0.0.1)
We can use nc (or NetCat) to connect to port 30000 on localhost. NetCat is a very useful network tool!
But first we need to get the password of the current level. We logged in via key authentication before, but we can still access this level via password.
Got it! Now we input this to port 30000 on localhost.
The password for the next level can be retrieved by submitting the password of the current level to port 30001 on localhost using SSL/TLS encryption.
SSL/TLS are encryption protocols used for securing internet connections between servers.
Here the openssl command can be used to set up a client from which we can start an SSL/TLS encrypted connection.
This level had me very confused, until I opened the manual page for openssl-s_client. Reading man pages are really essential in this course...
This command opens a SSL/TLS encrypted connection. Without specifying the host, it defaults to localhost, so I've only specified the port.
The credentials for the next level can be retrieved by submitting the password of the current level to a port on localhost in the range 31000 to 32000. First, I need to find out which of these ports have a server listening on them. Then, find out which of those speak SSL/TLS and which don’t. There is only 1 server that will give the next credentials, the others will simply send back to you whatever you send to it.
We need NetCat once more! with the -zv options applied, we can get an extensive list of all ports between 31000 to 32000 that have a server listening on them.
That's a lot of ports, obviously. I can't show the full list here, but we got 4 or 5 successful matches! Let's see which ones speak SSL/TLS.
Ports 31960 and 31691 have listening servers on them, but they don't speak SSL/TLS unfortunately. Let's try the next port, 31790.
This output is different. Seems like it's a match!
KEYUPDATE...? The OverTheWire page had something to say about this!
Helpful note: Getting “DONE”, “RENEGOTIATING” or “KEYUPDATE”? Read the “CONNECTED COMMANDS” section in the manpage.
Navigating to the manpage for openssl-s_client, we see that KEYUPDATE is a response to a command 'k' at the start of the line to send a key update message to the server. This was triggered since our password starts with the letter 'k'.
We can tell openssl to ignore such special commands by using the -ign_eof option.
Now we got an RSA key! We can use this to get into Level 17 via key authentication.
There are 2 files in the homedirectory: 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
For this, we'll use the diff command to compare the two files.
Since the password is in passwords.new, x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO is the password for the next level.
When trying to log in with the password we got in the previous level, we're met with this :
???
The password for the next level is stored in a file readme in the homedirectory. Unfortunately, someone has modified .bashrc to log you out when you log in with SSH.
Well, that explains it.
Luckily, we don't need to log into the remote computer to see what the password in the readme file is. SSH allows us to put a command after the SSH entry command, so instead of logging us in, it returns whatever output produced by executing the command we appended.
And that's levels 0-18 of the Bandit course of OverTheWire.org! I learnt alot about networking, and I'm quite interested by this so I've decided to continue with the rest of the course.