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:

• Enumeration
• Exploiting Heartbleed Vulnerability
• Privilege Escalation
• Key Takeaways

---

Enumeration

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 valentine@10.10.10.79 or heartbleed@10.10.10.79, 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 hype@10.10.10.79

Great! I’ve got a connection as a low-privileged user. I’ll go ahead and grab the user.txt file before moving on.

---

Privilege Escalation

At first, I figured I’d check for low-hanging fruit through a kernel exploit. Let’s see what OS I’m running on.
uname -a

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.
cd ~
cat .bash_history

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.

---

Key Takeaways

• 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.