DonkeyDocker: 1 is a relatively new CTF which appeared on VulnHub on April 22nd, 2017 by dhn. It can be found at https://www.vulnhub.com/entry/donkeydocker-1,189/

Let's start.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Booting the machine:

We can see that an IP 172.16.92.134 has been assigned to the target machine. As the attacking machine, I will be using Kali 2017.1.

The first step we will do is scan the target machine and see what information we can get:

As you can see, our result shows that it is a Linux based machine which has port 22 and port 80 open. As we all know that port 80 is usually responsible for running a web server (web application), so let's head there and see what we get:

The Web application does not tell us much so the next logical step is to check the source code of all the three pages and look for some hints. Unfortunately, even the source code of the pages does not help us.

Since a web application is running, we can use dirbuster to look for more links that we cannot confirm otherwise.

Here we come across a really interesting discovery /mailer/examples. So we head towards http://172.16.92.134/mailer/examples/ and find the following:

We now know that PHPMailer is running on the server. The first link we come across on the page is for PHPMailer's GitHub repository: https://github.com/PHPMailer/PHPMailer

Over there we can see that it contains a file called VERSION that might be able to tell us the version of PHPMailer that the machine is currently running:

As we can see, the version of PHPMailer is 5.2.16. A simple google search shows us that PHPMailer 5.2.16 is vulnerable to Remote Code Execution (CVE-2016-10033). Let's search for an exploit on our machine first:

Here, we can see that 40974.py might be able to help us out. However, before we could use this exploit, some changes would definitely be required. Let's head over to the exploit and see what all changes are required. After examining the exploit, the changes required are really minor. If we just change the TARGET IP (marked in red) and the ATTACKERS IP (marked in yellow), we should be able to use this:

Note: The local port (marked in blue) is optional to edit. Furthermore, an initial research showed us that due to a .htaccess file on the server, all .php are redirected. For e.g.: http://172.16.92.134/contact.php is redirected to http://172.16.92.134/contact

Now we will start our listener on port 4444:

Don't forget to change the port here if you changed it in the exploit. Moreover, now we are ready to run our exploit, but before we do that, the code tells us that we need to install requests_toolbelt. We can do that with the following command:

$ pip2 install requests_toolbelt

Now simply run the exploit by:

$ python 40974.py

Now by simply visiting http://172.16.92.134/backdoor.php we will be able to activate our listener:

There you have it! Let's get an extended shell and see what all is present in the machine:

$ python -c 'import pty; pty.spawn("/bin/bash")'

In / we find a really interesting file called main.sh. From the looks of it, it seems that we are in a container and there's a user called Smith. We can also see that our first flag is present in /home/smith/ but we would require smith's permission to enter there.

By making a simple guessing attack, we found that smith's password is Smith:

Now we have captured our first flag:

However, that is not it. We have to look deeper, says the flag.txt

Let's see if we can find some keys for the user Smith:

It seems that we have found ssh key for orwell@donkeydocker. Let's see if we can use this:

Voila! We are in! A simple ls -a command also showed us another flag:

However, we are still not the root users:

Let's go back to main.sh that we found earlier and see if we can get any hint. When you see how it is handling the flag.txt, it will not be the worst idea to remove the file flag.txt and replace it with a symlink to /, etc./passwd and /, etc./shadow

We can do this with the following commands:

$ mv flag.txt symlink.txt

$ ln -s /etc/passwd ./flag.txt

Now a simple Docker restart from our ssh session should put things in order:

We have successfully restarted the container. However, we are now disconnected from the reverse shell. Let's reconnect and see if it worked or not:

Now let's add ourselves into the file to gain root!

Time to update /etc/shadow

$ rm flag.txt

$ ln -s /etc/shadow flag.txt

Now let's see if we can create a new user hacker

Note: After our second symlink was completed, I printed out the contents of flag.txt, which in this case were content for /, etc./shadow and copied the password and permission part and changed the username to the hacker. Hence, we were able to add with the same syntax and using password Smith for username hacker.

Even though we have root, there was no flag.txt to be found, so we head back to the ssh terminal.

This is where things went haywire. After doing some research, I came across the following article: https://reventlov.com/advisories/using-the-docker-command-to-root-the-host along with https://github.com/chrisfosterelli/dockerrootplease

Using this, I ran the following commands in /home/orwell

$ mkdir chiragh

$ cd chiragh

$ cat > Dockerfile

FROM debian:wheezy

ENV WORKDIR /stuff

RUN mkdir -p $WORKDIR

VOLUME [ $WORKDIR ]

WORKDIR $WORKDIR

$ docker build -t chiragh-docker-image .

Note: The filename has to be Dockerfile and won't work with anything else

Now run the following command to check if this worked or not:

$ docker run -v /root:/stuff -t chiragh-docker-image /bin/sh -c 'id'

And finally we can see our flag.txt:

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Note: All unix commands should run as: $ docker run -v /root:/stuff -t chiragh-docker-image /bin/sh -c '<command>'