I almost titled this blog something that would give away the exploit but then I realized someone might be passing by to get a hint.  Without giving away the privilege escalation -- the first time I used this exploit, I felt like a l33t h4xor.  I'm not.  I just felt like one because it's more than just compile, execute, root.  I've only used it a few times but I like it.  There's a quicker way to root this box but it's worth doing the longer way especially because it didn't go as planned and there's a slight modification that makes it work anyway.  

Continuing on with the Kioptrix Series, this is Kioptrix 1.3 (#4), the fourth from this author (group?).  This is a big jump up from the first three in terms of difficulty, IMO.

Staring off with an Nmap scan:





Scanning with Nikto:

Scanning with Gobuster:




Notice we have what appears to be two usernames, John & Robert.  Saving that for later.

Hitting the web port:






Wondering if we're dealing with MySQL:








We are dealing with MySQL and it looks like we're throwing some errors.  Continuing to poke at the inputs with different injection techniques:





Looks like we have some sort of mechanism in place to deal with injection.  I go hunting for:  checklogin.php and member.php at which point, I find login-example.php on GitHub:

https://github.com/AjeetK/login-example-php/blob/master/checklogin.php

Getting to the meat of the script:





Notice we're using stripslashes and mysql_real_escape_string.  

Depending on how things are built up, there can be any number of ways of injecting.  





One that isn't listed above that's been successful is just:  1 OR 1=1

In the case of Kioptrix 1.3, that was not what worked.

Poking at the injection point further with one of our usernames:





Attempting to use an injection technique from the list above...





We have a successful injection. 

Now going after the other user:





Attempting to login through SSH:





We're in but we're in some sort of jail.  Looks like our commands are limited which leaves us only one way out as far as I can tell.

Let's see what we're dealing with:





I already know this box is vulnerable to DirtyCow. 

I also know a few other things after running linux privilege escalation script:





In order to make this work, I need MySQL creds and I need MySQL running as root.

Looking for creds:





Looking for root:





gcc is not installed on this server.  I need to compile my exploit in advance of moving it over to the box:





I've wrapped it up in a neat little package and I'm going to pull it over to the server:





Note this box does not allow port 80 out which is why I'm going over 443.  Since my box has a self-signed cert, I'm adding the --no-check-certificate option.

In advance of going through this exploit process, I'm going to list out all of the commands so you can see everything at once in a tidy grouping:





Moving all of the files into /tmp:





Going through the steps listed above:








Take note of the line where the arrow points -- since we've already compiled this exploit elsewhere, this step isn't necessary.  But if you were to bring it over without compiling it, this step would be required.  Since gcc doesn't exist, this step does nothing.  

Breaking out into a shell to execute setuid:





#NoJoy



Should have worked but didn't.  Not going to twist around trying to make it work.  I have another route.

Heading back into MySQL and I'm going to use Python instead:










I create a setuid on Python and toss a reverse shell back to my c2 box:





I catch the shell, check my id, #root.  One last thing to do:





This was fun.  Lots of twists to work through.  Good lesson on some SQLi as well.  Thank you, loneferret!