Summary

Kioptrix 2014 is an Apache web server running on FreeBSD.

It hosts a web app vulnerable to Local File Inclusion that was used to enumerate and expose another web app.

The additional webapp is vulnerable to Remote Code Execution that was used to drop a webshell and spawn a reverse shell. Once on the system, two kernel exploits were successfully used to gain root access.

Recon / Scanning

My initial recon was an arp scan of the local network in order to quickly return the target’s IP address on my private range with netdiscover .

netdiscover -r 192.168.15.0/24

-r to specify network range

netdiscover

Next I enumerated services on the host with an nmap scan

nmap -sV -sC 192.168.15.150

-sV to probe open ports to determine service/version info

-sC to run default scripts

nmap

We can see two web ports open on a FreeBSD host running Apache

Next, I tried to enumerate web directories using dirb and gobuster

dirb port 80

403 = Forbidden

200 = OK

index.html

index.html appears to be a default webpage

This scan didn’t yield much… let’s check out port 8080

dirb port 8080

Not much again this time.

At this point, I want to validate the lack of information with another tool.

I chose gobuster .

-w to specify a wordlist (Kali has several built-in)

-u to specify a URL

-s to specify responses to look for

200,204,301,302, 307 are default; I added 403 due to the dirb results

This scan ran for several minutes with no results.

Moving on to port 8080 with the same scan…

gobuster 8080

Almost every line in the wordlist was returning Forbidden responses — which was also easy to validate from a browser.

Something strange is going on here…

Finally, I run a nikto scan to enumerate any known vulnerabilities.

nikto -h 192.168.15.150

-h to specify host

nikto 80

The results were very similar on port 8080.

Looking this over, we see mod_ssl is out of date.

I found a vulnerability for this service and version that seemed like it should have worked but I never landed the exploit… possibly something to revisit.

At this point, there doesn’t seem to be a lot to work with so I revisit the default landing page and look at the page’s properties.

pChart2.1.3/index.php

There’s not a lot else to poke at, so I try visiting the URL listed in the properties.

pChart 2.1.3

And we’ve got a webpage!

Initial Exploit

searchsploit returned two vulnerabilities for this webapp:

Local File Inclusion Cross-Site Scripting

pChart LFI

I was able to validate the LFI with the example:

/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd

/etc/passwd

According to FreeBSD documentation, Apache config files are located at /usr/local/etc/apache2x/httpd.conf , since we know the host is running Apache 2.2 from our scans, the path to view the file is:

/index.php?Action=View&Script=%2f..%2f..%2fusr/local/etc/apache22/httpd.conf

httpd.conf

We can see that port 8080 only allows Mozilla4 user agents — which is why we kept getting blocked earlier!

Mozilla/4.0 is Microsoft’s Compatibility View and Internet Explorer 7’s user agent string.

I was going to change this in the browser itself, but then I encountered this…

nope

I decided to use burpsuite instead.

This is pretty trivial, but I didn’t want to leave intercept on and edit each request manually.

And I didn’t have to!

burpsuite has a built-in “Match and Replace” feature under Proxy > Options that had the change in my history. All I had to do was tell burp to keep doing that for me by checking a box!

Now I’m able to get to port 8080!