VulnHub - Kioptrix 3
by purpl3f0x
Here we are with Kioptrix level 3! This one was significantly more challenging than the last two if you exploited it manually, but there were some ways to automate the process to get the initial foothold to make things easier.
Recon and initial enumeration:
This one is going to be pretty straight-forward, clearly we're meant to exploit whatever is running on this web server. Per the suggestion made by the box maker, I updated my attack machine's hosts file to add an entry for "kioptrix3.com" and pointed it to the IP address that it got via DHCP.
I figured combing over Nikto would be a good idea since this is going to be purely web application hacking, but the only thing I really see here that caught my attention was "phpmyadmin". It's an application that streamlines managing instances of MySQL on the server, and is usually a vulnerable attack vector.
I spent maybe an hour or so trying to exploit it, but the exploits I used weren't working. I tried manual exploitation with a bash script, a Perl script, and Metasploit, but none of them seemed to work. The version number should have been vulnerable, but none of them really did anything, so it was time to poke around the server.
The main page was an uninteresting blog that was advertising a gallery but first I visited the tab that said "Login".
I found this login and tried the usual SQL injection attacks, but nothing worked, so I gave up on that after about 5 minutes to avoid "going down the rabbit hole".
I decided to check out the gallery, and for the longest time, I didn't see anything interesting. Finally, I found that if you played around with the "Sorting Options" menu, the URL would change to something that looked like it was SQL injectable:
Whenver I see a ? followed by some parameter and a number, that always raises an eyebrow. So I deliberately broke the URL to see what would happen:
By adding a single quot ( ' ) after the 1, I broke the SQL statement, which resulted in a verbose error message that should never appear. Blind SQL injection is one thing, but "error-based enumeration" is much easier if the server is misconfigured to spit out error messages like this.
Manual SQL Injection:
So now we need to enumerate the database, but first, we need to see if there are fields on this form that will print out info:
This is sort of a blind attack, because you have to keep adding numbers to the end of this SQL statement until it starts producing results. This web app wouldn't display anything if I used less than 6 fields.
Now that I know I can print things to fields 2 and 3, it's time to see how much information we can get.
By removing the "2" and replacing it with "@@version", we got the MySQL server to tell us which version it is. This is less about looking for an exploit, and more about just making sure I'm using the correct syntax. This technique also works if you put in "version()".
I was curious about which user the MySQL server was running as, so I replaced "@@version" with "user()"
Again, a fatal misconfiguration. Never ever ever ever run your SQL server as root!
At this point I had run out of ideas for what I could inject into the server, so some quick googling was in order, and I turned up a very good cheat-sheet for MySQL:
https://www.perspectiverisk.com/mysql-sql-injection-practical-cheat-sheet/
I figured the best place to start was enumerating the tables in the database that was in use, but first I had to get the database name:
By using "database()", I instructed the server to tell me which database was currently in use by this web app. Armed with this information, I can proceed to getting the tables:
There were many tables of course, but the first table on the list was the most interesting. The next move was to enumerate this table to see if it really did have what I wanted, in the form of enumerating the "columns":
This looks very promising. So now, naturally, I want to dump what's in these columns.
Perfect, we have what looks like hashed passwords, and some usernames. At first glance, I assumed they were MD5 sums, but Kali has a tool to identify hashes.
So, as I thought, these are most likely MD5 hashes, which are pretty easily cracked.
I could always fire up hashcat, but since hash-cracking on a VM can be slow, and I didn't want to copy the hashes to a physical machine with a GPU, I looked up a simple online MD5 cracker. It's worth trying if you don't want to sit around waiting for simple hashes to be cracked.
So the cleartext password for user "loneferret" is "starwars". Something that probably could have been guessed.
I tried this password on the "login" page on the main site, as well as phpMyadmin, but they didn't work. I was confused for a moment but then remembered that SSH was open. Sure enough, this password logged me into the server as "loneferret".
Privilege Escalation:
I landed in loneferret's home directory, and did an immediate "ls" to see what we had to work with:
I looked at the checksec.sh, but it was very long and complex. Didn't look like something that the maker of the box wrote, it was something aquired online. I didn't really know what to do with it, so I read the README file:
So we're basically being told exactly how we're going to get root here. This user has the ability to use "ht" as root, whatever that is. The program that opened up when using this command was very unfamiliar to me, so I had to look it up a bit. Ht is just a file/text editor that has a slight "gui" feel to it, despite being a terminal application. That being the case, I knew that we could edit any file owned by root. So I decided to go the route of editing the "sudoers" file:
It took a while to figure out but in order to invoke the "File" option, I had to hold Alt and press F.
I modified the sudoers file to give loneferret the ability to run /bin/sh as root. I hit Alt+F again, clicked "Save", closed out ht, and proceeded to run "sudo /bin/sh -i"
Easy root. A brief search of root's directory revealed the "flag":
Bonus: Automated SQL Injection
All of the work we did compromising those passwords can be done all with a single tool, "SQLMap". SQLMap is a tool that can automate enumerating, and then exploiting, web apps vulnerable to SQLi.
To get started, you invoke it by name, and provide the URL with the "-u" option. To specify which syntax to use, we provide the "--dbms=mysql" parameter. With the "--dump" option, we tell it to start dumping EVERYTHING it finds, which can be very very verbose. The "--threads" option tells it how many threads to open up to the web app. The more threads, the faster we get results, but having too many threads could overload the target.
After a while of churning through I saw the above. Looks familiar right? Well looks like SQLMap will even crack the hashes for us if we want it to. So I say "Y"
And all that work we did manually was completed in about 60 seconds.
Summary:
Kioptrix 3 was challenging enough to give me a headache and make me pace around several times throughout the night, but it wasn't so hard that it was discouraging. It was a nice chance to practice SQL injection, which I prefer to do anyway. SQLMap makes everything quick and easy, but I'm currently studying for the OSCP exam, and SQLMap is forbidden on the exam.
The priv esc was very obvious and straight-forward, and taught the lesson that you have to be very careful about what programs you allow a user to run as root with sudo.
Kioptrix 4 soon!
tags: Pentesting - VulnHub