Hackthebox: Poison – Walkthrough

Initial Enumeration

Whilst more extensive scans are run, let’s look at what we’ve got so far

22/TCP

standard openssh with no known vulnerabilities. Not much use to us so far, without even a username to brute force

80/HTTP

A script testing app. If that doesn’t shout LFI, I don’t know what does.

Testing it on the phpinfo.php file executes it at shows a lot of info that might be useful:

But let’s check for the obvious LFI:

In phpinfo we see this script is in this location:  /usr/local/www/apache24/data/browse.php. Just for fun let’s see what code the php file contains using the filter wrapper trick:

By using the base64-encode we base64 output instead of the raw, executable PHP and decoding it offers up the most fundamental file inclusion example possible.

Also from the phpinfo file we see that allow_url_include is not turned on, so a simple RFI is not possible.

Neither dirb, dirbuster or nikto find anything particularly interesting despite using several lists so I went back to the site to take a closer look and (not for the first time) turned out I’d browsed over something important. The listfiles.php script reveals an additional file I’d not noticed – pwdbackup.txt

Getting this file shows some base64 encoding, pointlessly and unrealistically, done 13 times. I really should write a script to automate these things as CTF writers seems to be obsessed with base64 tricks but that would only encourage them:

anyway, after decoding it you get: Charix!2#4%6&8(0

We already have a username Charix with login abilities so let’s see if we can ssh in directly with these creds:

And look, there’s some suspicious looking files in there too:

I’ll check those out in a minute but first I’ll run a privesc checker to get some more info.

The machine has python’s SimpleHTTPServer module available to serve up files so it’s trivial to get the files.

So I have the files. Looking at the dates i think it’s only user.txt (the HTB user token) and secret.zip I’m supposed to be seeing, with the other files being created by other users on the HackTheBox network. The secret.zip needs a password but that’s not a problem as the Charix login password reused:

So I have a password that looks very strange.

Privilege Escalation

Looking through the LinEnum output it’s apparent that xVNC service is running as root. Services running as root are a common privesc target. Usually you’re looking for services installed by the admin user (as opposed to standard services designed to be run as root) and which have the capability run commands or otherwise interact with the OS. This can be tricky but VNC is a remote desktop application which of course is designed to run commands and just about anything else. So if we can access that we should be able to get root. If the secret is the password for VNC that is.

Taking a closer look at the xVNC service:

(sockstat is FreeBSD’s version of netstat – I had to look it up)

What we’re interested in is the services owned by root. ps is telling us PID 529 is the one we want and googling around for that output, apparently the :1 -desktop means it’s referring to which desktop it’s running (if you had multiple remote desktop connections, each has a unique number). Sockstat for that process tells us that it’s running on port 5901. However, it’s listening on the loopback (local to the server) address only.

Just to cross-check that here’s an nmap scan from my kali box of a port range covering the VNC:

Notice how the EXTERNAL VNC port is 5902 So we only have external access to the Xvnc ports owned by charix. That’s no use at all since we already have Charix access. So we’re going to need a way to get access to 5901 from outside.

I happen to have done this exact things before. fairly recently. I run a Linux server for my company and, for security reasons, I’ve hidden vnc from the public and I use ssh to to access it via an ssh tunnel. The way this works is that you use your existing ssh capabilities to forward a local port on your own box to a local port on the server. You then connect your vnc client to the local port on your own box, SSH then routes that to the server’s local port. When i set up my own VNC I used this guide to do it: https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-on-ubuntu-16-04 note “Step 3” which gives you the ssh command for setting up the local port forwarding, used here:

This command tells SSH to create a tunnel from our local IP (not specified as it’s assumed) on port 5901 to port 5901 at the other end of the tunnel on ip address 127.0.0.1 (the server’s own local loopback address). Anything we send to port 5901 on our local machine will end up  on port 5901 on the remote machine. See here for explanation of port forwarding.

We have that weird password and some searching reveals that VNC passwords are encrypted and there are some decrypters around but also that you can just pass the encrypted password to the command as an argument, see the man page:

Trying it out:

Box. Rooted.

What did I learn from this one?

1. Read the outputs more carefully. I messed the password text file for a whole day by simply not reading the list of files.
2. Check for services running on internal ports that aren’t on external ports. I didn’t initially do this carefully enough and as they were quite similar numbers it passed my by for longer than it should have.