Poison — A Port Forwarding Privesc HackTheBox Walkthrough

Summary
Poison is a Linux host running a web server vulnerable to local file inclusion. This was leveraged to enumerate local users and recover a file containing an encoded credential. These were combined to gain SSH access to the machine. Local enumeration returned a VNC process running as root that only accepted local connections. Port forwarding combined with a key recovered from the host returned a terminal over VNC with root privileges.
Recon
I began recon on this host with a scan to enumerate Service Versions and run Default Scripts on the 1000 common ports that nmap checks by default:
nmap -sV -sC 10.10.10.84
-sV— enumerate service versions-sC— run default scripts
This returned two services, SSH and HTTP. Each were fingerprinted as running on a FreeBSD host.
The first service enumerated was HTTP. Visiting the web server immediately returns a portal to execute php files:

Running listfiles.php returns an array with multiple files from what appears to be the default web directory containing the local .php scripts referenced on the homepage. There is also a file named pwdbackup.txt:

Looking at the URL it is clear to see how the listfiles.php file gets referenced:
http://10.10.10.84/browse.php?file=listfiles.phpIn order to view the contents of pwdbackup.txt, it was simply a matter of replacing the file name in the URL:
http://10.10.10.84/browse.php?file=pwdbackup.txt
While testing this URL, I decided to see if other files on the system could be grabbed:
http://10.10.10.84/browse.php?file=../../../../../etc/passwd
This worked! However it is not readable or easy to parse. This can be easily worked around by viewing the page’s sourcecode:

At this point a list of users and an encoded password have been enumerated form the host. Now it’s time to put these two artifacts together and gain local access to the system.
Local Access
The file pwdbackup.txt contained a hint that the password had been ‘encoded at least 13 times’. It appeared to be base64 encoded. In order to rapidly recover the password and not bother with determining exactly how many times the string was encoded (it was in fact 13 times exactly), I wrote a python script to decode the string until it was plaintext:
To enumerate the users on the system that have valid login shells on the system, I used grep to filter out the /usr/sbin/nologin shell:
grep -v “nologin” passwd
-v— invert match
The users root and charix each have interactive /bin/csh shells. The user toor, the default backup account in FreeBSD, has no shell assigned. The user uucp is another default account in FreeBSD and does not have an interactive shell.
Using the decoded password and the username charix granted SSH access to the machine.
Privilege Escalation
In the charix user’s home directory, there was a file named secrets.zip. Transferring the file to the host and unzipping it with the user’s password returned a file with “Non-ISO extended-ASCII text”:
[|Ֆz!Viewing processes running as root returned an interesting (and very lengthy) process:
ps -U root
-U— specify user
There was an Xvnc session running as root. Researching each of the arguments for this process it was able to be determined that there were authentication keys to connect to this VNC session and it was only listening for local connections.
We can confirm the listening port 5091 is listening for connections by running sockstat:
sockstat -P tcp
-P— specify protocol
VNC is a GUI program. Since there is only SSH access to the machine, VNC sessions can’t be launched from the remote shell; there’s no pop-up window for the VNC session to spawn to. We also can’t connect to the VNC session remotely because it is only listening for local connections.
In order to make this work, we must tunnel our VNC connection through SSH in a process described and explained very effectively in this article and diagram:

Step 1:
Set up the port forwarding to reach the 5901 vnc session:
ssh -L 5902:localhost:5901 charix@10.10.10.84Leave this running throughout Step 2.
Step 2:
Back on my machine, I connect vncviewer to local port 5902, which will bounce the connection through the SSH tunnel and onto Poison at port 5901. Since the traffic went through the SSH tunnel, it appears as a local connection to the VNC process and we are able to authenticate using the file/key extracted from secret.zip:
vncviewer localhost:5902 -passwd secretThis will return a root shell over VNC.

