Attacking Docker Container hosted in AWS

tl;dr

In this post I will demonstrate how hacking in AWS could be performed. We will start our attack analyzing the Web Application. For the CTF-Players most of you will know this Web Application.

Overview

But step by step. At first a short overview of the attack path. To gain access to the AWS environment I uploaded a reverse shell build in php. After receiving the credentials from the EC2 Instance I iterated over the permissions and gained access to the ECR service. There I manipulated a docker image and uploaded it again with the goal to attack anyone who uses this container.

So I started by analyzing this web application. The name of the Application is DVWA (Damn Vulnerable Web Application) which is vulnerable to a lot of known attack techniques. For this purpose the used attack in the web application is not that important if we are able to execute commands on the victim machine at the end. In this case I exploited a vulnerable file upload functionality. The Web Application DVWA is deployed in an EC2 Instance. After analyzing the EC2 service a way to move lateral to the ECR service was found. In the private repository in this service I found an docker image, which I manipulated and overrode with a malicous image.

Remote Code Execution via File Upload

In this post I will exploit the File Upload functionality. I am personally a big fan of the PHP Shell developed by Ivan Sincek. Therefore, I use revshell.com to generate the necessary Reverse Shell in PHP.

After saving the file to my local kali I uploaded the php-file. In the easy mode of DVWA there are no restrictions we need to bypass. As I said it is not that important at this point.

The file was successfully uploaded. On our attacker machine, kali in my case, we need to open a reverse shell. If we go to the URL printed out by the Web App and have a open reverse shell listener we will receive a Shell Session as you can see below.

Credentials via Metadata Service

Short analysis, yes I am now inside a EC2-Instance. Therefore I tried to access the Meta Data Service. I tried it with a simple curl but no luck with this approach.

No worries we are not done yet :) Let’s try the Version 2 of the Meta data service.

This time was more successful. I received a valid token and are able to communicate to the EC2-Meta-Data Service. If we dig deeper in this this service we can access the /security-credentials of the IAM role used in the EC2-Instance called SecondTestDVWA.

Copy the received AWS credentials and evaluate what access we are able to access.

We can see that we are able to access the STS-AWS-Service which is a good sign. Now we need to analyse the access. We need to scan around an see if we are able to perform any kind of actions.

Lateral Movement to ECR

After a couple of tries I found out that we have access to the AWS ECR services. At this point we need to dig deeper. What can we do with that access?

I tried to list all of the private repositories in the ECR. For this action we can use the method describe-repositories. As a result we receive one entry. We can see the repositoryName and the repositoryUri. From now on things get wild. We need to analyse the found repository in more detail. We use the method describe-images to see what we will find there.

Hopefully the repository has some images we can access. Hold my beer, let’s see what we can do here. For the describe-images action we need the repository name from the previous commmand. As a result we found an image. But the information is not very helpful. Maybe we can download the image in the repository?

Docker Image Manipulation

But to do so we need to authenticate with the next command.

To make further analysis on the docker image we need to pull it first and then start it. Normally there is a awesome tool for this kind of attack I will show you in the next couple of steps but I could not manage to make it work. Am I stupid? Yeah probably but nevermind :D So the tool is not working, we need to analyse the procedure of the tool and find a way around. I stumpled a talk where this attack vector was explained. After some hours of research I tried to add a new ENTRYPOINT executing a Bash-Shell. Ok enough talking, I will show you how to.

We do have the docker image locally on our client. To manipulate the image we need a container ID. In order to get this ID we need to start the container from the image.

Please make sure that the container is still alive and we need to access the container via shell. This can be achieved while starting the container, but your container will stopp after you leave the shell. Therefore I start the container with the run command and do an docker exec –it afterwards.

After we successfully access the newly started container we add a Shell Script. The content of the Shell Script is a simple bash reverse shell for demonstration purpose.

sudo chmod +x shell.sh

Do not forget to add the executable flag for the shell.

Now here comes the magic. When a docker container is started and alive we can commit new layers to the docker image.

After we commited the changes to the docker image we can now push it back to our victim AWS Instance.

Damnit that shit really worked. Let’s imaging this docker image is part of an CI/CD pipelines which deployed new docker images everytime an image with the tag latest is uploaded?