FINRA Security Engineer Finds Privilege Escalation in Amazon EC2 Autoscaling
Read time: 4 minutes
Shubham Agrawal, a Senior Security Engineer with FINRA, discovered that the Amazon EC2 Autoscaling service lacked PassRole validation check for one of its commands, CreateLaunchConfiguration. This can lead to “privilege escalation” in the AWS cloud, which is gaining elevated access or jumping from a lower privileged role to higher privileged one. This blog discusses the system vulnerability and its remediation.
Amazon EC2 Autoscaling is a service which enables the scaling of resources, providing constant and uninterrupted performance. To create an autoscaling group that can launch EC2 instances, you should first create either a launch configuration or a launch template. Today, Amazon Web Services (AWS) guidance strongly recommends switching from launch configuration to launch template. Launch configurations do not provide full functionality of autoscaling, and AWS has said in a blog that it will not add any supporting new features. The vulnerability shown in this article is about launch configurations.
During my research on the Amazon EC2 Autoscaling, I discovered that it lacked the PassRole validation check for one of its actions, CreateLaunchConfiguration. Due to missing validation, any AWS user/role who has permission to use this action can launch an EC2 instance with any role of their choice. To do that, they need to pass the instance-id of the EC2 instance which has that role assigned. Let me give you a walkthrough on how to achieve that.
Setting up the Environment
To get to the vulnerability, I first set up the basic environment. I created two different roles and assigned them the AmazonEC2FullAccess managed policy. This policy contains full permissions for multiple AWS services, among which is autoscaling. I called the roles “AutoScaling_IAM_1” and “AutoScaling_IAM_2”. Additionally, no PassRole permission was given to prove the bypass.
This is the AmazonEC2FullAccess managed policy; it shows autoscaling has been given full permission.
Having these two roles, the next step was to have two different web application servers or EC2 instances with different roles assigned. Our goal here was to represent how someone who has access to one server, can spin up another EC2 instance with a different role.
The Finding
After creating these instances, my next step was to connect through Secure Shell (SSH) into the first instance and use a create-launch-configuration command. SSH is a network communication protocol used to securely connect one device to another. According to AWS’s autoscaling create-launch-configuration documentation, there are two ways one can create a launch configuration:
- Provide an individual option like key-name, security-groups, iam-instance-profile, or many more.
- Provide an instance-id option, which will directly replicate the configuration of provided instance id, without the hassle of providing each option.
This example outlines the instance-id option providing the instance-id of the second EC2 instance.
aws autoscaling create-launch-configuration --launch-configuration-name
In the above screenshot, you can see that the launch configuration was created without any failure. You can check the same thing on the AWS console. The successful creation of the launch configuration highlighted a critical security flaw of role authorization.
The AWS console shows that a launch configuration was created with instance profile of the second role “AutoScaling_IAM_2”.
Further, to prove it is possible to spin up EC2 instance with second role, an autoscaling group was created using the newly created launch configuration.
aws autoscaling create-auto-scaling-group --auto-scaling-group-name
The screenshot above shows the group was created. This can be checked on the AWS console too.
After clicking on the autoscaling group, and going to the Instance Management tab, you see that the EC2 instance spins up with the second role used as the IAM role.
This proved how one can bypass the validation check by using instance-id and spinning a EC2 instance with an unauthorized role.
The Root Cause
When a user supplied create-launch-configuration command, no check was performed to see if the role was authorized to assign a different role to create a launch configuration. Generally, for this, AWS IAM has a feature called PassRole, a service that allows one to assume a different role and perform actions on behalf of that role (view more). In a secure world, if I want to pass the second role to launch configuration using the first role, the first role needs to have iam:PassRole permission with a resource pointing to the second role’s Amazon Resource Name (ARN). Though that wasn’t the case as shown in the above POC, and due to the missing validation check, the unauthorized creation of EC2 instances was possible.
Remediation
Once contacted, AWS was prudent about fixing this identified issue. The fix encompassed implementation of the lacking PassRole validation when this command was used with instance-id.
AWS also found that another autoscaling action called CreateAutoScalingGroup was vulnerable using the same instance-id option. They fixed the vulnerability for both the actions and pushed the changes to production.
Timeline: From Discovery to Resolution
- August 11, 2022: Vulnerability was discussed with AWS
- August 18, 2022: AWS team came with compensating controls while the actual issue was being fixed. They also mentioned that CreateAutoScalingGroup also has the instance-id option and lacks PassRole Validation.
- September 7, 2022: AWS team deployed fix for this issue in us-east-1/2 region.
- September 9, 2022: AWS team deployed the fix worldwide.
Shubham holds a master’s degree in cybersecurity and has been working in the cybersecurity industry for more than 3 years performing web application security. Recently, he’s grown increasingly interested in Cloud Security (mainly AWS) and in finding ways how users can gain privilege escalation in a cloud environment.
