A Beginners Guide to Vulnhub: part 3

Who should read this and why

This is a guide for anyone who has an interested in penetration testing but no experience with it. To control scope, I’m going to assume that you have some development experience and are familiar (if not comfortable) using a command line interface. But as much as possible I’ll try to tell you exactly what command to enter or button to press as well as what each command and button is doing.

I’m hoping that this will expose more developers to the world of ethical hacking. And even if your journey stops after this tutorial, hopefully you will leave with a better understanding of some of the tools and techniques that hackers might use to attack your projects.

If you haven’t already, you should start with part 1 of this series.

The attack (continued)

When we left off in part 2 we had just used hydra to brut force a password to a website served by our target and were rewarded with this page inviting us to search for usernames:

This one doesn’t warn us that it isn’t connected to an sql database, so we could just assume it’s vulnerable, but let’s make belive we don’t live in a world where our targets don’t send us helpful hints about how to attack there systems. To see if this form is hooked up to an sql database we can try to send it some invalid characters and see what it does.

I’ll start with the ‘ character. Looks like it does fine with that.

Next I’ll go back to the form and send the “ character.

Looks like our form is in fact connected to an sql database and it is at least somewhat vulnerable to attack. It’s also worth noting that the form sends a request to “/kzMb5nVYJw/420search.php” with a parameter usrtosearch. With a little more manual work we can see that setting usrtosearch to ‘a’ gives back at least one result.

Now we can switch back to automated tools. In this case we will want to use sqlmap, which, as you might have guessed, helps map out a target database using common vulnerabilities.

First we want to check what kinds of sql vulnerabilities there are:

sqlmap -u “http://10.10.10.2/kzMb5nVYJw/420search.php?usrtosearch=a"

This just tells sqlmap to look for vunreabilities in a database that is reachable by the url “http://10.10.10.2/kzMb5nVYJw/420search.php?usrtosearch=a" (the rest of the sqlmap commands should be pretty self explanatory so from now on I won’t go over what each part of the command is doing).

And we find out that there are a few different attacks this database is vulnerable to. So let’s see if we can get the databases name.

sqlmap -u “http://10.10.10.2/kzMb5nVYJw/420search.php?usrtosearch=a" — dbs

The — dbs flag tells sql map to try and find the names of the connected databases.

To spare you the anticipation, if we spent time digging through all of these we would eventually find out that the most interesting one is ‘seth’. So let’s skip ahead and get the tables in the seth database.

sqlmap -u “http://10.10.10.2/kzMb5nVYJw/420search.php?usrtosearch=a" -D seth — tables

Looks like there is only one table in this particular database, ‘users’. So let’s find out the columns of this table.

sqlmap -u “http://10.10.10.2/kzMb5nVYJw/420search.php?usrtosearch=a" -D seth -T users — columns

Now let’s take a look at what is in the user and pass columns.

sqlmap -u “http://10.10.10.2/kzMb5nVYJw/420search.php?usrtosearch=a" -D seth -T users -C user,pass — dump

Which gives us a couple usernames and what looks like a hashed password. At this point you could do one of two things.
1) notice that all of the characters in the password are part of the base 64 alphabet, convert the string from base64 to utf-8 (with your own code or a service) then notice that the resultant string, ‘c6d6bd7ebf806f43c76acc3681703b81’ is the right length for an md5 hash, try and look it up in an md5 decoding service and find out that it decodes to ‘omega’

OR

2) just google ‘YzZkNmJkN2ViZjgwNmY0M2M3NmFjYzM2ODE3MDNiODE’ and notice that the second result is a page from http://md5decoder.org/ identifying the string as the base64 version of an md5 hash of the word ‘omega’.

Either way, we now have a username, ‘ramses’, and a password, ‘omega’. After doing a little trial and error looking for the lock that fits this key you will eventually want to try it out on the ssh port we found in the very beginning (you are are unfamiliar with ssh, you can read about it here). That would look like this:

ssh ramses@10.10.10.2 -p 777

Which is an attempt to log into 10.10.10.2 as the user ‘ramses’ using ssh protocol on port 777. We will then be prompted for a password and will enter ‘omega’.

Which allows us to log into the target server as ramses. If we move up a few directories we will see a root folder, which is where we’ll find a private key (our end goal). But if we try to access it we find that ramses doesn’t have permission.

So after some more digging around we might see what this use has been upto recently. We can do that by logging out the contents of their .bash_history file. From the base directory, that command would be:

cat home/ramses/.bash_history

Here we see that ramses recently went to the directory var/www/backup and then ran a program named procwatch. To run that from the base directory we enter:

/var/www/procwatch

If you are unfamiliar with the linux ‘ps’ command, this is a list of currently running processes. For comparison, here is an example of just running ‘ps’:

For this next part we’ll want to change directories to the folder that procwatch is in. from the base directory that would be:

cd /var/www/backup

Then we’ll pull a neat little trick that I saw in one of the walkthroughs. It’s evident that the procwatch file calls the ps command, so we can try to create a symbolic link between the ps command in the folder we are in, and some other command. If it works, this would allow us to get the procwatch file to execute some command that we might not have access to ourselves. To test this out we can try to get the ps command to perform the function of the ls command instead.

ln -s /bin/ls ps

Then to make sure that procwatch will find the new version of the ps command you just created (which is really just a link to the ls command) you can add the current directory to the PATH environment variable:

export PATH=`pwd`:${PATH}

Since we are now in the same directory as the procwatch program, we run it with the command:

./procwatch

Which shows that the procwatch file is now running ls instead of ps, so our strategy works. Now we can create a symbolic link between ps and a more useful command. The linux sh command creates a shell where you can execute commands. If we ran it as ramses we would only be able to execute commands that ramses is permitted to run. But if procwatch runs the sh command for us then we should have whatever privileges procwatch has. So we create a new symbolic link by first deleting the old one:

rm ps

And then creating a new link to the sh command:

ln -s /bin/sh ps

Now when we run procwatch:

./procwatch

We get a shell, and if we check our user privileges by running the linux command ‘whoami’ we find out that we are now executing commands as the root user.

Now we can change directories back up to the base directory and then enter the previously forbidden root folder. In it we will find a single file, ‘proof.txt’.

If we log out the contents of proof.txt we find a code to prove we made it along with a short congratulatory note from the creator of the vulnerable machine.

A few of the walkthroughs show the code and message, but I think it’s more fun to read it off your own screen first.

Let me know if you spot any typos, misinformation, or parts that seem confusing. I’ll try and post some more of these geared towards beginners. Like I said at the start, even if you don’t want to become a pen tester it’s good to have some understanding of how vulnerabilities can be exploited. Hope this was clear, informative, and fun!