Valentine HTB Writeup
Hey everyone, I am back with another HTB easy difficulty level box called valentine. This box was definitely one of the good starting point to learn different techniques of Linux privilege escalation. Let’s get started.
As usual, started by scanning TCP and UDP full port and services scanning. By the time I managed to root the box, the UDP scan still did not terminate.
Following are open ports and services available:
Port 22: openSSH 5.9p1
Port 80: apache httpd 2.2.22
Port 443: apache httpd 2.2.22
After that I Checked port 80 and 443 on browser and found below image which gave an idea that this could be heartbleed related machine. Even page source of the pages reveled nothing but ‘image: <center><img src=”omg.jpg”/></center>’
To enumerate directories, I used gobuster. The ‘/index, /omg and /server-status lead’ nowhere. The ‘/encode and /decode’ seem to be scripts that encode and decode strings.
The /dev directory contained the two interesting files.
The hype_key contains a string that is hex encoded.
Converted and saved into the ‘RSA key Hype’ named file.
We’ll try and ssh using our newly found private key. Based on the naming convention of pub/priv keys, “hype” is likely the username.
Since a private key is equivalent to a password, it should only be readable by you. We resolve the error using the following command.
>chmod 400 RSA_hype_key
However, it prompted for a password so decided to dig deeper into other factors. Just to confirm whether the heartbleed is there or not, decided to run a nmap script.
The scan result confirmed that port 443 was running on a version of OpenSSL that is vulnerable to Heartbleed! You can check for a great comic article for more detail about heartbleed. The popular OpenSSL cryptographic software library vulnerability allows anyone on the Internet to read the memory of the systems protected by this vulnerable version of OpenSSL. This can lead to the compromise of secret keys, passwords, information, etc. It also allows attackers to eavesdrop on communications.
Searched for heartbleed exploit online and cloned it.
Run the exploit with a loop number of 10 which revealed that the decode.php file has some text value so took a note of it.
There was a decode folder available on the server so copied the string and decode it which gave highlighted response.
Looks like a password string and since port 22 was open so used it to SSH into hype’s account. That’s how I got a user flag. Definitely a worth box to know about Heartbleed working.
It was a time to escalate a privileges. Today I started with Udemy’s Linux privilege escalation course and learned some new tools so it was a good starting point for trying it. The ‘linenum.sh’ file downloaded into the local system.
The script provided ton of details but an old version of Ubuntu that is probably vulnerable to Dirty COW caught my eye. Dirty COW is a privilege escalation vulnerability which exploits a race condition in the way the Linux kernel’s memory subsystem handles the copy-on-write (COW) breakage of private read-only memory mappings.
To confirm whether the target machine is vulnerable to Dirty COW, downloaded the Linux Exploit Suggester script. In the attack machine, start up a server in the directory where the script resides.
We confirm that it is vulnerable to Dirty COW.
Downloaded the exploit related to the dirty cow vulnerability and copied it into the dirty.c file. The compilation part was also mentioned into the exploit. Chosen the password for the newly created user and switched to new created user using ‘su’ command. These all steps were mentioned in the exploit. And, that’s how I got the root privileges' flag.
Method2: Tmux
After pwning the box, I always watch ippsec’s video for alternative solutions/methods. Not gonna Lie, but I found this method after watching his video. It was actually much easier than the dirty cow method but I missed it.
There was active tmux session that is owned by root found in the running processes list. The tmux is a terminal multiplexer: it enables a number of terminals to be created, accessed, and controlled from a single screen. It’s essentially a shell that is owned by root! So if we can enter this active tmux session, any command we run there is executed with root privileges.
In the target machine, attach to the tmux shell using the following command.
>tmux -S /.devs/dev_sess
Let’s do a root dance. Indeed, this was a good learning Sunday experience. :)
