Rhino Security Labs

Pillaging AWS ECS Task Definitions for Hardcoded Secrets

April 21, 2020

Introduction: ECS Task Definitions in AWS Pentests

In performing AWS penetration tests, we’ve often identified sensitive information obtained from task definitions in AWS ECS — very similar to hardoded secrets in Lambda Functions and EC2 user data.  While these vulnerabilities have long been exploited in our own assessments, the continued growth of ECS moved us to build these attacks into Pacu and streamline the process.

 

In addition to this walkthrough, today we’re releasing two new Pacu modules — One to enumerate all ECS resources in a target AWS environment, the other to download ECS Task Definitions and extract hardcoded secrets.

These new modules can be found on the Pacu Github.

Background and Security: Managed Containers and ECS

Amazon Elastic Container Services or ECS, is an offering from Amazon Web Services (AWS) designed to provide a platform to host containerized applications in the cloud. ECS has two deployment methods, EC2 instance type and a serverless option, Fargate. Containers are spun up incredibly fast and the service makes running containers in the cloud very easy and pain free. Due to these aspects, it has been a popular service for developers looking to make use of containers to host their applications.

This image from AWS showcases the basic deployment model of ECS.

Vulnerable ECS Clusters, Services, and Task Definitions

ECS operates using the following three building blocks: Clusters, Services, and Task Definitions. 

Clusters are groups of containers that are running in the cloud. As previously mentioned, there are two launch types for containers, EC2 and Fargate. AWS defines the EC2 launch type as allowing customers “to run [their] containerized applications on a cluster of Amazon EC2 instances that [they] manage”. Fargate is similar and is defined as “[allowing] you to run your containerized applications without the need to provision and manage the backend infrastructure”. 

Services are the same regardless of the launch type chosen. Services are responsible for running tasks inside of clusters. Inside a service definition you define the number of tasks to run as well as general networking information such as VPC’s, subnets, and security groups.

Task Definitions are responsible for defining what containers will run and the various parameters that will be configured with the containers. These parameters include any references to secrets or environment variables the containers need to operate.

Sensitive Data In Task Definitions

Task definitions are responsible for configuring the actual containers that will be running in ECS. Since task definitions define how containers will run, a plethora of information can be found within.

 

For example, this AWS-provided sample task definition, stores the password of a MySQL database in an environment variable. Task definitions can also specify commands for containers to run on startup, these commands can potentially store plaintext passwords as a command line argument.

Pacu Module #1: ECS Service Enumeration

The ECS enum module, as the name suggests, enumerates the targeted environment for all the information on ECS. For example, this module will return information on the amount of clusters, containers, services, and the amount of task definitions in a target environment.

The module will enumerate all available regions if none are specified and utilizes the following API calls to obtain this information.

list-clusters
list-container-instances
list-services 
list-task-defintions

List of "ECS Enum" Module Commands

The output of the module looks like the following.

Pacu Module #2: ECS Task Definitions Download

The ECS enum task definitions module takes information from the ecs__enum module and uses it to grab the task definitions. The information pulled from this module is stored at the file path /sessions/<SESSION NAME>/downloads/ecs_task_def_data/ upon completion. The module works by taking the task definition ARNs previously obtained via ecs__enum and calls the ECS describe-instances command. This module will fetch all existing task definitions, including revisions of task definitions. This data is stored in JSON format which makes it easy to parse.

The above GIF shows how the module runs as well as some example output. The task definition shown in the output is one of AWS’s example task definitions. Within task definitions, the most important bits of information can be found in the command and environment sections. For example, commands can house information useful on an assessment such as passwords specified in a command line argument. 

Another useful, and probably the most common location to find sensitive information is in the environment section of the output.

In the example above, an environment variable named MYSQL_ROOT_PASSWORD has a hard coded value. Hard coded secrets in environment variables is a common issue in all AWS products that allow environment variables to be set. Again, even AWS’s own example task definition houses the password for a mysql root account in an environment variable.

Conclusion

In addition to EC2 user data and Lambda Functions, ECS task definitions can be a great place to pillage for hard coded secrets. These two modules are aimed to make the process of enumerating ECS simple for anyone looking to test resources in ECS. 

Pacu and the updated ECS modules can be downloaded from our GitHub here:  https://github.com/RhinoSecurityLabs/pacu.

Thanks for reading, check back frequently for more blogs posts, research, and tool releases. In the meantime, follow us on Twitter for news and updates: @RhinoSecurity, @nspagsws33