HTB: Valentine Writeup w/o Metasploit

cyber shinobii
6 min readFeb 4, 2022

Introduction

Today we are working with Valentine. This machine introduced us to a well-known exploit named heartbleed. It abuses a vulnerability in SSL 1.0.1 and allows attackers to read sensitive information from memory due to poor inputs validation. Here is a video walkthrough we did together for Cyber Thursday.

Recon

We kick things off by starting our nmap scans. Please note I have a script that’s doing a variety of nmap scans against our targets. This includes version, vulnerability, full, fast scans, etc.

nmap -Pn -n -sV -A -T4 10.10.10.79 — open -oN nmap-version-10.10.10.79

Our version scan shows 3 ports are open, that is port 22, 80, and 443. Port 22 is used for remote logins, 80 and 443 are typically used to host web services. If we check out the web service via web browser, we see the image below.

http://10.10.10.79

Enumeration

The heart is supposed to be the logo for heartbleed. There isn’t anything interesting with this web page. During our video walkthrough we checked http://10.10.10.79 and https://10.10.10.79. Neither revealed any useful information. While we were investigating the web service over port 443 (https://10.10.10.79) we did check the certificate to see if there was any useful information, and there was none.

At this point, the web ports are leading us to a dead end so far. Let’s go back and analyze the results from our rasengan scan. Remember the rasengan is a bunch of different scans including nmap scans and some gobuster scanning. Our nmap vulnerability scan showed us that Valentine is vulnerable to the SSL Heartbleed Exploit because it’s using vulnerable versions of OpenSSL.

nmap -Pn -n — script vuln 10.10.10.79 -oN vuln-scan-10.10.10.79

In addition to the vulnerability scan, our gobuster scan showed us a few more available directories we can access.

gobuster dir -u 10.10.10.79 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -k -x txt,php,html,asp,aspx

Before we try to find a heartbleed exploit, lets enumerate the website some more by assessing these other directories gobuster found. The most useful one is the “/dev” directory.

http://10.10.10.79/dev/

There is what appears to be a private key and some notes. FYI: its common to see organization use this naming convention with private keys. For instance, “username” followed by “key.” So, in this case the user is “hype” and this could be their private key.

http://10.10.10.79/dev/hype_key

If we click on the key, we see a bunch of hex characters and if we decode it using any online hex to ascii decoder, we learn it’s a private key.

https://www.rapidtables.com/convert/number/hex-to-ascii.html

Make sure to save the private key into a file. We saved it in a file named hype_key. If you try to use, ssh may complain about the permissions. Change the permissions to 600 using “chmod 600 hype_key.” This makes the key writable and readable by owner of the file and no one else. If you still try to use it, it will ask for a passphrase, which we don’t have.

ssh -i hype_key hype@10.10.10.79

We don’t have the passphrase and didn’t find it within the notes or any other page returned from gobuster. So, what next? Well, we do know the system is vulnerable to heartbleed. Maybe we can use that vulnerability to find sensitive information such as the passphrase. Heartbleed allows us to return information from a web service that is supposed to be confidential. It’s possible because the vulnerable versions of SSL are not properly validating user requests.

There’s a bunch of heartbleed exploits out there, the one I used is here. Git clone this down to your local machine and use this string (python2 attack.py 10.10.10.79 -n 20) to launch the exploit. The “-n” tells the exploit how many times to it should try to retrieve sensitive information, it’s a loop. You have to be in the same directory as the attack.py script for it to work; unless you’re using the full path of the attack.py script.

FYI, the script is written in python2 not python3. I’m using python2 to launch the attack. You can convert it to python3 by fixing the print statements. I think there are online converters out there to help with this if you use python3.

python2 attack.py 10.10.10.79 -n 20

The script returns a bunch of information. One thing in particular is a parameter named “text.” It has a value (aGVhcnRibGVlZGJlbGlldmV0aGVoeXBlCg) that appears to be encoded with base64.

echo -n aGVhcnRibGVlZGJlbGlldmV0aGVoeXBlCg | base64 -d

And it is encoded with base64. After decoding it we get “heartbleedbelievethehype.” Using this as the passphrase for the hype_key, logs us in to the system as hype.

ssh -i hype_key hype@10.10.10.79

Privilege Escalation

Now we’re in. Time to escalate our privileges since hype doesn’t have root access. We escalated our privileges using two methods. One was via tmux session we saw started as root. Another was with the dirty cow exploit. I won’t get into the dirty cow exploit here. If you’d like to see how we did that, please check out the video walkthrough. There are time stamps in the description to fast forward to that part of the video.

Escalating our privileges with tmux was pretty straightforward. If you use “ps aux | grep root” you’ll get a list of all the running processes under the root user One of them is a tmux session (first in the picture below).

ps aux | grep root

The root account started a tmux session named “dev_sess.” If you look at its permission, it has a setuid bit. This bit allows us to launch a file with the permission of the user (owner) that created it. In this case, its owned by root.

All we need to do is attach to the tmux session and we’ll be root. To do that we’ll use the following string “/usr/bin/tmux -S /.devs/dev_sess.” The “-S” is used to tell tmux which socket we want to use.

/usr/bin/tmux -S /.devs/dev_sess

Conclusion

And that’s the box. This wasn’t a difficult machine. It’s very beginner friendly and at the same time, it allows you to work with well-known exploits such as heartbleed and dirty cow. Understanding how both of these work with help you a lot throughout your hacking journey. Unfortunately, there are plenty of systems that are still vulnerable to both of these exploits.

AAR

To prevent our attack methods, we recommend the following:

  • Remove the private key from the web directory or require authentication to access that “dev” directory. This would prevent us from getting hype’s key for user level access.
  • Upgrade to a secure version of TLS or SSL. This would prevent the heartbleed exploit from being successful.
  • Change the SSH credentials to Hype’s account. The password was not complex enough.
  • Upgrade our OS and Kernel to something more secure to mitigate the dirty cow exploit.

Hopefully, you enjoyed this writeup. If you did, a clap or comment would be greatly appreciated. Also, don’t forget about the video walkthrough here. I know seeing things is another effective way of learning. Thank you!

--

--