Kioptrix #1
Kioptrix is an ‘easy’ machine. There are vulnerabilities galore and exploits already created for those vulnerabilities. Let’s dig in.
First things first, download the VM and load it into your VM software — I use Virtualbox. Once mounted, you should have settings similar to these:
Once you are done with the set up, go ahead and start it. You may have to change some of the configuartion settings but it is a very straightforward start up process. When it’s done booting up, you should have a screen like this:
Now we can start our Kali instance. I have my VMs configured to the NatNetwork option in Virtualbox. The IP addresses are decided by DHCP so we don’t necessarily know what IP address the vulnerable machines are running on, but if I know the IP address of the Kali machine I will know it’s on the same network. We should be aiming for the 10.0.0.0/24 subnet.
We can use Nmap to scan the local subnet and discover any hosts that are running. Since only Kali and the Kioptrix are running on this network, they should be the only two hosts up. After running the scan, nmap reports two hosts available. 10.0.0.4 is Kali. This must mean that the Vulnerable Kioptrix machine is 10.0.0.11.
The preliminary scan showed 6 ports open on the vulnerable machine. We’ll do a more in depth scan and confirm some of the services. Right now we aren’t focused on stealth. We’re trying to see how and where to make our entry point to the machine. What catches my eye here is that port 139 is open, often times this is an easily exploitable port if it is configured incorrectly.
The full report takes much longer, but provides much more granular detail. Here we can see that this machine is running SSH (port 20), an Apache Web Services (ports 80 and 443), RPC Service (ports 111 and 32768), and Samba (port 139). We can also tell that this is a Red Hat linux box.
For full scans I almost always use the same parameters:
- -A provides adds OS detection, version detection, script scanning, and traceroute.
- -p- scans all 65,535 ports
- -T4 sets the speed at 4 (out of 5)
Since there is a webserver running, we should check that out first. We’ll set firefox to look at the IP address of the vulnerable machine:
A test page is not necessarily a vulnerability, but it does speak to the security hygiene of the box. If they left a test page open, what else might they have? Default credentials? Default file paths? I always make a habit of checking the source code for these types of machines, sometimes the creators will leave helpful hints. Unfortunately not in this case, that too was left as default. No additional information was disclosed. I was hoping for a login page of some kind but I was not finding anything particularly useful, it was time to move from the website being served and look back at the webserver and continue enumerating.
Our Nmap scan revealed Apache 1.3.20 as the version running. Searching for this, I found it is a significantly outdated software version and the current version is somewhere around 2.4.46 (as of November 2020). This may be a good place to explore further, something that far out of date would almost certainly have a large number of exploits available.
As I continued to enumerate I found the OpenSSL 2.8.4 is not only outdated, but has a known vulnerability which allows for Remote Code Execution by way of a buffer overflow — an easy win. Looking at the exploit I found it was outdated unfortunately, but some nice soul has brought it up to date and created a github for it and given it a very clever name.
Installing the script is straightforward thanks to the person that updated it. Follow the instructions from the git hub or look at the screenshots below.
When I install or download new repos from github I almost always change directories to be in the /opt/ folder and start the clone there.
Running the application without any arguments provides a list of the vulnerable systems and the associated memory block that will be used to complete the exploit. Since this is a buffer exploit it’s important to have the right version loaded. For this machine, we don’t know exactly what OS version that is being used but we did gather it is a Red-Hat version higher than 6.2. The Nmap scan confirmed a Red-Hat OS and the website test page included verbiage indicating that the current version could have been upgraded from 6.2 or earlier. If we grep the results of the application with the Apache version we know is being used and combine that with some of that information we’ve gathered, we should be able to try this exploit and see if it works.
For this exploit to work we should try 0x6a and 0x6b since those are the only Redhat versions for Apache 1.3.20.
Using the input parameter 0x6a, I ran the script and it attempted to connect but it doesn’t seem to respond. I tried a few times but it wasn’t able to work. No shell was spawned. We should try again using 0x6b.
After a few unsuccessful attempts I was able to successfully spawn a shell. Surprisingly, this exploit provides full root access immediately and no privilege escalation was necessary.
However, escaping the TTY shell with echo os.system(‘/bin/bash’) caused the shell to drop down to the apache user. A lesson that the shells gained from an exploit which was temperamental to start will not be terribly reliable. You might need to retry the exploit again if the shell drops for any reason. However, with this it’s safe to say we have rooted this machine and it is now ours. We could load malicious websites, change the root password, delete system files, and more.
To avoid this kind of exploit, updating to more recent software would eliminate the buffer exploit. The versions provided in the exploit we found were numerous, but if we can upgrade our OS or the server version either would eliminate the exploit from occurring.
