AWS Fargate’s role-based STS Tokens, from a security perspective (Part 1 of 3)

This is part 1 of 3

/0 Intro:

I decided to give ECS-Exec on Fargate a try, to better understand how it works. Once a shell was spawned, I switched hats to explore what we can do from an attacker/redteamer perspective, in order to have a good clarity and awareness of the security risks involved. This article/lab guides us through that process, with a conclusion on the security implications of ECS-Exec as well as the STS tokens obtained from the EC*/EKS ecosystem (EC2, ECS-EC2, ECS-Fargate, EKS, etc), or, through a shell obtained via other means.

I will be using Kali 2021.1 for the entire lab.

/1 Quick notes on ECS-Exec:

Released around Q1 2021, it allows to run commands directly in a Fargate container. One neat thing about ECS-Exec is the ability to provide the permission to use it purely via IAM (ecs:ExecuteCommand) to specific engineers, for a specific cluster Task, while having the full audit capabilities of S3 and CloudWatch Log events (down to the commands executed inside the container). Cloudtrail remains a necessary and available option, just not as detailed as the previous two.

With all that said, assigning an IAM “Task Role” under the Fargate cluster Task Definition will essentially control what the Fargate tasks, and therefore containers, will be able to do with other AWS services, once they have been promoted to a running state.

/2 Prerequisites for the lab: 3 total Steps

Step 1) Having a Fargate Cluster up and running:

We gonna cover 2 different methods, the long and the quick way. The choice is yours, only one of them is necessary.

• Method 1 — The Long Way: Semi-Scripted-install

This takes quiet a bit of time in configuration and execution, but it is rewarding in that you will learn every step of running a Fargate cluster. I would suggest the following resources (thanks to the author for the good How-To):

https://github.com/moinuddin14/ECS-Exec + https://www.youtube.com/watch?v=IljEeCC0RFg&t=1943s

Fore more info: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html

• Method 2 — The Easy way: AWS Copilot

First, we will install docker on our system (using, for example: https://phoenixnap.com/kb/how-to-install-docker-on-ubuntu-18-04) and execute the following to make sure docker is up and running:

$ sudo systemctl start docker

Next, we will install AWS copilot:

$ curl -Lo copilot https://github.com/aws/copilot-cli/releases/latest/download/copilot-linux && chmod +x copilot && sudo mv copilot /usr/bin/copilot 
$ cd ~ && mkdir copilot-lab && cd copilot-lab && git clone git@github.com:aws-samples/aws-copilot-sample-service.git demo-app && cd demo-app

Then, we will run the following to install a simple Fargate cluster, with all the necessary stuff:

$ copilot init --app demo \
 --name demo-linkedin-exec \
 --type 'Load Balanced Web Service' \
 --dockerfile './Dockerfile' \
 --port 80 \
 --deploy

Step 2) Installing the Session-Manager plugin

Please note that this is not part of the aws-cli-v2, which I assume is already installed. If it is not, I cover installing the aws-cli-v2 in part 2 of the article (the same commands will therefore apply on your host machine).

$ sudo curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb" -o "session-manager-plugin.deb"
$ sudo dpkg -i session-manager-plugin.deb

$ sudo session-manager-plugin

For more info: https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html

Step 3) Getting an ECS-Exec shell

Let’s start by getting a bash shell on the Fargate Container:

If you went with method 1, let’s run the following command:

$ sudo aws ecs execute-command \
     --region ca-central-1 \
     --cluster <name_of_fargate_cluster> \
     --task <task_id> \
     --container <name_of_container> \
     --interactive \
     --command "/bin/bash"

Alternatively, if you used method 2 (copilot), we can run the following:

$ sudo copilot svc exec -a demo --env test -c /bin/bash

/3 Fargate Task Role policies

In order for the lab (in part 2) to work properly, we would need to attach some policies to the “Task Role” of the Fargate Cluster. This depends on which method was used to create the cluster, but it should be along these lines:

• If Method 1 was used, the Task Role name should be: ecs-exec-demo-task-role
• However if method 2 (copilot) was used, it would be: demo-test-demo-linkedin-exec-TaskRole-some_random_chars
• Important note for Method 2: remove the inline policy DenyIAMExceptTaggedRoles from the “demo-test-demo-linkedin-exec-TaskRole-some-random-stuff” role

Here are the AWS-Managed policies that need to be attached to the Cluster’s Task Role (Method 1 and/or 2):

ReadOnlyAccess
SecurityAudit
AmazonSSMFullAccess

At this point, we are ready to roll.

This is the end of part 1. Part 2 is found here