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 “Kioptrix Level 1.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 choosing Private Networking in order to keep Kioptrix off of my production network.
As a side note, I did have a few issues with Private Networking where the Kioptrix system was not receiving an IP Address. My work around this issue was to delete and re-add the NIC; which seemed to resolve the issue.
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_1 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 buffer errors and privilege escalation. In addition, there is a flag that can be captured within email.
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 and 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.131.
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 open ports and then output the findings into three different file formats starting with the name of NmapFullScan.
Reviewing the Nmap scan results, TCP Ports 80 and 443 are using Apache Server version 1.3.20 with Open SSL version 0.9.6b. Also, TCP Port 22 is using Open SSH version 2.9p2 and TCP Port 139 is using Samba (version unknown at this time).
To take a closer look at TCP Ports 80 and 443, launch Nitko with the host and port parameters. In the example below, there were minor differences in the output between Port 80 and Port 443.
Nikto did find CVE-2002–0082; which can be exploitable for a remote shell. Make a note to research this exploit in a later step.
Moving on to TCP Port 139 and Samba, I used nbtscan to gather additional information about this service.
Enumeration:
Using the information gathered from the scans, I used Dirb to scan the web server for hidden directories or other items that may be useful.
Based on the findings, I explored each one of the hyperlinks. However, the exploration did not provide detail of any additional exploits.
Moving on to Samba, I used enum4linux to enumerate the SMB Service. Enum4linux found that the system allowed Null sessions. However, there appeared to be an issue with enum4linux being able to return information regarding the SMBClient.
In addition, when reviewing examples that others used, the section of Share Enumeration usually returns an error and indicates the version of the SMBClient. However, the green box outlines the area where the error should be seen and is not.
Since enum4linux reported that the Samba services were installed on the Kioptrix system with a Null session, I used rpcclient to create a session.
Once connected to the shell, I issued the sysinfo command to determine the version of Samba. But once again, I was unable to determine the specific version.
Being shot down by enum4linux and rpcclient, I moved to msfconsole to see if its’ smb scanner could determine the SMB version.
I searched the Metasploit database and found a smb version scanner. So, I instructed msfconsole to use the auxiliary module and then issued the info command to determine the required parameters.
Reviewing the parameters requirements, I set the RHOSTS parameter to the IP Address of the Kioptrix system.
Once I validated the parameters, I executed the script with the run command.
Finally, I have the Samba version and I can now research it as well as the other service versions captured from above.
Exploiting OpenSSH:
In researching OpenSSH 2.9p2, I was able to obtain the information that this version was vulnerable with the “off-by-one error in the channel code.” However, I was unable to find a usable exploit for CVE-2002–0083 at this time.
Exploiting Samba:
Researching Samba version 2.2.1a, there appears to be at least two methods that can be used to exploit Samba. The first method involves Metasploit and the second version involves a Perl script.
Method #1
This method is a walkthrough of using Metasploit to gain root access. For a better comprehension of the processes, I have included successes and failures.
After launching msfconsle, search for the CVE with the above information.
Once the exploit module was identified, the use command was issued to load the exploit module.
Next, the info command was issued to obtain further information as well as parameter requirements.
Utilized the set command to input the remote host’s IP Address.
Reviewed the options for the exploit.
Launched the exploit with the run command.
Looks like there are issues trying to open the session(s). In doing some additional research, it would appear that a payload will need to be specified.
Since the remote server appears to be a Linux x86 operating system, a payload for a reverse shell will need to be used.
Reviewing the options one last time prior to executing the exploit.
Re-launch the exploit with the run command.
A successful shell with root access.
Method #2
In this method, I have included my successes and failures with gaining root. This method is a walkthrough of using different scripts.
I reviewed the searchsploit database installed on the local Kali system. I issued the -w switch with the parameters of linux and samba to narrow the search. I reviewed several of the exploits that matched the version of Samba until I found a vulnerability for the call_trans2open function (noted above prior to Method #1).
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 download the trans2root.pl script in order to exploit the vulnerability. As a side note, the script could have been used from the local Kali searchexploit database instead.
After the Perl script was downloaded, the head command was used to review the switches and parameters required prior to executing the script.
Once executed, this script ran for about thirty minutes with no results.
After striking out with the Perl script, I decided to do an Internet search for the Samba 2.2.1a. The first site listed was another entry within the Exploit Database site.
After reviewing the information about the Remote Code Execution, I ran searchsploit with the keyword of “Samba 2.2.8”to determine if it was present within the database.
After searching the database once again, the exploit file was found.
Since this appears to be created in C, the 10.c file has to be compiled for execution.
Once compiled, determine the switches and parameters required to execute the exploit.
At this point, it’s time to launch the exploit with the parameters to obtain a shell.
Yet another successful shell with root access.
Exploiting Apache:
Reviewing the findings from Nikto, it was determined that CVE-2002–0082 was present and it is exploitable to produce a remote shell. With that information, it is time to find additional information within searchsploit.
Using the -w switch produces hyperlinks to each of the exploits. Our focus will be on the link that contains 764. So, right-click the link and open it with a browser.
The browser connects to the Exploit Database site and launches the page that contains information about the exploit.
Clicking on the “green” hyperlink will open PaulSec’s Blog. Use this instruction set to modify the original 764.c file.
Paul notes to add or modify the following changes to the exploit file:
1. Add Headers
a. #include <openssl/rc4.h>
b. #include <openssl/md5.h>
2. Update the URL
a. Search for wget
b. Replace with 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.
After completing the steps from above, compile the new program using gcc.
Execute the program to determine the required switches and parameters.
The list of Supported Offset values is long. So, use the grep command with the Apache version to shorten the list.
Knowing that his is a Linux server, use the first hex value for RedHat Linux 7.2 and the IP Address of the Kioptrix system to launch the exploit.
Based on the above “Good Bye!” message, the first hex value failed to obtain a shell. Re-use the same command, but replace the first hex value with the second hex value and relaunch the exploit.
A successful shell. However, the whoami command reveals obtaining the apache user account. This is due to setting up Kioptrix in a Private Network versus a Bridged Network.
In order to obtain a root shell, the modified 764.c needs to be updated with a local URL on the Private Network. In addition, the ptrace-kmod.cfile needs to be downloaded and moved to the Kioptrix_1 directory. Also, a local Web Server is required when launching the exploit.
First, make a copy of the 764.c file and name if 764_local.c. This file will be modified with the local parameter change for the new exploit.
Once again, search for wget and replace the https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c with http://<Kali local IP>:8000/ptrace-kmod.c.
Recompile the modified 764_local.c file using gcc.
Within the Kioptrix_1 directory, use Python to launch the SimpleHTTPServer.
Execute the exploit with the second hex value obtained from above.
Once a successful connection has been established, the SimpleHTTPServer will log the connection.
Finally, a shell with root access.
Capturing the Flag:
Even though VulnHub notes that the flag is in email, I had been taught to issue a locate command for a possible file with the name flag in it.
Since the locate command did not yield much information, time to move on to see what /root provides.
Nothing exciting within /root. So, let’s review . bash_history.
Making progress. The mail commands look interesting.
The first pass through the mail turned up a lot of information. I did notice that the very first message contained a “U” in front of it. Meaning the message is not new or has not been read. Now that all the new messages have been read, I issued the mail command once again.
Looks like we have the flag within the mail message.
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 list.
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/dive.rule | hashcat -m 500 -w 3 -a 0 password.txt -o ~/KioprixPass.txt — session=Kioptrix_1
After an estimated ten minutes using the rockyou wordlist and the HastCat dive.rule, the following passwords were recovered.
