Poison
Reconnaissance:
NMAP:
┌──(kali💀kali)-[~]
└─$ sudo nmap -sC -sV -O 10.10.10.84
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).
TCP/IP fingerprint:
OS:SCAN(V=7.94SVN%E=4%D=1/3%OT=22%CT=1%CU=38486%PV=Y%DS=2%DC=I%G=Y%TM=65962
OS:47D%P=x86_64-pc-linux-gnu)SEQ(SP=103%GCD=1%ISR=10E%TI=Z%CI=Z%II=RI%TS=22
OS:)SEQ(SP=105%GCD=1%ISR=10A%TI=Z%CI=Z%II=RI%TS=21)SEQ(SP=106%GCD=1%ISR=10A
OS:%TI=Z%CI=Z%II=RI%TS=22)SEQ(SP=107%GCD=1%ISR=108%TI=Z%CI=Z%II=RI%TS=21)SE
OS:Q(SP=FD%GCD=1%ISR=104%TI=Z%CI=Z%II=RI%TS=21)OPS(O1=M53ANW6ST11%O2=M53ANW
OS:6ST11%O3=M280NW6NNT11%O4=M53ANW6ST11%O5=M218NW6ST11%O6=M109ST11)WIN(W1=F
OS:FFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FFFF)ECN(R=Y%DF=Y%T=40%W=FFFF%O=M
OS:53ANW6SLL%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=Y%D
OS:F=Y%T=40%W=FFFF%S=O%A=S+%F=AS%O=M109NW6ST11%RD=0%Q=)T4(R=Y%DF=Y%T=40%W=0
OS:%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6
OS:(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%
OS:F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=38%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G
OS:%RUD=G)IE(R=Y%DFI=S%T=40%CD=S)
Network Distance: 2 hops
Service Info: OS: FreeBSD; CPE: cpe:/o:freebsd:freebsd Enumeration: HTTP TCP Port 80
Temporary website to test local .php scripts.
Sites to be tested: ini.php, info.php, listfiles.php, phpinfo.php
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.
phpinfo.php
info.php
pwdbackup.txt
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).
RFI TESTING
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.
expect://id GET /browse.php?file=expect://id HTTP/1.1
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:
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 gives you a base64 encoded version of the source code. Decode the string.
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.
Foothold
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
Exploit 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.
It’s clearly base64 encoded, so let’s decode it:
Local File Include (LFI): Entering those php scripts into the bar does run them, but there’s also an obvious local file include that allows any site visitor to grab any file they want:
With a user name charix here, we could go directly to shell.
Exploit 2: phpinfo.php Race Condition
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!
Exploit 3: Log Poisoning
The phpinfo (which is easy to get from http://10.10.10.84/browse.php?file=phpinfo.php) does show that allow_url_include is off, which eliminates direct RFI.
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:
We’ll modify our user-agent using burp to add a webshell. I always like to add a marker here (like “0xdf:”), so that as the log file grows, we can easily locate our output, either with ctrl-f, or using curl and grep.
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
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.
Then visit:
We get a shell!
Privesc: charix –> root
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.
-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.
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.
Last updated