DonkeyDocker 1 – Walkthrough
CTF Challenge attempted – https://www.vulnhub.com/entry/donkeydocker-1,189/
Tip I found from the setup – if VMWare offers to upgrade the DonkeyDocker image, don’t do it. I did on mine & it broke the IP connectivity from Kali.
This is my first attempt at a CTF, so was an enjoyable learning exercise. I’ve loosely grouped the steps taken below into Reconnaissance & Scanning, Access & Escalation and Exfiltration.
Useful things I learnt along the way:
- Try simple things first before going with the complicated (i.e. try and guess passwords)
- Document as you go, it saves having to retrospectively write up what you have done
Reconnaissance & Scanning
First up let’s go and find the host.
Extra virtual machines filtered out – so we know the target host is at 192.168.195.134. Now let’s see what’s running.
Okay so we have a SSH & web service running.
First step let’s see what SSH tells us
So there will be no brute force guessing the password – the image is looking for a saved ssh key to login.
Next let’s pickup the robots.txt and see what the webserver has to tell us.
Looking at the website, we have a fairly basic home page (index.php), an about page that returns an error and a contact form that looks interesting.
A search of vulnerabilities on Apache 2.4.10 & OpenSSH doesn’t reveal an easy way in, so on with more scanning. For the next stage I tried dirb to see what else was on the website.
Loading up /mailer/examples/index.html reveals an installed instance of PHPMailer. Based off reviewing the GitHub page for PHPMailer – I know the version number should be stored at /mailer/VERSION. Checking this reveals we are running version 5.2.16.
Doing a quick search leads me to CVE-2016-10033 & https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10033-Vuln.html. Remote code execution in PHPMailer versions under 5.2.18 – looks like our way in.
Access & Escalation
From the above link I downloaded a copy of PwnScriptum_RCE_exploit.py, running it yields:
Viewing the source of http://192.168.195.134/contact gives me the input fields I need:
Now to run the script:
And we have a shell 🙂
Now we are in, let’s have a little poke around
Conclusions taken so far are:
- We appear to be operating inside a docker container. There is a .dockerenv file in the root directory, there is no sshd_config file (but the service is running on the host) & the name of the challenge kinda gives it away
- There is a user named smith
- The first flag appears to be in the users home directory
Onwards to try and guess a few passwords.
Su doesn’t seem to like the terminal www-data is running in, let’s try and spawn a new shell.
First guess worked, now let’s see what’s in the users home directory.
And flag # 1 captured. The message confirms I’m running in a docker container, so need to look deeper. Emphasis is also on the name orwell.
Onwards to dig deeper:
Hmmm, ssh keys (including the name orwell). Let’s pickup a copy of these.
Okay, so smith cannot write files to the /www/mailer directory, back to our www-data user
Now to pick the private key up off my kali image and see if logging in via ssh works (noted earlier that ssh into the main vm seems to only expect a key, no password)
Now to see if the key lets us in
And we are in – now to have a small poke around.
The second flag is now ours – of more interest we also appear to be part of the docker group. Off to do some more research. The main link I’ve found of use is https://docs.docker.com/engine/reference/commandline/cli/
From this I can the user orwell can indeed run docker commands, there is one container running (donkeydocker) and two images available.
Further research reveals (https://reventlov.com/advisories/using-the-docker-command-to-root-the-host). From this I see a user with docker permissions (orwell) can use docker to run commands as root. Tinkering with some commands we now have:
Third (and hopefully last) flag found 🙂