Cloud security

CloudGoat walkthrough series: IAM privilege escalation by attachment

This is the fourth in the walkthrough series of the CloudGoat scenarios. CloudGoat is a “vulnerable by design” AWS deployment tool designed by Rhino Security Labs. It is used to deploy a vulnerable set of AWS resources and is designed to teach and test cloud security penetration testing via issues commonly seen in real-life environments.

This walkthrough assumes you have CloudGoat set up on your Kali Linux. You can use our post on Working with CloudGoat: The “Vulnerable by Design” AWS Environment as a guide in deploying it.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Scenario summary

The scenario starts with an IAM user, Kerrigan, with limited set of permissions. The attacker is able to leverage the instance-profile-attachment permissions to create a new EC2 instance with significantly greater privileges than their own. With access to this new EC2 instance, the attacker gains full administrative powers within the target account.

Goal: Delete the “cg-super-critical security-server”.

Walkthrough

To deploy the resources for each scenario on AWS:

./cloudgoat.py create iam_privesc_by_attachment

1. Deploying the resources gives us the access key and secret key for Kerrigan. [CLICK IMAGES TO ENLARGE]

2. Save the credential to a profile — Kerrigan.

aws configure --profile Kerrigan

3. Perform reconnaissance on the user “Kerrigan” to see what privileges the user has by enumerating the policies and permissions attached to the user.

We tried running the usual commands “list-user-policies” and “list-attached-user-policies”. We noticed we were not authorized to carry out those actions.

aws iam list-user-policies –-user-name <insert username here> --profile <insert profile name here>

list-user-policies: Lists the names of inline policies embedded in the specified IAM user.

aws iam list-attached-user-policies –-user-name <insert username here> --profile <insert profile name here>

list-attached-user-policies: Lists all managed policies that are attached to the specified IAM user.

Running the “list-roles” command revealed two IAM roles: “cg-ec2-meek-role- cgidnek40ur5gb” and “cg-ec2-mighty-role-cgidnek40ur5gb”. From the naming convention, it seems to suggest that the “cg-ec2-mighty-role-cgidnek40ur5gb” may have more permissions than the other role, “cg-ec2-meek-role-cgidnek40ur5gb”.

aws iam list-roles --profile <insert profile name here>

list- roles: Lists the IAM roles that have the specified path prefix.

aws iam list-instance-profiles --profile <insert profile name here>

list-instance-profiles: Lists the instance profiles that have the specified path prefix.

We notice two interesting things: an instance profile (cg-ec2-meek-instance-profile-cgidnek40ur5gb) with an IAM role (cg-ec2-meek-role- cgidnek40ur5gb). An instance profile is a container for a role that can be attached to an Amazon EC2 instance when launched. An instance profile can contain only one role, and that limit cannot be increased.

4. Get more information about the EC2 instance running.

aws ec2 describe-instances --region us-east-1 --profile <insert profile name here>

We notice that an EC2 instance (our target server), “super-critical-security-server”, is running.

To explore the permissions of the identified roles, we are going to attach them to a new EC2 instance and then use the EC2 instance to enumerate the role permissions.

5. Create a new EC2 instance via AWS CLI. The following information are required for the creation of the EC2 instance which can be found using the describe-instances command:

1. The subnet ID of the existing EC2 instance
2. The security group that allows SSH access in the existing EC2 instance
3. The AMI image ID used in creating the existing EC2 instance
4. The ARN of the instance profile in the existing EC2 instance

In addition, we’ll need a new key pair, which will allow us to SSH into the new EC2 instance.

6. Create a key pair, as we don’t have access to any of the existing key pairs in the AWS account (if any).

aws ec2 create-key-pair --key-name <insert key name here> --query ‘KeyMaterial’ –output text > <insert key name here>.pem --region us-east-1 --profile <insert profile name here>

create-key-pair: This command creates a 2048-bit RSA key pair with the specified name. Amazon EC2 stores the public key and displays the private key for you to save to a file. The private key is returned as an unencrypted PEM encoded PKCS#1 private key.

7. Change the permission on the key.

chmod 600 <insert key name here>.pem

Chmod 600 means the owner has full read and write access to the file, while no other user can access the file.

8. Create a new EC2 instance using the newly generated key pair (Scenario04.pem).

aws ec2 run-instances --image-id <insert ami id here> --instance-type <insert instance type here> --iam-instance-profile Arn=<insert the arn of the instance profile> --key-name <inset key name here> --subnet-id <insert the subnet id here> --security-group-ids <insert security group id here> --region us-east-1 --profile <insert profile name here>

run-instances: This command launches a specified number of instances using an AMI for which you have permissions (in our case, we are using a free and public AMI).

• image-id: The image-id for the AWS AMI to be used in creating the EC2 instance.
• instance-type: The type of instance to be created. For a free-tier account, t2.micro.
• iam-instance-profile: The IAM instance profle is the role to be assigned to the EC2 instance.
• key-name: The name of the newly created key pair.
• security-group-ids: This specifies the security group that will be applied to the instance. In this case, we need SSH access to the new EC2 instance, hence the SSH security group ID.
• region: The region where the instance should be created in.
• subnet-id: This specifies the subnet ID that will be applied to the instance.

We currently have the meek role assigned to this instance profile: “cg-ec2-meek-instance-profile-cgidnek40ur5gb“. We have to remove the “cg-ec2-meek-role-cgidnek40ur5gb” role and then attach the “cg-ec2-mighty-role-cgidnek40ur5gb” role to the instance profile.

9. Remove the meek role from the instance profile.

aws iam remove-role-from-instance-profile --instance-profile-name <insert instance profile name here> –-role-name <insert username here> --profile <insert profile name here>

Attach the mighty role to the instance profile.

aws iam add-role-to-instance-profile --instance-profile-name <insert instance profile name here> –-role-name <insert username here> --profile <insert profile name here>

10. SSH into the new EC2 instance.

ssh -i <insert key name here>.pem ubuntu@<insert public ip address here>

Once we are logged in, we install AWS CLI on it.

sudo apt-get install awscli

11. We check permissions assigned to the “mighty role”.

aws iam list-attached-role-name --role-name <insert role name here>

aws iam get-policy –policy-arn <insert the policy arn here>

aws iam get-policy-version –policy-arn <insert the policy arn here> --version-id <insert version id here>

12. Test the new privileges by attempting to delete the critical server.

aws ec2 terminate-instances --instance-ids <insert the EC2 instance id here> --region us-east-1

13. To destroy the resources created during this lab:

./cloudgoat.py destroy iam_privesc_by_attachment

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Summary

The bad actor was able escalate their privilege by removing the “meek role” and attaching the “mighty role” to an instance profile, granting the user full administrative privileges. Using the newly created EC2 instance, the bad actor was able to gain access to the data stored on existing EC2 instance “cg-super-critical-security-server” and also terminate the critical server.

 

Sources

AWS CLI Command Reference - IAM, AWS

Well, that escalated quickly, Bishop Fox

AWS IAM Privilege Escalation Methods, Rhino Security Labs