VulnHub — Kioptrix: Level 3

14 min readJun 1, 2018

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, my goal is to work through this series and document my findings along the way.

Setup:

Download the Kioptrix VM from Kioptrix.com and use RAR to expand the compressed file. Since my Host machine is Linux (Ubuntu 16.04), I launched VMWare Player and selected the updated “KioptrixVM3.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. Since Kioptrix uses DHCP, one has the choice of using Private Networking or Bridged Networking. I ended up configuring the NIC for Private Networking in order to keep Kioptrix off of my production network.

Since I am using a Private Network, I decided to deploy the 32-bit VMware Image of Kali Linux from Kali.org. However, I also added a Bridged NIC so that I could remotely connect from a system located on my production network. In addition, I created a Kioptrix_3 directory within root’s home directory, on the Kali system, to capture and store files.

Victim Description:

Based on reviewing the VulnHub.com site, the listed vulnerabilities are

File Inclusion
Improper Access Control
Reused Credentials
SQL Injection
Unrestricted Upload of File with Dangerous Type
Weak Credentials

In addition, there is a text flag that located on the system.

Information Gathering:

Since I am using a Private Network on a remote Linux Host, I chose to review the network settings on the Kali system to determine the Private Network IP Address and Subnet Mask.

With the Kali system’s IP Address and Subnet Mask obtained, Nmap for an initial scan of the subnet was used.

The parameters used for Nmap will perform an Aggressive Ping scan of the 172.16.209.0/24 subnet and then output the findings into three different file formats starting with the name of NmapFast.

Using the output file that ends with the “.gnmap” extension, issue the cat command and pipe in the grep command to find the key word of “Up”. In addition, add an additional pipe to issue the cut command to only copy the IP Addresses, from the second column, to output to the LiveHosts file.

In reviewing the returned IP Addressing of the LiveHosts file, we know that 172.16.209.1 and 172.16.209.254 are assigned to the VMWare Private Network. In addition, we know that 172.16.209.129 is the Kali system. So, through the process of elimination, the Kioptrix system is 172.16.209.130.

In order to save time on scanning, remove the non-Kioptrix IP Addresses from the LiveHosts file prior to issuing the second Nmap scan.

This time, the Nmap command will use the LiveHosts input file to perform an Aggressive Service scan, this treats all hosts as being online, to probe all TCP SYN ports and then output the findings into three different file formats starting with the name of NmapFull.

Reviewing the Nmap scan results, TCP Ports 22 was Open SSH version 4.7p1 and TCP Port 80 was using Apache Server version 2.2.8 with PHP/5.2.4–2. The OS appears to be Ubuntu using Linux Kernel 2.6.9–2.6.33.

I decided to run Nmap with the Intense parameter for additional details.

Items of interest would be with the PHPSESSID not having the cookie flag set. In addition, it would appear that the website starts out as the root directory.

To take a closer look at TCP Ports 80, I launched Nikto with the host, port, and output file parameters.

An area to further investigate would be the phpMyAdmin directory.

Enumeration:

Using the information gathered from the scans, I decided my next logic step was to start manually enumerating the Kioptrix web site. So, I opened a browser and typed in the IP Address for the Kioptrix system.

Once connected to the web site, I clicked on the Blog menu to review the information on the Blog. There are two items on this page that I ended up missing during my first pass.

The first item refers to a Gallery page on the Kioptrix system. The second item appears to be a possible username called loneferret.

Next, I clicked on the Login menu located within the light grey bar within the web page. I tried to use SQL injection within the Username and Password fields, but that did not work. However, I noticed that the site was using the content management system of LotusCMS.

Prior to exploring the local Kioptrix web site any further, I decided to launch searchsploit with the -w switch to determine if the LotusCMS had any vulnerabilities.

Right-clicking on the hyperlink opened a browser and displayed the information about the vulnerability on the Exploit Database site. This is where I was able to determine that the LotusCMS was vulnerable to Remote Command Execution with Metasploit.

Exploiting LotusCMS:

Knowing that LotusCMS was vulnerable to Remote Command Execution, I launched Metasploit and searched for the keyword of lotuscms.

Metasploit returned with an excellent ranked exploit. However, I was not sure which version of LotusCMS was installed on the system.

So, I decided to move forward and attempted to exploit LotusCMS regardless of the version. I instructed Metasploit to use the exploit and then I issued the options command to determine the required parameters.

I then set the parameters of the RHOST, URI, and LPORT.

· RHOST = IP Address of the Kioptrix system

· URI = root folder of the website (obtained from the Information Gathering section)

· LPORT = local port used on the Kali system to communicate from the RHOST (a recommendation I picked up from the TrustedSec guys during InfoSec World 2018).

I reviewed the parameters one last time by issuing the options command again.

Once satisfied with the parameter settings, I issued the run command to execute the exploit.

A successful session was established.

To gather additional information about the system and current user, I issued the sysinfo and getuid commands within the session.

The Kernel version was 2.6.24–24 and the user was www-data.

From meterpreter, I viewed the /etc/passwd file and made note of the accounts loneferret and dreg.

Next, I tried to view the /etc/shadowfile. However, the www-data account does not have permission to view the file.

I continued to manually search the directory structure and found a wwwdirectory within /home. Based on my initial findings, there were three directories to research.

In reviewing the /home/dreg directory, there was nothing interesting to review. However, reviewing the /home/loneferret directory turned up some interesting information.

Opening the CompanyPolicy.README provided information of using the sudo ht command as part of the company policy to install software.

I decided to execute the sudo ht command in a shell launched from meterpreter.

Without the www-data password, nor any other credentials, I was not able to successfully launch the sudo ht command.

Continuing the manual search of the /home, the www directory appears to be the local web site on the Kioptrix system. I decided to use the search command for any files that contained the key word of config.

Further inspection of the /home/www/kioptrix3.com/gallery/gconfig.php file appears to have hard coded rootcredentials for the gallery database.

Next, I launched a browser and returned to the Kioptrix web page. As noted from the Information Gathering section, Nikto uncovered a phpMyAdmin directory on the web site. So, I appended that information to the Kioptrix system’s IP Address (http://172.16.209.130/phpmyadmin).

With the phpMyAdmin login page visible, I entered the root credentials and clicked the Go button.

Excellent!!! I had the root credentials to the database.

Exploring the database application, I selected the gallery database from the menu pane on the left side of the page. Additional options appeared once selected.

Next, I selected the dev_accounts menu from the left menu pane. This provided additional tab options at the top of the main page.

Selecting the Browse tab revealed the username and password credentials for dreg and loneferret. I made a note of the hashes for later use.

Exploiting Local File Inclusion:

During the enumeration process, I launched a browser and connected to the Kioptrix local web site.

Seeing that the local website used PHP, I tried to determine if the PHP scripts had been sanitized. I added the ../../../../../etc/passwd directly after the = sign within the URL.

Unfortunately, I did not receive any results. So, I turned to the Internet to research for PHP LFI vulnerabilities. In reading the OWASP “Testing for Local File Inclusion” guide, it was noted that a null-byte terminator may be needed to signify the end of a string.

So, I re-entered the ../../../../../etc/passwd and added %00jpg at the end of the string. I added the jpg after the string as a technique suggested within the OWASP article.

Success! I captured usernames from /etc/passwd.

Exploiting SQL Injection:

Important: the attacking system must have the its /etc/hosts file updated with an entry for kioptrix3.com. Otherwise, reference to kioptrix3.com will attempt to connect to the Internet and the image files may not be displayed correctly.

As a side note, I will be going into greater detail than what may be needed for some. For me, I am attempting to gain a better understanding of SQL Injection and where/how to apply the tools for detection and exploitation.

I launched a browser and connected to the Kioptrix local web site. I then clicked the now! hyperlink and was redirected to the gallery page.

Next, I opened a terminal and launched sqlmap with the URL for the gallery page.

Does not appear to have been successful.

Exploring the gallery page, I clicked on the Recent Photos hyperlink. This redirected me to the recent page.

Continuing with sqlmap, I used the recent page URL to find injectable results.

Still no luck with sqlmap.

Exploring the recent page did not yield any interesting results. So, I clicked on the Home hyperlink to be redirected back to the gallery page.

Within the gallery page, I clicked on the Ligoat Press Room hyperlink. This redirected me to the g.php/1 page.

Once again, I cranked up sqlmap to determine if there were injectable parameters within the gallery/g.php/1 page.

And once again, no luck with sqlmap.

Within the g.php/1 page, I noticed a down spinner.

From the down spinner, I selected Photo Id. The page added the code for the sort within the URL.

Using sqlmap again, I scanned the /gallery/gallery.php?id=1&sort=phtoid#photos URL.

This time, sqlmap determined that the id parameter might be injectable, and the backend database appears to be MySQL.

Next, I ran sqlmap against the /gallery/gallery.php?id= with the –dbs switch to determine the databases that were present.

Good results. I have the MySQL version (5.0.12), OS information (Ubuntu 8.04), PHP version (5.2.4), and Apache version (2.2.8). In addition, there were three databases installed on the Kioptrix system.

· gallery

· Information_schema

· mysql

Continuing with sqlmap, I ran the -D gallery and –tables switches to enumerate the tables within the gallery database.

Looks like the gallery database contains seven tables.

Using sqlmap again, I ran the -D gallery and -T dev_accounts — dump switches to enumerate the data within the gallery database. In addition, I chose the default answers to the questions that were asked once sqlmap was executed.

Awesome! I obtained the credentials for the dreg and loneferret accounts.

Next, I used sqlmap to determine the tables contained within the mysql database.

The mysql database contains 17 tables.

Using sqlmap, I ran the -D mysql and -T user –dump -C ‘host, user, password’ switches to enumerate the data within the sqlmap database. In addition, I chose the default answers to the questions that were asked once sqlmap was executed.

Note: The first time I ran the sqlmap without the -C switch, the output was difficult to read.

Cool!! Looks like I have the MySQL hashes for root and debian-sys-maint accounts.

Cracking:

Having both usernames from /etc/passwdand now the usernames and hashes from phpMyAdmin, I had enough information to use a password cracker to recover the credentials. I decided to use Hydra and HashCat.

Method 1:

I created a text file named users and added the loneferret and dreg usernames to the file. I then launched Hydra to do a brute force crack against the Kioptrix system using the following parameters:

· -L = Login File

· -P = Password File

· ssh = port

· -e nsr = n: null password, s: login and pass, and r: reversed login

· -f = exit after login/password found

· -t 4 = parallel number of connected tasks

Excellent! Hydra cracked the loneferret account.

Method 2:

I copied the hashes from the phpMyAdmin page (see above) into a text file named hash.txt.

Using my cracking rig, I launched HashCat in attack mode, for MD5, using the rockyou.txt wordlist against the hash.txt file and writing the output to the Kioprix_3-Pass.txt file.

Within a few seconds, HashCat cracked the hashes.

Reading the output file, I had the credentials for loneferret and dreg.

Based on the above two methods, it appears that the users reused credentials. The same credentials are used for the local Kioptrix system as well as the phpMyAdmin application.

In addition, weak credentials were used based on the cracked passwords of starwars and Mast3r.

Exploiting Improper Access Control:

Using the loneferret credentials, I used SSH to connect to the Kioptrix system. Once connected, I validated the account being used.

Next, I issued the sudo -l to determine which commands were allowed using sudo.

After re-reading the CompanyPolicy.README from the /home/loneferret directory, I issued the sudo ht command.

Unfortunately, I ran into an error opening the terminal with xterm-256color. I did some research and determined that if the export TERM=xterm command was used, it would by-pass the xterm-256color error.

Next, I re-issued the sudo ht command and it launched without issue.

The ht editor opens within the terminal window. At this point, I should be able to open any file with root permissions.

Using the ALT key to navigate, I opened the /etc/sudoers file. The /etc/sudoers allowed me to add root privileged commands for the loneferret account.

With the /etc/sudoers file open, the loneferret account already had a line item with root privileges to two commands that did not require a password entry.

In order to obtain root privileges for the loneferret account, I needed to add ,/bin/sh directly after /usr/local/bin/ht. This provided root access to the sh shell.