VulnHub - Kioptrix 4
by purpl3f0x
Now it's time for the next pentest challenge in this series, Kioptrix 4!
Recon and enumeration:
As always we start with an nmap scan, courtesy of my favorite enum tool Sparta, and can see some pretty common ports open, SSH, web, and SMB. I always like to check out SMB when I see it, because shares with poorly configured permissions are often something that can either expose sensitive information or could otherwise be leveraged for dropping files on the target.
Doesn't look like there's much here to really go after. The shares here are default shares that usually can't be read and don't have anything in them. The nmap scan from before didn't really turn up the exact version, so I decided to grab the full version with metasploit, since my version of smbclient doesn't seem to enumerate versions anymore.
With the version enumerated now, I of course look to see if there are any exploits for this version of Samba:
Doesn't look like there are any exploits for this exact version of Samba, so I'm not going to pursue this. Next step is to check out the web page.
A login page. I want to try a SQLi login bypass here but while I play with that, I get a gobuster scan going to see if there are any directories hidden.
Only a few results. There's nothing of interest in /images, /index is just the login page, /logout is self-explanitory. So I check out john and robert. They are directories that contain php scripts that just take me back to the login page if I click on them, and the source code as visible in the browser is just the login page code. So I go back to trying SQLi.
So trying the SQLi in both the username and password fields reveals that the user field has a form for santization by escaping single quotes. Leaving this syntax in the password field, I try a few more usernames:
Logging in as John:
There we go, we have a password for robert. Not sure why loggin in as John didn't yield anything. So at first glance, this password looks like it is Base64 encoded because of the two '=' on the end, which is common for Base64-encoded strings.
Or........maybe not. To rule out improper padding, I tried decoding it again with no =, one =, and three =, but nothing worked. So, taking a wild guess, I use this password to SSH into the box.
And it works without any form of decoding. I guess the two = were put on the end to fool us, maybe.
Privilege Escalation:
So, looking closer at the login prompt that we landed in, it's obvious that we're stuck in a limited shell. I neglected to take a screenshot, but the only commands permitted were cd, echo, ll, lpath, ls, and help. Trying to chain commands with &&, ||, or ; resulted in "forbidden syntax" warnings, stating that 2 more violations would result in being kicked. Exceeding the warning limit results in the SSH session being terminated. It took me a while to figure out exactly how to escape this shell, but ultimately it was pretty simple.
By typing "help help" it finally told me what type of shell it was. With this, I was able to research ways to escape "lshell" and quickly found my way out:
https://www.aldeid.com/wiki/Lshell
Free of the limited shell, it's time to start doing the post-exploitation recon to find a way to get to root. First I checked the processes running as root:
Right away I see a very tempting attack vector; MySQL is running as root. But I don't have any way to login right now.
Thinking back to what I found on the web page, I decide to poke around in the www directory. Usually if a web application needs to connect to MySQL, there will be some PHP code that will login, and the username and password will be in that PHP file. We can't see this on the webpage because the server is executing the PHP code and won't show it in the browser when using "inspect element" or "show page source".
It didn't take long to find the file, and it was the "robert.php" file. The MySQL server root account doesn't have a password. This is a huge security flaw, because the MySQL server is actually capable of executing system commands, and since the SQL server is running as root, those commands are run as root.
Logging into the server is done from the terminal, with this command:
Even though the -p option is being provided, you don't put the password in on this line, you press enter, at which point the server will ask for a password. I just press enter again, since there is no password, and I'm logged into the database. I run a few commands to check if I an execute commands as root.
Odd. The server is running as the root account, but it's running shell commands as robert. I'm a bit confused, I really don't know what's going on. So it's back to researching. I search using terms along the lines of "exploiting mysql running as root". I found a suggestion to use a completely different command, "sys_exec()". I decide to test if this will really execute commands:
I decided to use 'touch' to see if I could make a file, and it allowed me to do so. What I should have done to check afterwards was "ls -la" to see who owned the file, and confirm that root owned it. Regardless, I moved on:
The command above is adding robert to the admin group. This doesn't make robert a "root" user, but it does allow robert to run any command as root with "sudo".
Just like that, we won, we have root! A quick look into the root directory reveals the "flag":
Summary:
This one wasn't too hard, it encouraged some web directory enumeration, and explored how you can use processes running as root to gain administrative privileges. To be honest, I felt that Kioptrix 3 was harder, mostly because I was rusty on how to conduct SQLi, as well as identifying vulnerable urls/pages. There's only one more left in the Kioptrix series, and I'll be tackling that one very soon~
tags: Pentesting - VulnHub