In honors of Valentines day, I figured it only made sense to give this box a try and was shocked at how easy it ended up being.
Table of Contents:
- Exploiting Heartbleed Vulnerability
- Privilege Escalation
- Key Takeaways
As always, I started with an nmap scan to see what ports are open.
nmap -T4 -sV -sC 10.10.10.79
Reviewing the results, I see that we’re dealing with a webserver that also has port 22 open for SSH. My immediate thought is I’ll be able to find credentials through a web exploit, which I can use the log into the box via SSH.
To start, let’s go take a look at the webpage on port 80 and 443.
I quickly see the infamous Heartbleed logo on both webserver ports. Add in the fact that this box is named Valentine, I start to wonder if Heartbleed is the intended path.
To see if the machine is vulnerable to Heartbleed, I decide to run a quick nmap script against the box.
nmap -sV --script=/usr/share/nmap/scripts/ssl-heartbleed.nse 10.10.10.79
According to the results, I’m able to confirm the machine should be vulnerable to Heartbleed.
Exploiting Heartbleed Vulnerability
At this point, I start looking for public exploits for Heartbleed and come across the following python script at https://stackabuse.com/how-to-exploit-the-heartbleed-bug/
I take a copy of this code and save it as exploit.py on my machine. After reviewing the code, I see that the syntax only requires the IP address of our target.
sudo python exploit.py 10.10.10.79
There is a lot of output that gets returned, which tells us that we successfully exploited Heartbleed. Taking a closer look at the output shows a text value (that appears to be Base64) for a form located at https://127.0.0.1/decode.php (see above screenshot for the highlighted text value).
Note: You may need to run the exploit multiple times before you find the text string I’m mentioning.
I decide to head over to the decode.php page and see if I can decode this string.
Interesting! So we’ve got a value that appears to be some sort of credential. At this point, I attempted to SSH into the box as root using heartbleedbelievethehype as the password, but it didn’t work.
Seeming to be at a dead-end, I decide to run
dirbuster against the box. After some time, I uncovered a page at /dev/hype_key that appeared to contain a hidden message in hex format.
I copy this hex code, look up a quick online decoder, and dump the text in. Looks like we found an RSA key for an SSH connection!
I take the decoded RSA key and store that into a file named rsa.key. I then attempt to connect to the box using the key and uncovered passphrase, but am still unable to get in. It seems I need to uncover a username still as this key isn’t working for the root user.
After trying a few basic usernames, such as firstname.lastname@example.org or email@example.com, I finally realize that the username is in the name of the encoded RSA key. If you recall, the name of this file was hype_key.
Finally with this additional insight, I attempt to connect to the box using this RSA key, passphrase, and username.
sudo ssh -i rsa.key firstname.lastname@example.org
Great! I’ve got a connection as a low-privileged user. I’ll go ahead and grab the user.txt file before moving on.
At first, I figured I’d check for low-hanging fruit through a kernel exploit. Let’s see what OS I’m running on.
Sweet, x86 Ubuntu 3.2.0-23. Wonder if there are any known privesc exploits?
searchsploit ubuntu 3.2
Look like there are a couple! I attempted to use two of these, but was unable to make it work. Either ran into a compilation error, or a problem executing the payload. Either way, figured there must be another way to gain root-access and decided to dig deeper.
If I can’t make an easy kernel exploit work, perhaps I can still find a lazy path to root? Let’s see what commands were previously ran on this box as root.
Interesting.. Looks like the admin was using tmux for something. Let’s try a couple of these commands and see what happens.
tmux -S /.devs/dev_sess
Wow, looks like that got us root! Let’s grab our flag and consider this one a wrap.
- Staying up to date with major vulnerabilities will make your life easier when it comes to identifying critical holes.
- Not all attack vectors relay on remote code execution or buffer overflows.
- Always look for low hanging fruit, whether that’s something as simply as looking at command history or even kernel exploits.