Poison Writeup w/o Metasploit
Last updated
Last updated
First thing first, we run a quick initial nmap scan to see which ports are open and which services are running on those ports.
-sC: run default nmap scripts
-sV: detect service version
-O: detect OS
-oA: output all formats and store in file initial
We get back the following result showing that 2 ports are open:
Port 22: running OpenSSH 7.2
Port 80: running Apache httpd 2.4.29
Before we start investigating these ports, let’s run more comprehensive nmap scans in the background to make sure we cover all bases.
Let’s run an nmap scan that covers all ports.
No other ports are open.
Similarly, we run an nmap scan with the -sU flag enabled to run a UDP scan.
We get back the following result showing that no other ports are open.
Before we move on to enumeration, let’s make some mental notes about the nmap scan results.
The OpenSSH version that is running on port 22 is not associated with any critical vulnerabilities, so it’s unlikely that we gain initial access through this port, unless we find credentials.
Ports 80 is running a web server, so we’ll perform our standard enumeration techniques on it.
I always start off with enumerating HTTP first.
Port 80
Visit the application in the browser.
It’s a simple website that takes in a script name and executes it. We’re given a list of scripts to test, so let’s test them one by one. The ini.php & info.php scripts don’t give us anything useful. The phpinfo.php script gives us a wealth of information on the PHP server configuration. The listfiles.php script gives us the following output.
The pwdbackup.txt file looks interesting. Let’s see if we can view it in the application.
We get the following output.
Based on the output, we can deduce that the application is not validating user input and therefore is vulnerable to local file inclusion (LFI). Based on the comment, this file includes a password that is encoded. Before we go down the route of decoding the password and trying to SSH into an account using it, let’s see if we can turn the LFI into a remote file inclusion (RFI).
There are several methods we can try.
PHP http:// Wrapper
The PHP http wrapper allows you to access URLs. The syntax of the exploit is:
Start a simple python server.
Attempt to run a file hosted on the server.
We get an error informing us that the http:// wrapper is disabled. Similarly, we can try ftp:// but that is also disabled.
PHP expect:// Wrapper
The PHP expect wrapper allows you to run system commands. The syntax of the exploit is:
This functionality is not enabled by default so let’s check if our application has it enabled. Intercept the request using Burp and attempt to run the ‘id’ command.
We get an error informing us that the PHP expect wrapper is not configured.
PHP input:// Wrapper
The input:// wrapper allows you to read raw data from the request body. Therefore, you can use it to send a payload via POST request. The syntax for the request would be:
The syntax for post data would be:
This doesn’t work for our request, but I thought it was worth mentioning. There are several other techniques you can try that are not mentioned in this blog. However, I’m confident that the application is not vulnerable to RFI so I’m going to move on.
One useful technique you should know is how to view the source code of files using the filter:// wrapper.
PHP filter:// Wrapper
When a file such as index.php is executed, the page only show the output of the script. To view the source code, you can use the filter:// wrapper.
This will encode the page in base64 and output the encoded string.
For example, to view the ini.php file, run the below command.
This gives you a base64 encoded version of the source code. Decode the string.
You get the source code.
We diverged a little bit from solving this machine, the conclusion of all the above testing is that it is not vulnerable to an RFI. So let’s move on to gaining an initial foothold on the system.
Gaining an initial foothold can be done in three ways.
Decode the pwdbackup.txt file and use the decoded password to SSH into a user’s account.
Race condition exploit in phpinfo.php file that turns the LFI to an RCE.
Log poisoning exploit that turns the LFI to an RCE.
I initially got access to the machine using method 1 and then exploited methods 2 & 3 after watching ippsec’s video.
Method 1: pwdbackup.txt
The output of the pwdbackup.txt file gives us a hint that the password is encoded at least 13 times, so let’s write a simple bash script to decode it.
Save the script in a file called decode.sh and run it.
We get back a password. We want to try this password to SSH into a user’s account, however, we don’t have a username. Let’s try and get that using the LFI vulnerability. Enter the following string in the Scriptname field to output the /etc/passwd file.
We get back the following data (truncated).
Only two users have login shells: root and charix. Considering the password we found, we know it belongs to Charix.
SSH into Charix account using the credentials we found.
View the user.txt flag.
Method 2: phpinfo.php Race Condition
In 2011, this research paper was published outlining a race condition that can turn an LFI vulnerability to a remote code execution (RCE) vulnerability. The following server side components are required to satisfy this exploitable condition:
An LFI vulnerability
Any script that displays the output of the PHPInfo() configuration
As we saw in the enumeration phase, the Poison htb server satisfies both conditions. Therefore, let’s download the script and modify it to fit our needs.
First, change the payload to include the following reverse shell available on kali by default.
Make sure to edit the IP address and port. Next, change the LFIREQ parameter to the one in our application.
You’ll also have to change all the “=>” to “=>” so that the script compiles properly.
That’s it for modifying the script. Now, set up a listener to receive the shell.
Run the script.
We get a shell!
Method 3: Log Poisoning
This was probably the intended way of solving the machine considering that the box is called “Poison”. Log Poisoning is a common technique used to gain RCE from an LFI vulnerability. The way it works is that the attacker attempts to inject malicious input to the server log. Then using the LFI vulnerability, the attacker calls the server log thereby executing the injected malicious code.
So the first thing we need to do is find the log file being used on the server. A quick google search tells us that freebsd saves the log file in the following location.
A sample entry in the access log is:
Notice that the user agent “Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0” is being logged. Since the user agent is something that is completely in our control, we can simply change it to send a reverse shell back to our machine.
Intercept the request in Burp and change the user agent to the reverse shell from pentestmonkey.
Set up a listener to receive the reverse shell.
Execute the request in Burp so that the PHP code is saved in the log file. Using the LFI vulnerability call the log file which in turn should execute the reverse shell.
We get a shell!
Since the machine is running a freeBSD OS, the LinEnum script won’t work on it. So we’ll have to resort to manual means of enumeration.
If you list the files in Charix’s home directory, you’ll find a secret.zip file.
If you try to decompress the file, it will ask for a password. Let’s first transfer the file to our attack machine.
Try to decompress the file using Charix’s SSH password. Most user’s reuse passwords.
It works! Check the file type.
The file seems to be encoded. Before we go down the route of figuring out what type of encoding is being used, let’s park this for now and do more enumeration.
In the target machine, run the ps command to see which processes are running.
There’s a VNC process being run as root.
Let’s view the entire process information.
VNC is a remote access software. The -rfbport flag tells us that it’s listening on port 5901 on localhost.
We can verify that using the netstat command.
Since VNC is a graphical user interface software, we can’t access it through our target machine. We need port forwarding.
The above command allocates a socket to listen to port 5000 on localhost from my attack machine (kali). Whenever a connection is made to port 5000, the connection is forwarded over a secure channel and is made to port 5901 on localhost on the target machine (poison).
We can verify that the command worked using netstat.
Now that port forwarding is set, let’s connect to VNC on the attack machine.
I tried Charix’s password but that didn’t work. I then googled “vnc password” and found the following description on the man page.
When setting a VNC password, the password is obfuscated and saved as a file on the server. Instead of directly entering the password, the obfuscated password file can be included using the passwd option. Earlier in this blog we found a secret file that we didn’t know where to use. So let’s see if it’s the obfuscated password file we’re looking for.
We’re in!
VNC was running with root privileges so we can view the root.txt file.
Before we end this blog, let’s check if there is any online tools that decode the obfuscated password file. Since it’s not encrypted, we should be able to reverse it without a password.
After a bit of googling, I found this github repository that does that for us. Clone the repository and run the script on our file.
-d: decrypt
-f: file
We get the following output showing us the plaintext password is “VNCP@$$!”.
Now that we know the password, we could directly log into VNC using the plaintext password instead of the obfuscated password file.
To gain an initial foothold on the box we exploited four vulnerabilities.
LFI vulnerability that allowed us to both enumerate files and call and execute malicious code we stored on the server. This could have been easily avoided if the developer validated user input.
Sensitive information disclosure. The pwdbackup.txt file that contained a user’s SSH password was publicly stored on the server for anyone to read. Since the content of the file was encoded instead of encrypted, we were able to easily reverse the content and get the plaintext password. This could have been avoided if the password file was not publicly stored on the server and strong encryption algorithms were used to encrypt the file.
Log file poisoning. Since the log file was storing the user agent (user controlled data) without any input validation, we were able to inject malicious code into the server that we executed using the LFI vulnerability. Again, this could have been easily avoided if the developer validated user input.
Security misconfiguration that lead to a race condition in phpinfo.php file. This required two conditions to be present: (1) an LFI vulnerability which we already discussed, and (2) a script that displays the output of the phpinfo() configuration. The administrators should have disabled the phpinfo() function in all production environments.
To escalate privileges we exploited one vulnerability.
Reuse of password. The zip file that contained the VNC password was encrypted using Charix’s SSH password. The question we really should be asking is why is the password that gives you access to the root account encrypted with a lower privileged user’s password? The remediation recommendations for this vulnerability are obvious.
