Kioptrix 2 VM Writeup
Hey everyone, I have decided to start doing some writeups on vulnerable VMs and retired HTB(HackTheBox) systems in my spare time. I will try to keep my usage of Metasploit to a minimum in my walkthroughs so I can show you how to manually exploit systems. I have nothing against Metasploit, it is an awesome tool and you should definitely know how to use it but at the same time there are instances where it will not be an option. This writeup will cover one of the Kioptrix series systems from VulnHub. These systems are typically a good start for beginners. So let's jump right into it!
I start with an nmap scan as always and since this is a VM and not a live test, why not start off with the loudest scan possible?
My scan reveals a few open ports, the most interesting of them being my favorite port. Port 80 :) Browsing to the server reveals a login page, lets see how resilient this thing is.
The old admin:admin doesn't work but if we try a simple SQLi by entering admin and aaa' or 1=1 # as the password.....
BOOM! We got admin access. Let's see if we can ping our Kali system.
Ok, so we know now that the server is accepting commands and executing them. Let's see what other commands we can run.
Next we will try to execute the following reverse shell command on the server:
After opening a listener with netcat and running the command chain, we get a reverse shell \o/.
Now as you can see, the server is telling us that we have no job control. Not a big deal, there just so happens to be a command that I keep handy for this exact situation.
python -c 'import pty;pty.spawn("/bin/sh")'
Keep in mind that obviously python has to be installed on the server for this method to work.
Now that we have a more functional shell, I run a couple of preliminary commands to do some quick basic enumeration. The "uname -a" command presents me with what appears to be my avenue to escalating privileges on the server. Now you may be wondering how I am able to recognize a vulnerability from this ouput. The answer is that I have been doing this for awhile and have encountered many exploits for the 2.6.x kernel.
A quick Google search turns up an exploit that looks promising. I could have also used searchsploit here but there are a ton of exploits for this kernel version and I wanted to keep it simple.
Since this exploit is on exploitdb, that means that it is already on our Kali system. So there is no need to download it. Using some bash job control wizardry, we can background our current shell, switch to the directory where the exploit is located, start up a python server and background the process. I discuss this technique in further depth in another article that I wrote. Which can be found here:
https://www.garudax.id/pulse/utilizing-bash-job-control-upgrade-shell-chris-risley-oscp/
Also I could have just added a "&" to the end of my python server command to run it in the background from the start but I wanted to showcase this technique and how useful it can be.
Now that I have my server running, I foreground my shell and move to a directory that I will be able to write to. I choose /dev/shm because it is virtual memory and doesn't persist to disk. Once in the /dev/shm directory, I use "wget" to pull down my exploit from my Kali system.
With the exploit on the target server, I use "gcc" to compile it and run it. Pwnd.
Something to note here is the reason why I compile the exploit on the target server and not my Kali system. The reason for this is to avoid issues that will occur if there is a difference in architectures between the two systems. Now if I was not able to compile on the target server here, I would have just compiled it on one of my exploit development systems but that is something that I will discuss in a future article.
That's all I have for today folks! I hope that you found this useful and an enjoyable read. I'll try to get another walkthrough or tutorial up within the next few days.