NullByte - Vulnhub

This is a walkthrough of the machine called NullByte on Vulnhub. It uses a few interesting concepts, but was fairly quick to exploit once I understood what had to be done.

Link to the machine: https://www.vulnhub.com/entry/nullbyte-1,126/

I set the machine up on my VirtualBox, with a bridged network connection. First, I found the machine’s IP using netdiscover:

I got the IP as 192.168.1.142. Next, I did a full port scan using nmap.

I got four open ports. To enumerate the services running on these ports further, I performed a more detailed nmap scan on these ports alone.

HTTP port 80 is open, and SSH is up and running on port 777. At this point, these were the most important ports to me, so I proceeded to check the website on port 80 out.

It’s a simple website, with just an image and a quote. I could not find anything else manually, so I did a directory enumeration using dirb, which revealed some pages like a phpmyadmin page, but nothing turned out to be particularly useful to me. I even googled the quote and found the author, but nothing stood out as a clue to me.

Finally, I decided to try and see if I could get anything out of the only thing that was remaining – the image. And sure enough, when I checked the image using exiftool to check out the metadata, I found an unusual string.

The string in the comment “kzMb5nVYJw” turned out to be a directory name.

The page asked for a key, which I did not have at this point. I checked all the sources I found so far again, and also tried SQL injection, but no luck. Finally, I decided to try and brute force the key using Hydra.

In order to do that, first I inspected the element using my browser’s “Inspect Element” feature, to find the protocol used, and the name of the field to brute force.

Using this information, I built my hydra command. In the end, it looked like this: hydra 192.168.1.142 http-form-post "/kzMb5nVYJw/index.php:key=^PASS^:invalid key" -P /usr/share/wordlists/dirb/big.txt -la

http-form-post indicates that it’s a post request, followed by the directory path of the form field. key symbolizes the name of the field, and the ^PASS^ placeholder shows that it’s a password we need to brute force. Hydra will insert the values from our wordlist in place of ^PASS^. invalid key is a text indicator which appears on the page when a wrong password is entered, so that Hydra can identify incorrect entries. I specified my wordlist using -P, and -la is to choose the username as ‘a’ so that Hydra won’t show an error that the username argument is missing. Since we do not have a username field, it won’t matter whatever value we provide.

I got the password as “elite”. When I entered the key, I got another page which asks for a username.

I did not have any usernames either so far. I accidentally hit enter without typing anything, and it gave me two usernames in return. Good page.

Remembering the SSH service on port 777, I tried to brute force the password of any of the users. I tried ramses first. The wordlist I used is just rockyou.txt which can be found at /usr/share/wordlists/rockyou.txt by default on Kali machines. I just renamed it to pass.txt when I copied it to my desktop.

I got the password as “omega”, and signed in as ramses via SSH.

I did some enumeration, but did not find much. I did not have permissions to run sudo -l either. So, I checked for binaries which have the SUID bit enabled. When a binary has the SUID bit enabled, it will always execute as the owner of the binary, no matter who enters the command.

procwatch is an interesting find here, since it isn’t generally present in common computers. I decided to go check it out, and sure enough, the owner of the binary is the root user.

I executed procwatch to see what it would do, and I found that it executes sh and ps.

We can escalate to root user using the PATH environment variable in this case. First, I added the current directory to the beginning of the PATH variable.

Then, I created my own version of the ps binary in the current directory, with contents /bin/sh. Using that, I was able to get a shell with root privileges when I ran procwatch again.

This works because procwatch runs my version of ps instead of the one it was originally executing. Binaries check for the files they execute in the order of directories listed in the PATH environment variable. Since I added my current directory to the beginning of PATH, it found and ran my version of ps first, and I got root.

Now, I just had to read the root flag.

And that was it! I hope this writeup was informative. Happy hacking!