Pentester Academy: Weakest Link

Pentester Academy provided a challenge to do a write-up of their container breakout challenge: “Weakest Link”. Link can be found here: https://attackdefense.pentesteracademy.com/challengedetails?cid=1415. This challenge is an example of a container manager that uses weak credentials that allows the exploiter to gain access to the root/host operating system. The scenario is based on a brute-force attack has revealed credentials to a default Portainer instance. Here goes:

Initial login

The login provides the portainer.io panel that allows for the management of containers. Looking at what is pre-built, there is a container running for me that exposes ports 8000 and 9000. We can see it runs on IP address 172.17.0.2

Containers Available

I usually check the “Inspect” tab to see what it took to start up this container, and you’ll see some juicy stuff in there like hard-coded parameters. However, it appears in this instance that there isn’t much to exploit. Looking at the Mount points, there are a few mounting points that are being used here. If we could start up our own container and mount those points with elevated privileges, that would be handy! Let’s try. Let’s add a container and see what we can do with it.

Adding the root to the container

So we can add to the container any path on the host OS, so how about we just add “/”? Also, I’ll go to the “Runtime & Resources” tab and select “priviledged” to ensure we get all the permissions we can. Now I hit “deploy container” and it builds it. Now on the container just click “Console” and then “Connect” and see what you get. And voila!

Showing both systems access

As you can see, we get the other OS mounted into our container (with root privileges). We can see the difference by running a simple “hostname” printout and confirming they are two different files. So we can do plenty of malicious things from here, but the goal as to get a flag so here it is:

Grabbing the flag from the host file system

So in summary, this machine was able to be exploited by quite a few things that went wrong:

1. A weak credential being used on the Portainer GUI
2. No protections for brute-force dictionary attacks
3. No restrictions to access resources on the host machine
4. No logging or monitoring to find this abusive behavior

These are quite common findings in smaller organizations and start-ups. Just a few misconfigurations and the unethical hacker is off and running!