Kioptrix 2014 is an Intermediate level Boot2Root VM, released under the Kioptrix series of VMs. Kioptrix 2014 was an incredible machine for me since it forced me to get out of my usual routines and go an extra mile for gaining the initial foothold, but the privesc was fairly straightforward.
Let’s start the enumeration process with netdiscover.
netdiscover -Lr 192.168.1.0/24
Where 192.168.1.0/24 is my home network’s range, -L is to keep listening and -r is to specify range.
From that command i’ve found out the IP Address of the target as 192.168.1.4.
we are going to start the enumeration by a Nmap scan.
nmap -sCV -v -oN tcp 192.168.1.4And the output is as follows.
Nmap scan report for 192.168.1.4
Host is up (0.00018s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
22/tcp closed ssh
80/tcp open http Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
|_http-title: Site doesn't have a title (text/html).
8080/tcp open http Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
| http-methods:
|_ Supported Methods: GET
|_http-title: 403 Forbidden
MAC Address: AA:22:CC:44:DD:66 (VMware)There was two Apache web servers running at ports 80 and 8080 and an SSH service running. The Apache service was leaking the OS variant as FreeBSD. Given the distro and the Apache version information I’ve found a possible OS version as FreeBSD version 9.0 with a little googling.
Let’s check the web site running on port 8080.
The web site running at port 8080 was forbidden to us for some reason. This occurs usually because the apache2.conf file is configured to do so. A sample configuration is listed below.
<Directory "/usr/local/www/apache22/data2">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from 192.168.1.2
</Directory>
In the above sample apache2.conf entry, the server will only allow requests with the IP address 192.168.1.2 and discards every request from IP addresses other than this. Let’s keep this information in the back of our head for now.
Moving on..
I’ve bruteforced both the web sites without any interesting results. Since we do not have an initial foothold yet even after bruteforcing, I decided to look at the source code of the web site running on port 80.
Navigating to the said URL showed me the following page.
I digged around the website and found nothing interesting. But, Searchsploit-ing the pChart version has found fruitful as there existed a directory traversal/ LFI vulnerability!
As per exploit-db, the vulnerability can be exploited by requesting the following URL.
hxxp://localhost/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwdSince our server has pchart in a different folder, I changed the URL to the following.
http://192.168.1.4/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd
We are off to a great start! Or so I thought.
My initial plan was to try to get a remote shell using log poisoning. But FreeBSD is does not follow the same linux standards and things are different in several aspects including the location of the log file.
I looked up the location of apache access logs and found the location as /var/log/httpd-access.log and I successfully used the above discovered vulnerability to view the contents of the file.
But, no matter what I tried, I couldn’t find a way to execute code through log poisoning. My poison code was showing up on the logs, but there was some pre processing taking place, before the data gets entered in the log file. So, there is no way to execute my poisoning code, without bypassing the filter.
I’ve tried several iterations of the PHP poison code, but none of them worked. All the quote characters were escaped by the pre-processing script. So, I have decided to move on.
Moving on..
I was stuck at this time. I had no idea how to proceed from here, except continuing the bruteforcing and digging around the server using the LFI vulnerability. So, I decided to do so.
We only had three services running in the target. SSH on port 22 and two web servers on port 80 and 8080; where port 8080 was inaccessible for us. Like we discussed above, this was configured using the apache.conf file.
But, since we are dealing with FreeBSD, the file name and location varied. I looked up the configuration file location and found it as /usr/local/etc/apache22/httpd.conf.
Examining the apache configuration file was fruitful as it showed the following (weird) configuration.
So, I installed a FireFox addon called User-Agent Switcher by Alexander Schlarb, added a custom User agent string and navigated to the web server running at port 8080.
Searchsploit-ing the name phptax showed me the following results.
I decided to try the manual exploits before going into using Metasploit exploits. I knew it was harder, but where is the learning experience in exploiting the easy way?
I was able to exploit the phptax using both manual way and the msf way. Let’s discuss how I exploited the machine using both ways.
Method#1 Exploitation using Manual Exploit.
I knew that I needed to modify the exploit to accommodate the special condition (the weird UA string) for the exploit to work. And with some struggling I’ve modified a rce script I’ve found on carnal0wngae’s github repo to work with Kioptrix 2014. Actually I made two scripts: a python2 one and a python3 one.
Along with the UA string, I also swapped the payload in the original script to accommodate two separate payloads in my script; as the original bind shell payload wasn’t working for me. This can be selected by passing the command line argument 1 or 2 into the script.
The first payload in my version of the phptax_rce script uses the netcat without -e reverse shell method and the second payload uses telnet to spawn a reverse shell. The second payload (Telnet) used in my version of the script is a modified version of the payload used by the Phptax MSF module.
You can find the modified scripts from my github repo.
Keep in mind that, when using a nc listener, I had to use the -k flag with nc, because if I didn’t specify the -k flag, then sometimes the shell would die upon receiving the connection back. This mostly happened when I used the telnet payload. So, it would be better to stick with the nc without -e payload.
Method#2 Exploitation using MSF module.
Exploitation using phptax_exec MSF module was fairly straight forward for me, except the fact that we have to modify the UA string. As far as I know, there wasn’t a built-in option inside MSF to swap the User Agent string without fiddling with the module’s script. To keep things simple, I decided to alter the User Agent on the fly using Burp suite.
So, I set the PROXIES option to redirect the traffic to Burp Suite and set the ReverseAllowProxy option as true. We are setting ReverseAllowProxy as true because, by default MSF doesn’t allow TCP-Connect back payloads when specifying proxies. So, by setting ReverseAllowProxy option as true, we are overriding this behavior.
Along with the usual options, we had to specify a payload before running this module; which by the way was not specified anywhere in the module. If we run the module without specifying a payload, there will be an error.
Also, the payload should be selected by typing set payload and pressing the <tab> button, to let the autocomplete function list the available payloads. We are using the tab auto complete feature instead of explicitly specifying a payload here, because this module only supports a handful of payloads and we want to see the list of available payloads.
As you can see from the above image, I selected the cmd/unix/reverse payload.
set payload cmd/unix/reverseNow, when I executed the module with run -j, Burp suite captured the traffic and I chaned the User Agent string.
And once I forwarded the request, I got a connection back!
Moving on to Privilege escalation…
Now, I knew the O.S version was an old one and chances are high that there is a kernel exploit for this version. But, I decided to try that later and explore the machine to find any vulnerabilities that I can exploit manually.
I tried different things in the machine. I ran linpeas script, manually went into different directories; you know, the usual stuff.
But I couldn’t find any manual vector to escalate the privileges. Linpeas output showed the presence of gcc in the machine, which pointed that this box was probably meant to be rooted using a kernel exploit. So, I searchsploit-ed FreeBsd 9.0 and found a kernel exploit for it. FreeBSD 9.0 < 9.1 – ‘mmap/ptrace’ Local Privilege Escalation- [EDB-ID 26368]
I transferred the 26368.c script using nc, compiled it with gcc and got root!
There was a congratulaion.txt flag in the /root directory, which explained the tools and technologies used by the author; which was a nice touch! Kudos to loneferret for this machine and going this extra mile.
Loneferret also created a custom script to monitor and log the modified directories or files. He also installed “OSSEC-HIDS”; an IDS for monitoring the attacks and logging them. This will gave us an idea of how noisy the attacks are from a blue team perspective.
Overall this was a great VM to learn pentesting and it was indeed a great learning experience for me!
SecNigma