Permissions: hexdump, zip files, and password-less login.
Welcome back to my 7th iteration of this blog series. In this series we’re growing our cybersecurity knowledge starting from the very basics using the overthewire.org challenges as a guide. First, I’d like to thank everyone for their feedback based on the last post! I’ll do my best to implement it and as always, more feedback is always welcome. Now let’s start!
We’re still working with the “data.txt” file but things are about to get interesting. We talked about security through obscurity previously and how it is not particulary a secure solution but it can help slow down attacks. In this case, we have a data.txt file that is a hexdump. Hexidecimal is a form of machine code that is printable and in many ways more human readable than binary. Converting and saving sensitive files is another way of obscuring its contents especially since hexdumps are reversible.
So let’s take a look at our first hexdump:
Hexdumps are very neat: we have consecutive numbers in a column on the left, a few columns of number-letter combinations in sets of 4, and then column of what looks like gibberish. We won’t go crazy trying to decipher this ourselves, we don’t have to, but we’ll just cover the basics of what each mean. The first column is the address column. It’s the relative address in memory for each of the “lines” of data that follow it. If this was a running process, we’d see the actual memory addresses. The numbering scheme of the lines already gives us some insight into how hexidecimal works. The line following the address is the actual data of that line. It’s broken into sets of 4 to make it more human readable. The last column of “gibberish” is the actual data that corresponds to the hexidecimal representation.
That’s enough of hexadecimals for now, so how do we move forward? Well, we know this is a hexdump from the hint given and also because of the structure of the file. We can also check what the data type in the file by using file:
file thinks that it’s just ASCII text, which it is because it’s meant to be that way: hexdumps are meant to be information to humans. So let’s get the real file back by reversing the hexdump. The command the creates and reverses hexidecimals is xxd:
It’s gibberish but it’s the gibberish we want. If we compare this output to the right most column of the hexdump, we’ll see that it’s the same data. Unfortunately, the reversing is done in stdout only and no new file is created. Trying to make a new file is not allowed because of the permissions on this directory but we have permissions to work with “/tmp”, so let’s do that and we’ll call our folder “samelsaid”. Then we should copy this file to work with there:
Using “;” is a way to chain commands together. We’ve done this before with >, <, and | but all those are dependent on the previous command. The “;” links commands together independently and they run one after the other regardless of the previous command. Now let’s save the reverse hex in a new file and check what data type this file is:
Having see the “data2.bin” name in the original hexdump, I chose to name this file data2.bin but that’s not necessary at all. In fact, we’re going to have to rename it for the next step to work. But let’s take at the information provided by file first: it is “gzip compressed data”. Cool, so we know what to do next. Let’s decompress it (take a look at man gzip):
gzip doesn’t know what to do with a “.bin” file so we have to rename it then try again (in the man page, we see that the files compressed by gzip are extension “.gz”):
It worked! Now let’s try reading data2:
Ok, so this is a case of multiple compressions (which the hint mentioned but it doesn’t hurt to check). Let’s see what type of file this is and decompress it accordingly:
Checking man bzip2, we see it uses the same syntax as gzip and the extension is “.bz2”. Rinse and repeat:
Let’s address the “was ‘data4.bin’” information from file. This is simply what the original name of the file that was compressed. Well, it’s another gzip file so we’ll keep going until file tells us something we haven’t covered:
tar is another type of zip file. The man tar indicates we should use -xf to decompress it. But first we have to rename it as always:
Finally, “data8” is an ASCII text file, let’s see what it holds:
Took enough steps but we finally got it. This is a practical example for how obsucring a file like this can slow down an attacker. This is also somewhat simple to create a script to take care of checking and decompressing so again, “security through obscurity” is only really good against novice and inexperienced attackers.
For this next part, we’re told it’s impossible to get the password directly. But we’re given the private key to login to bandit14. Then bandit14 can read their own password. Using the private key is simple enough (take a look at man ssh) but we should just use “localhost” as opposed writing out the whole address:
Ignore the warnings about not being able to create and edit directories, that’s part of the security of the levels so as not to change things for the next user. But now that we’re successfully logged in as bandit14, we can go ahead an read the password:
In this last challenge we used “localhost” as an address for ssh. We need to discuss the internet a little. The inter-net is simple a massive network of connected computers. The computers talk to each other to find the information they’re looking for and respond accordingly.
When we only have two computers connected together, it’s simple enough to ask the “other one” for I don’t have. This gets more complicated as the network grows and thus we have addresses. Addressing has multiple layers which represented by the TCP/IP stack. In this case we’ll just discuss the 3rd IP layer and well cover the rest later as it becomes directly relevant.
Going back to our example of finding information, computer A asks the network for some info. Computer B responds to say that it had the information. Since the internet is a massive network of interconnected computers, a standard addressing system called the Internet Protocol or IP was created. The IP address is a unique identifier for a computer on the network but is also reassignable. It’s consistently written on 4 sets of 3 numbers such as “192.168.1.55”. Even if only one number is used, like the “1” in our example, it’s still read as 001.
IP addressing allows computers to find each other from all over the world across and within networks. Some IP addresses had to be reserved as the number of devices started to balloon beyond the capability of the IP range. One such IP is 127.0.0.1. This is called the “loop back” address or “localhost” and it refers to the same computer sending out the request. It’s essentially the computer talking back to itself when it sends something addressed to localhost.
This is a very brief and simplistic explanation of the Internet Protocol and I suggest finding sources that will explain that it in more depth. I’ll be creating another series to explain these principles but until then: google.
