Why you need to update your risky default EMR managed roles and policies

Amazon EMR is a managed cluster platform that simplifies running big data frameworks such as Apache Hadoop and Apache Spark. EMR’s service allows a cluster to be launched in just a few minutes without the worry of node provisioning, resizing, scaling, or replacing poor functioning instances – EMR does it all for us.

In this blog we will examine EMR’s default roles and managed policies to understand if they follow security best practices of least privileges. When Amazon launched EMR they provided default managed policies and roles that can be attached to IAM roles, users, or EMR services. The V1 default managed policies and roles are risky as they provided a wide set of permissions across several other AWS services such as S3 and DynamoDB. Amazon EMR will be deprecating existing managed policies (V1 policies) in favor of new managed policies (V2 policies). The new managed policies have been scoped-down to align with AWS best practices. After the existing V1 managed policies will be deprecated (no estimated date as of yet), it will not be possible to attach these policies to any new IAM roles or users.

Existing roles and users that use deprecated policies will be able to continue to use them. Therefore, if you created an EMR cluster using the V1 managed roles and policies, it is important to take action and change them to secure your environment.

EMR clusters are a collection of EC2 instances, where each instance is called a node. There are three types of nodes:

• Master node: A node that manages the cluster. It tracks the status of jobs submitted to the cluster and monitors the health of the instance groups.
• Core node: A node with software components that runs tasks and stores data in the Hadoop Distributed File System (HDFS).
• Task node: A node with software components that only runs tasks and does not store data in HDFS. Task nodes add power to perform parallel computation tasks on data.

A cluster includes one master node (with Amazon EMR 5.23.0 and later, it is possible to launch a cluster with three master nodes to support high availability of applications). Core/Task nodes are not mandatory but if chosen, can be one or more (for each type). Below is a diagram of Amazon EMR’s cluster infrastructure showing one master node, two core nodes, and one task node.

EMR Network:

When creating a cluster it is possible to choose between custom security groups that already exist and are managed by your administrator or to choose the default managed security groups provided by Amazon:

• ElasticMapReduce-master – The default managed security group for the master instance in public subnets.
• ElasticMapReduce-slave – The default managed security group for core and task instances in public subnets.

As with any other EC2 instance, the preferred way to connect to the machines is via SSH. Today, the default inbound rules in the security groups do not allow SSH access from public IP address. But, until December 2020, Amazon had a pre-configured rule in “ElasticMapReduce-master” security group that allowed inbound traffic on Port 22 from all sources (0.0.0.0/0). This configuration is dangerous as it allows anyone SSH access to the instances from any IP with no restrictions. Amazon strongly recommends that you remove this inbound rule and restrict traffic to trusted sources.

EMR Identities:

When a user creates an EMR cluster there is an option to add two IAM Roles: EC2 instance profile and EMR role.

EMR role:

An EMR role defines the allowable actions for EMR when provisioning resources and performing service-level tasks that are not performed in the context of EC2 instances. This role allows EMR to call other AWS services on our behalf when provisioning resources and performing service-level actions.

EC2 instance profile:

As mentioned above, an EMR cluster is a collection of EC2 instances. Each instance in the cluster is called a node. An EC2 instance profile is assigned to every EC2 instance in the EMR cluster when the instances are launched and the roles that are attached allows applications running on an EMR cluster to access other AWS resources, such as Amazon S3. For example, if you run Apache Spark jobs that process data from Amazon S3, the policy needs to allow access to such resources.

Amazon has a V1 default managed role that can be attached to each one of these roles. The V1 managed role for EMR role is EMR_DefaultRole, and the V1 managed role for EC2 instance profile is EMR_EC2_DefaultRole.

Note: The V1 managed roles can still be attached as they are not yet deprecated.

EMR_DefaultRole (V1):

This role is using a policy called “AmazonElasticMapReduceRole” which is a managed policy that will be deprecated in the future. The first thing to note about this policy is that the resource is set to: “*” which means that the listed actions are applied to any resource in the account.

The role is used for creating the cluster, therefore many of the actions that are listed in the policy are related to EMR actions, but there are also actions such as “s3:Get*” or “sqs:Delete*” that allows access to any data from any bucket in the account or to delete any queue/messages from SQS.

Part of ‘AmazonElasticMapReduceforEC2Role’ policy (V1 policy)

EMR_EC2_DefaultRole (V1):

EMR_EC2_DefaultRole is the default managed role that is assigned to our EC2 instances as an instance profile when we create our cluster. The role has a default managed policy called “AmazonElasticMapReduceforEC2Role” which has a few risky actions.

If we will take a closer look, we can see that this policy contains several actions such as “dynamodb:*”, “s3:*”, “cloudwatch:*”, “sns:*”, “sqs:*”, “sdb:*” and similar to the above example, with the resource of “*”. These configurations allow attackers to perform all actions on all resources. From an Amazon S3 service point of view this means attackers can read, write, list, and delete any bucket or object inside the bucket. From a DynanoDB point of view it allows attackers to query, execute statements, delete tables, and take many more actions. In addition to these risky actions, this policy also includes “ec2:Describe*” and “rds:Describe*” and although these actions do not allow the modification of any data, they provide a great value for an attacker as they can be used for reconnaissance.

Using these permissions an attacker can gain a better understanding about the environment – what instances are running, what roles and instance profiles are attached, private and public IP addresses, vpc, subnets, security groups, and more. This information can be used to build a map of the environment and leveraged for future attacks.

Part of ‘AmazonElasticMapReduceforEC2Role’ policy (V1 policy)

How are these two risky default managed roles limited in V2?

Amazon’s EMR V2 policies allow better security by granting specific access privileges in combination with resource tagging.

There are two main things the new V2 policies provide:

1. “iam:PassRole” action requires iam:PassedToService condition set to specified services
2. Amazon does not allow full access to EC2, S3 , DynamoDB, SNS, SQS and other services by default.

EMR_DefaultRole (V2):

The risky V1 policy “AmazonElasticMapReduceRole” will be replaced with V2 policy “AmazonEMRServicePolicy_v2” where the type of actions has been minimized and the resources are more specific and require additional conditions.

EMR_EC2_DefaultRole (V2):

There is no replacement AWS default managed role or policy for the risky V1 policy “AmazonElasticMapReduceforEC2Role”. You must create a resource-based or identity-based policy by yourself. It is important to follow the least privileges security guidelines and allow only the necessary actions to perform the task.

Lightspin detects these risky roles and policies in a full attack path, as shown below:

How can we search for users or roles that can escalate privileges using AmazonElasticMapReduceFullAccess?

Besides the two roles described above, Amazon’s managed EMR policies includes the policy “AmazonElasticMapReduceFullAccess” that can be attached to IAM roles or users which allows full permissions for EMR actions.

Part of ‘AmazonElasticMapReduceFullAccess’ policy (V1 policy)

When looking at the actions list, we can see the action “iam:PassRole”. What is so critical about this action?

When we configure services in AWS we need to pass a role to the service. This action allows the service to assume the role and perform actions on our behalf (according to the policy attached to the role). The fact that this policy has “iam:PassRole” actions with a resource of “*” essentially allows attackers to pass any role to any service that matches the trusted policy, including admin roles which may lead to privilege escalation.

An example would be creating an EC2 instance with a strong role. This policy also allows EC2 instance creation using the action: “ec2:RunInstances”. When creating the instance, we can pass a strong role using the pass role action. Once the instance is up and running we can access its metadata and extract the security credintials of the role, and use it later to compromise the account.

In order to check which users, roles, or groups are using this policy we can simply use AWS CLI with the following command:

aws iam list-entities-for-policy –policy-arn arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess

Expected output:

{
"PolicyGroups": [],
"PolicyUsers": [
{
"UserName": "dana_test"
}
],
"PolicyRoles": []
}


Lightspin detects this privilege escalation and alerts the user:

Conclusion

Amazon EMR is a great service for processing and analyzing big data, but as in any other service, it is important to double check the default roles that we use and stick to the concept of ‘least privilege’. In this post we explored the risky defaults of V1 EMR managed roles and policies are explained how V2 solves the issue in some cases.

Check your environment:

• AmazonElasticMapReduceFullAccess
  • Check if there are users or roles in your environment that use V1 policy “AmazonElasticMapReduceFullAccess”:

    aws iam list-entities-for-policy --policy-arn arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess

  • If there are, replace it with V2 policy “AmazonEMRFullAccessPolicy_v2” that depends on scoped-down access to resources that Amazon EMR provisions or uses.

• EMR_EC2_DefaultRole
  • Check if there are EMR clusters in your environment that use V1 managed role EMR_EC2_DefaultRole for the EC2 nodes:

    aws emr describe-cluster --cluster-id <cluster-id> --query "Cluster.Ec2InstanceAttributes.IamInstanceProfile"

  • If there are, you need to create a new custom role that allows only the actions required by the task running on the node.

Try Lightspin for free? Start now.

*** This is a Security Bloggers Network syndicated blog from Lightspin Blog authored by Dana Tsymberg. Read the original post at: https://blog.lightspin.io/why-update-risky-default-emr-managed-roles-and-policies