Originally Written By: Hunter Gregal
Updated By: Justin Fimlaid

It’s that time again; to practice our penetration testing skills and tactics! NullByte: 1 is another root-the-box type challenge that can be found on http://vulnhub.com. Like other challenges on the site, the goal is to read the flag hidden in the root directory of the server… but you have to exploit your way to root first. For this walkthrough I will be using a KALI 2.0 virtual machine as my attack host. Without further delay, let’s dive in to NullByte: 1!

We can start by powering on the VM and doing a quick Nmap sweep to find the IP address that the box has been assigned. Remember from the previous blog (https://nuharborsecurity.com/Application-Security-Testing-Tutorial-via-Rooting-Hackademics-RTB1) that we will be looking for a machine with a “Vmware” network card manufacturer. Yours may be different, depending on what software you’re using to run the VM. We can also assume that this vulnerable machine will probably be running a webserver on port 80.

nmap -T4 -sV -p80 192.168.100.0/24

There we go! With an IP address it’s time to check out what other services this box may be hosting. Running a more in depth Nmap scan will give us that information.

nmap -T4 -A 192.168.100.131

Aside from RPC and SSH running on port 777, there is not much to go off of here. Let’s see what pages the webserver is handing out by navigating to the IP address in a web browser.

With only a single static page, I’d say the next step is to run some directory brute-forcers and vulnerability scans against the webserver. I decided to do both a Nikto scan and a Dirb scan to see what kind of results I could find.

nikto -host >http://192.168.100.131

dirb http://192.168.100.131

Aside from a few directories and a unique header, there does not appear to be a whole lot going on that catches my attention. Let’s save ourselves the time of manually checking these discovered pages and move on the image on the homepage. After some time it dawned on me that perhaps there was a hint hidden in this image, perhaps in the form of steganography.

We can wget the image from the webserver and, as a rule of thumb, check the exifdata before all else.

wget http://192.168.100.131/main.gif

exiftool main.gif

It seems we have lucked out and discovered what appears to be some sort of cipher hidden in the comment section of the EXIF data.

Now admitably, I spent a fair amount of time playing with this string. I tried using it as an SSH password, brute forcing known ciphers against it to see if it was in fact an encoded value, and even using it as a phpmyadmin password. After many failed attempts, however, I tried a bit of a desperate attempt and used it as a directory name on the webserver. Lo and behold it worked!

http://192.168.100.131/KzMb5nVYJw

It appears to be a page asking for a key where if we inspect the page source we can find a hint that suggest brute-forcing may be the way to go. Now at the point I could write a script to brute force the key, but let’s not re-invent the wheel. In an attempt to broaden my horizons I decided to use a tool on KALI 2.0 called Patator.

patator http_fuzz url=http://192.168.100.131/KzMb5nVYJw/index.php method=POST body='key=FILE0' 0=~/wordlists/rockyou.txt follow=1 accept_cookies=1 -x ignore:fgrep='invalid key'

In almost no time at all we have the proper key “elite”! Inputting the key brings us to the following form:

Recalling that the hint from earlier said “this form isn’t connected to mysql”, I had a nagging feeling that it means that this form might be. Jumping right into sqlmap it’s time to test the hypothesis.

sqlmap -u http://192.168.100.131/kzMb5nVYJw/420search.php?usrtosearch=test --dbs

Bingo 🙂 Noticing the database named seth, let’s enumerate the tables and then the columns.

sqlmap -u http://192.168.100.131/kzMb5nVYJw/420search.php?usrtosearch=test -D seth --tables

sqlmap -u http://192.168.100.131/kzMb5nVYJw/420search.php?usrtosearch=test -D seth -T users --columns

I have a good feeling about this database. Let’s dump the values…

sqlmap -u http://192.168.100.131/kzMb5nVYJw/420search.php?usrtosearch=test -D seth -T users -C id,users,pass --dump

It looks that the pass for ramses is a hashed value at first peek, but I know a base64 string when I see one. Decoding the base64 value gives us the actual hash. (Note I add a “=” to the string so that base64 can properly decode it)

echo "YzZkNmJkN2ViZjgwNmY0M2M3NmFjYzM2ODE3MDNiODE=" | base64 -d

With the actual MD5 hash we can use hashcat and the rockyou.txt wordlist to crack it:

echo "c6d6bd7ebf806f43c76acc3681703b81" > hash

hashcat -m 0 -a 0 hash ~/wordlists/rockyou.txt

Now with the user ramses and the password omega, it’s time to figure out what these credentials are for. Trying to log into SSH with these credentials proves successful. (Remember from earlier that the ssh port is 777)

ssh [email protected] -p 777

We now have a shell on the system and the final step is to escalate to root to read the flag in /root/. We can start by checking the .bash_history for any hints.

cat .bash_history

It appears that a previous user was running a binary called procwatch in /var/www/backup

Let’s check out this procwatch binary…

Notice that the file is owned by root and has the sticky bit permission set. This must be our ticket to gaining root privileges. We can grab this file and debug it with gdb-peda to see how it is working. However after running it I have a feeling it’s using the “ps” command in some way.

Notice the sections highlighted in yellow above; the binary is simply calling “ps” from the system as an argument. Knowing this we should be able to easily exploit this by modifying the $PATH environment variable on the NullByte: 1 box. Let’s rename /bin/sh to ps and point the PATH to it.

cd /var/www/backup

ln -s /bin/sh ps

export PATH=.:$PATH

./procwatch

id

And there we have it, a root shell!

Last but not least, let’s read the flag 🙂

I hope you enjoyed this walkthrough of NullByte: 1, and stay tuned to the NuHarbor Security blog for more!