Hack the Box Writeup - Poison

Today's writeup details the steps taken to own retired Hack the Box machine, Poison. There's some interesting techniques in this one, so hopefully it will make for an interesting read.

Hack the Box Writeup - Poison

Today's writeup details the steps taken to own retired Hack the Box machine, Poison. There's some interesting techniques in this one, so hopefully it will make for an interesting read.

Enumeration

Let's begin with our nmap scan.

$ nmap -sC -sV -p- -oA nmap/scan 10.10.10.84

nmap

Only 2 services available, ssh and http.

Browsing to the website shows us something unusual, a page describing itself as somewhere to test local PHP scripts!

http

The page lists a few PHP files to be tested, one of which looks interesting, listfiles.php.

Putting that in the textfield takes us to a page which seems to output a PHP array containing all the files in a specific directory. All of them bar one are already listed on the webpage, but the one missing is called pwdbackup.txt, so let's take a look at that.

pwdbackup

Interesting. Looking at the string it is fairly obvious that the "encryption" is base64 done 13 times. So that's easy enough for us to reverse.

Exploit

Let's start up a python repl, and put in the following:

import base64
passwd = "<base64 string>"
for _ in range(13):
    passwd = base64.b64decode(passwd)

passwd

python

We have a password! What we don't have is the username to go with it.

So let's go back to our website and see what else it will let us take a peek at.

Entering /etc/passwd into the text field shows us that the page doesn't do any checking as it happily shows us the password file.

lfi

So we have Local File Inclusion (LFI). Trying to get the user flag using this method fails however as the user the website is running under does not have the correct permissions. But from this password file we do now have a user account, and looking back at our nmap scan we can see that ssh is running on the server so let's give these credentials a test.

$ ssh [email protected]
Password for charix@Poison:

ssh

They worked! So we have access to the first flag.

Further Enumeration

As well as the user flag, the home directory also contains an interesting zip file called secret.zip. We can't resist a good secret so lets unzip it and take a look.

password-zipfile

Well that sucks. And it seems the version of unzip on this FreeBSD box does not have the -P parameter to enable us to pass in a password. So let's copy it back to our Kali machine and have a go.

$ scp [email protected]:/home/charix/secret.zip .
Password for charix@Poison:
secret.zip                                    100%  166     6.3KB/s   00:00

Now we can pass in a password, and using the credentials we already have seems to work, and the file extracts.

extracted-secret

It's a rather strange file though, and yields us no further clues as to what we should do with it ¯\(ツ)/¯.

So let's go back to the box and do some more enumeration.

Yet More Enumeration

As we got distracted by the tempting secret.zip in the home directory, lets get back to having a proper look at what is running on this box.

Eventually I took a look at what network connections were running, and one jumped out at me.

NOTE: FreeBSD's version of netstat is bit different, so if you want the equivalent of netstat -antp, use sockstat -4l instead.

network-services

Comparing this to our initial nmap scan shows some differences. It seems that this box is running a VNC service as root on the loopback address, so not accessible externally. So let's fix that by that doing some ssh tunneling.

First make sure we have an ssh server running on our Kali machine (and that your password is very strong), then on the Poison box run the following:

$ ssh [email protected] -nNT -R 5901:localhost:5901

NOTE: The -nNT flag tells SSH not to set up a TTY terminal on our Kali machine.

Now, in a new terminal on our Kali box we can try the following:

$ vncviewer 127.0.0.1:5901

vnc-fail

Unfortunately the password we already have for the charix user does not seem to be the password we need here. Perhaps the secret file from earlier has something to do with it?

Looking at the options for vncviewer we can see a flag -passwd which accepts a filename!

$ vncviewer -passwd secret 127.0.0.1:5901

vncviewer-1

And there we have it, a root remote desktop and access to the final flag :)