In my road to OSCP certification, one of the common to-dos as many before me have done in preparation for the exams was to take on the retired machines available in Hack in The Box (HTB) platform. This platform is a great platform for practicing and learning new penetration testing skills as well as taking on the challenge of “capturing the flag” on their machines.
In this HTB series, I will be sharing my write-ups on all the retired machines that I have and will attempt. If you are wondering, “How does he know which machine to do to prepare for OSCP?” Well, I am using TjNull list of OSCP-like boxes in HTB which can be found here
This box is pretty interesting. It requires a decent amount enumeration and the path of exploitation to get the initial user shell is interesting that it uses log file poisoning (hence the box name) technique to exploit the LFI vulnerability. This occurs usually when input data comes from an untrusted source and that data is written on an application or system log file. Manual Enumeration is required for the privilege escalation.
Recon Phase
To begin with this box, we first carry out our basic Reconnaissance. For me, I used AutoRecon which is developed and scripted by Tib3rius. It is one of my fundamental scans I make before moving on to more manual enumeration for specific ports or applications. From the initial Nmap scan results done by AutoRecon:
We can see that Port 22 and Port 80 is open. Port 22 is OpenSSH 7.2 and Port 80 is Apache httpd 2.4.29 (FreeBSD) with PHP 5.6.22. Just this initial Port scan, we are given with information about the OS which is FreeBSD and that PHP 5.6.22 is used on our web service on Port 80. It is usually unusual for us to be able to gain any access on Port 22 so that is probably not the focus of this machine.
Information Gathering
Browsing the IP Address of the box on the web browser. We notice that we are brought to a page that looks like this:
This web application that is hosted here is interesting. It seems to be some website that allow us to test local .php scripts. It even gives us an example of what we can put in the form. Submitting info.php or phpinfo.php will give us the following views:
One thing I notice is how the URL has a ?file=phpinfo.php This indicate to us that the input we use is actually sending a filename and opening it up as what we see on the browser. Knowing this, I suspected that a Directory Traversal Vulnerability might be possible with this. So, I replaced the ?file=phpinfo.php with ?file=../../../../../../../../etc/passwd
We have managed to successfully read the file! This mean that we can do a directory traversal and read files that we are not supposed to initially. During the enumeration of the information found through phpinfo.php file, we also notice that allow_url_include is disabled. Therefore, this eliminates the option of RFI. Thus to exploit this, we have to rely on LFI for code execution. We check if we can access?file=../../../../../../../../var/log/httpd-access.log :
Exploitation
Since we are able to access the apache log, we want to attempt log poisoning to load up our malicious payload on this log by interacting with the web server and access this log in an attempt to execute the malicious payload.
When we add the additional parameter&cmd=ip a to the URL:
We see the output for ip a is now on the log file when we access it. We are able to gain command execution on the server now!
We then try the command ls -la for the &cmd parameter:
We see that there is a pwdbackup.txt . When we tried reading the file:
Here, we see that this is a password file and the author of this file has mistaken encoding for encrypting. He even included the number of times this encoded string has been encoded. Looking at the encoded string, it seems likely that it is a base64 encoded string because of the encoded string ends with a = . Thus, attempting to base64 decode this encoded string 13 times will give us the password to a user.
We then look at the /etc/passwd again and we see that there is a charix user which looks like the password. Using the password to SSH in, we obtain a foothold:
After gaining a foothold, we can now obtain the user.txt !
Privilege Escalation
Information Gathering
Initially, I would transfer and run the enumeration scripts that I commonly used to find Privilege Escalation vectors. However, in this machine, one of the interesting find is that I am unable to execute the sh script on this machine. So I decided to do a manual enumeration to dig deeper. Alas, the answer is usually quite in your face which I fail to see in an attempt to download the scripts to automate my privilege escalation information gathering phase.
A quick look at the home directory of Charix:
It seems like the secret.zip is available. However, the file requires a password which we will need to crack if the previous password found was not reusable. However, we know people like to reuse passwords too. We first transfer the file back to the attacking machine:
Then we attempt to unzip this file by using the password that we used to SSH in as Charix:
Bingo. We managed to obtain a secret file. This file seems to some kind of passfile which can be used for another process or service. We then checked current processes running to which we will notice an interesting process running for VNC.
Checking out ports to just be sure that the VNC port is open to us locally:
We see that there is 2 ports, port 5801 and 5802 that is open to us locally. These were the ports that our remote Nmap scan missed because it is a local listening port. Googling these ports would tell us that these likely belongs to the VNC process we saw earlier.
Exploitation to get Root
With the information that we gathered, It is likely that the secret file, which is a possible password file that can be use for authentication purpose is used for the VNC service. To help us exploit this, we will need to do port forwarding and use our attacking machine’s VNCviewer to connect to the VNC service port forwarding on port 5000.
We attempt to port forward our local port 5000 to the machine’s local port 5901. This means that whatever command given to our local port 5000, will be forwarded to the victim machine’s port 5901
ssh -L 5000:127.0.0.1:5901 charix@10.10.10.84
Then using netstat -an on our attacking machine we can check if the port forwarding is successful.
It is successfully done. We then use the VNCviewer on our attacking machine and realise that the VNCviewer has a -passwd <passwd-filename> option for us to utilise. We use that and attempt an access with the secret file we found earlier:
This will pop up the VNC client which is the terminal for our victim machine and we are root on this terminal, which means we have successfully privilege escalate ourselves to root!
We then use this terminal and obtain our root.txt!
Learning Points
This box is interesting in that to get the foothold, we did not exploit the LFI vulnerability to gain a reverse shell but we retrieve a file to obtain the password of a user in the box. This is really the reason why we should not store password files or sensitive files unencrypted on web servers and we should avoid storing sensitive files in web root folders as well. Another interesting thing is the way we exploited LFI is via log poisoning as it shows how we gain code execution if proper measures are not taken in place to prevent it. The privilege escalation reminded me to not be over-reliant on scripts or automated scans and not to tunnel-vision on the results from automated enumeration tools as well. Again, passwords used to zip secret files should not be the same passwords we use to login via SSH and we should avoid password reuse as much as possible.
Thank you for reading! And like always if you enjoy this write-ups, subscribe to my publications or follow me on twitter @lojomojo96 and hit me up with a DM! It will really encourage me to write and share even as I prepare for my OSCP Certification. Of course, if there are points to improve upon my own methodology, do let me know too!
