Hack the Box - Poison
This was a fantastic machine that started off with a very straight forward attack vector of an ssh and http port. The website appeared to of been accidentally posted with sensative information on the external server. This allowed for local file inclusion attack that leveraged such sensitive info in order to gain a users credentials that we use to connect in. From we learn VNC is running locally and are able to exploit it with some research and creative thinking.
Priv esc enumeration
LFI to RFI
└─$ nmap -sC -sV 10.129.1.254 130 ⨯ Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-14 19:11 EDT Nmap scan report for 10.129.1.254 Host is up (0.15s latency). Not shown: 998 closed ports 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
I always like to get dirbuster started in the background and in this instance it provided me with no results which was fine because everything I needed was on the landing page in the below image. Here we have a search box and several suggested php files. It appears if a dev team was testing a new platform and have not applied any access control or restrictions to this web application. We start off with simple enumeration to learn what the scriptname: box returns upon entry of arbitrary characters.
The response to a query of arbitrary characters is a back end call to a "file =" query.,
Querying one of the suggested scripts yields sensitive backend information that allows us to move to the next stage of the engagement. By going through all the files one by one I eventually reviewed the "listfiles.php" which had and index of options.
Eventually selecting the "pwdbackup.txt" provided us an encoded string of characters with an author statement "This password is secure, it's encoded atleast 13times....could go wrong"
At this stage I was able to identify the encoded text as base64 just from experience. But it initially would not work and this lead me to consider all sorts of possibilities until I realized I was perhaps overthinking things. From here I decoded the message by running a base64 decoder 13 times.....
Gaining user access
With the above credentials It seemed clear to try charix:!2#4%6&8(0. But this format did not work, so I proceeded back to the initial query button and checked for local file inclusion with ../../../../../../etc/passwd and this provided me the users list. Remember to always validate user input! I realized that perhaps the user Charix has simply used their name in the password. Trying the combination charix:Charix!2#4%6&8(0 granted me ssh access.
A different attempt at user flag
From experience I know that LFI can escalate to RFI, so we will have a look over if it is possible here. I read the following in the cited reference which is provided multiple times throughout this document.
During assessments it is still common to find LFI vulnerabilities when testing PHP applications. Depending on the server configuration it is often possible to convert these into code execution primitives through known techniques such as;
/var/lib/php/session/ (PHP Sessions)
/tmp/ (PHP Sessions)
For these wrappers we will have to check the server response status and we can literlally biew the output on the page or utilize burp suite to burp our reqiets.
PHP filter Wrapper
When .php files are executed we don't see the source code. The folter wrapper allows us to encode the output in base64 and into a single string.
PHP Expect Wrapper
This wrapper expects you to run system commands
PHP HTTP Wrapper
This wrapper lets you access URLs.
Spin up a server with what ever you want to transfer.
PHP Input Wrapper
This wrapper lets you read the daw data extracted within request bodies. This allows you to modify and send a payload via post request.
<?php echo shell_exec($GET['cmd']); ?>
I used burpsuite to read the servers repsponse regarding the wrapper configurations. But I never got anywhere.
From here I noticed the secret file in the landing folder. I was unable to unzip this folder and put it on the back burner for a moment while I followed the enumeration process and uploaded linpeas.
I had some trouble with uploading files initially. I attempted Netcat, Wget and Curl without success. I then reviewed OSCP material and recalled the use of SFTP for a "Free BSD" system.
Priv esc enumeration
After uploading and running linpeas I took some notes
I always check the OS version and in this case there were no known CVE's.
Binary processes permissions
Nothing stood out to me here.
No cron jobs were found sadly
Now we are talking! We have two internal ports. But wait, they are internal only!
I attempted to take advantage of the GDB program with a sudo token, but free bsd does not recognize the sudo command or export command for declaring varibles. I used GTFO bins as usual to help with this token with no success.
Not sure what to make of this!
I couldn't cat the file in this case.
Checking the processes shows us xvnc.
ps -auxww | grep vnc
Viewing more detailed info by appending the ps aux command with ww and greping for vnc.
port - 5901
Looking up xvnc shows us it is a known linux application related to bnc viewer.
Second Method to gain user access
Another method to gain access here is to turn LFI into RFI. Here is a great reference
There essentially have to be two conditions present.
An existing LFi Vulnerability
Access to a call a script that reads PHPinfo()
Simply downloading the script and adding a php-reverse-shell.php to the payload is all we need to do. The LFIREQ needs to be changed to the entry point of the LFI vuln in the webapp.
I could not get this working, there was some other troubleshooting that had to be performed with the script.
VNC access on the path to root
So this next part is what makes this HTB machine a medium rated box due to the ssh tunnel we will have to create inorder to attempt a connection with the xvnc on the local host over port 5901.
I was looking for a guide on how to use VNC on linux then I thought to quickly try "vncviewer" which sure enough popped the native application and gave me a connection prompt for a server.
We will need a way to connect and unfortunately we will not be able to pop a graphical UI on a compromised machine with a simple ssh connection.
First we setup a port forward as the foundation for the SSH tunnel.
ssh -L [local-port]:[remote-ip]:[remote-port]
ssh -L 9999:127.0.0.1:5901 firstname.lastname@example.org
We can confirm our ssh tunnel worked here by running netstat .-an. We see 127.0.0.1.9999
After many failures some research informed us we can call a password file and should we not do this then in some instances the service will terminate the connection if not configured to handle not passwd file's for authentication. So I called the -passwd on the zip file which at first did not work. Following this, allot of brain storming and research over the forumns I realized I had to unzip it locally. So I transferred it over with sftp and from there I was able to unzip it and run it as a secret file.