Passage is a medium-rated Linux machine on the reputable penetration testing platform known as HackTheBox. The ultimate goal is to compromise this machine and gain root privileged access. In the write-up below I explain the steps I took to successfully gain root access to this machine. This one falls in the category of TJNull’s HackTheBox OSCP-like machines. So if you’re planning on taking the OSCP like me, this machine is good practice. The whole list of OSCP-like machines can be found here.
Reconnaissance
Those familiar with the Cyber Kill Chain are aware that reconnaissance is the first step in the process of compromising a system, so let’s start with an Nmap scan. Pictured below are the results of the Nmap scan.
The results show that there are only two ports open:
- Port 22 is running OpenSSH 7.2p2
- Port 80 is running Apache httpd 2.4.18
Let’s start out by enumerating port 80 and check what’s actually running there.
It looks to be some website that publishes news reports. Viewing the source of the page gives us some potential usernames, those include:
- nadav
- paul
We can see that some sort of Fail2Ban has been implemented which means we can’t brute force directories because we’ll get a two minute IP ban. Let’s explore the page a bit more and keep our usernames in mind for later down the road.
On the bottom of the page we can see “Powered by CuteNews”, let’s click on the link to see where it leads us to.
The link on the web page leads us to the website of the CuteNews project. Let’s check if there are any public exploits available for CuteNews.
Well, that’s quite a list.. Let’s try to check if we can find the version of this particular CuteNews implementation. Navigating to http://10.10.10.206/CuteNews we are being presented with a login form and the particular CuteNews version gets disclosed to us.
Now that we know the version of CuteNews we can trim down our searchsploit results to only exploits for version 2.1.2. Doing so we find four potential vulnerabilities that we can exploit.
The “Authenticated Arbitrary File Upload” exploits sounds promising, for that we need to be authenticated so first we create a user. After creating a user we check out the exploit and it basically boils down to the fact that we can upload a malicious file because there isn’t any proper file checking mechanism built-in. So let’s give that a shot! Let’s create a malicious GIF that includes a simple PHP web shell.
So what’s actually going on here? The “GIF8;” represents a file signature, also known as the magic bytes of a file. We use this here to trick file checking mechanisms into thinking it’s a GIF file but in reality it’s a PHP file that can execute code. We can simply check this by issuing the following command:
Now that we have our malicious GIF file, let’s try to upload this to the box. After intercepting the request to change our personal avatar with Burp we can see that our “GIF” file actually gets uploaded as PHP. (Content-Type: application/x-php)
The next step is to find out the path to our uploaded shell, after reading the PoC exploit of CVE-2019–11447 we see the path as /CuteNews/uploads/avatar_<username>_b1tsec.php. Let’s navigate to this path and see what happens.
We have code execution! Pictured above is the result of the “id” command. Now that we have code execution let’s check if we can get a reverse shell on the box. First let’s see if there’s Python on the box.
Now that we know that Python is on the box let’s try to get a reverse shell using Python. We get our reverse shell from PayloadsAllTheThings. We edit the reverse shell to include our own IP address and port, we then set up a listener on our machine to catch the callback.
We get a connect back so we have a shell on the box now, nice! Let’s enumerate further. The first thing I always do is check which users have a shell on the box as well.
Users root, nadav and paul seem to have a shell on the box, this means that the potential usernames from the blog seem to exist. Since we’re dealing with an entry point via a web application let’s enumerate the CuteNews folder. Doing so gives us an interesting directory /var/www/html/CuteNews/cdata/users, in this directory there’s a file called lines which contains base64 encoded data.
The interesting thing here is that we see PHP code that prints “access denied”, which could indicate that we‘re potentially dealing with authentication data of some sort. Let’s decode the base64 encoded data and see what we’re dealing with.
After decoding the base64 string we can see that we’re dealing with a serialized object here. We can see the username nadav and a pass object that includes a hash that is 64 characters long. Let’s check which type of hash we’re dealing with.
Hashid tells us that we’re dealing with a SHA-256 hash. When trying to crack this particular hash with hashcat we didn’t get any results. After decoding some more base64 data from the lines file we also get a hash from the user paul. When we fed this hash into hashcat we got a hit.
Hashcat returns the result “atlanta1”, let’s give this password a try with the user paul.
The cracked password is successful and we’ve switched to the paul user. In the home directory of this user we find the user flag. I immediately noticed that paul has a .ssh directory and he has a private key in there. Sometimes private keys get shared between multiple users, this is very bad practice. Let’s try this private key for the nadav user via ssh.
Guess what? Paul and nadav share the same private key for ssh. We have now successfully pivoted to the nadav user. Let’s continue to root and run linPEAS to make things easier.
After analyzing the output of linPEAS we see that linPEAS spotted a vulnerability. The vulnerability essentially boils down to the following: “A vulnerability in the USBCreator D-Bus interface allows an attacker with access to a user in the sudoer group to bypass the password security policy imposed by the sudo program. The vulnerability allows an attacker to overwrite arbitrary files with arbitrary content, as root — without supplying a password.” A quick check to see if our user nadav is in the sudoers group gives us hope that this might be the way to root.
We find this article that explains how the vulnerability works. SSH seems to be a theme on the box so my thought process is to make a copy of root’s private key and put it in a directory we can read like so:
We don’t get any errors which means our file should have been copied to the /dev/shm directory.
And indeed it has, we confirm that root’s ssh key has been copied to our file in /dev/shm. Now all that’s left to do is log in as root with the private key and get the root flag.
This wraps up Passage, I personally really enjoyed this machine. I hope you learned something new and hope to see you next time.
