In the previous tutorial, we learned about cloud technologies and how to conduct data gathering. It’s not always the case that the user whose access you managed to obtain will be an administrator, so it’s worth learning how to perform privilege escalation in an IAM environment.
It’s recommended to start from the policies: our goal is to get unlimited access to as many resources as possible. A policy with Action: , Resource: , Effect: Allow.
IAM provides a wide range of capabilities, and as a result, the attack vectors are many. Let’s look at some of them.
Creating a new policy version
The iam:CreatePolicyVersion permission allows us to create a new version of a particular policy. If we have access to the object to which the policy is bound, we can escalate our privileges.
To check the policies attached to a user, use the following commands:
kali> aws iam list-attached-user-policies –user-name <username>
kali> aws iam list-user-policies –user-name <username>
To do this, we can use the following method.
Create a json file, in my case it is MyPolicy.json:
Although setting a new policy version as default typically requires the iam:SetDefaultPolicyVersion permission, using the –set-as-default flag during creation automatically designates it as the new default version without needing that permission.
The procedure is as follows: first, we need to try to gain control of any user account that has any policy attached to it. After that, we simply create a new policy in AWS, updating an existing one. The result is that the object you have control over gets unlimited permissions.
Attaching a policy to a user/group
If our IAM user has the iam:AttachUserPolicy permission, then we can escalate privileges by attaching a policy, gaining the permissions specified in that policy.
This can be done as follows:
kali> aws iam attach-user-policy –user-name my_username –policy-arn arn:aws:iam::aws:policy/AdministratorAccess
As you might have guessed, the user will get administrator rights. Adding a policy to a group works in the same way, but requires iam:AttachGroupPolicy permission:
kali> aws iam attach-group-policy –group-name my_group –policy-arn arn:aws:iam::aws:policy/AdministratorAccess
Setting the default policy version
Suppose you find out that the cloud you are investigating has multiple versions of the same policy. And the first version gives slightly more advanced features than the second version. In this case, with the iam:SetDefaultPolicyVersion privilege, we can change the policy version to the one we need.
For example, you noticed that the PolicyToChange policy has several versions:
kali> aws iam list-policy-versions –policy-arn arn:aws:iam::123456789012:policy/PolicyToChange
To analyze a specific version in depth, use the following command:
kali> aws iam get-policy-version –policy-arn arn:aws:iam::
123456789012:policy/PolicyToChange –version-id v1
After the analysis, you will be able to determine the policy that provides more capabilities. And change it to the required one with a command:
kali> aws iam set-default-policy-version –policy-arn arn:aws:iam:: 123456789012:policy/PolicyToChange –version-id v1
Creating an EC2 instance with an existing instance profile
With iam:PassRole and ec2:RunInstances permissions, we can create a new EC2 instance with OS access. Then, we pass an existing EC2 instance profile/service role to it. By logging into the instance, we request associated AWS keys from the EC2 instance metadata, gaining access to all permissions of the instance profile/service role.
We can access the instance by creating/importing an SSH key or supplying a script in the EC2 User Data or a reverse shell payload.
Once the instance is running and accessible, querying the EC2 metadata provides temporary credentials for the associated instance profile, granting access to any AWS service the attached role has.
An example command to exploit this method might look like this:
kali> aws ec2 run-instances –image-id 12345 –instance-type t2.micro –iam-instance-profile Name=iam-full-access-ip –key-name my_ssh_key –security-group-ids sg-123456
Where we have access to my_ssh_key and the security group sg-123456 allows SSH access. Another command that could be run that doesn’t require an SSH key or security group allowing SSH access might look like this:
kali> aws ec2 run-instances –image-id 12345 –instance-type t2.micro –iam-instance-profile Name=iam-full-access-ip –user-data file://reverse_shell.sh
Where the .sh script file contains a script to open a reverse shell in one way or another.
Automated checks
Various tools exist to scan policies and look for privilege escalation vectors. One of them is aws_escalate.py (https://github.com/RhinoSecurityLabs/Security-Research/blob/master/tools/aws-pentest-tools/aws_escalate.py).
To start, specify the following options:
kali> python3 aws_escalate.py –user-name User –access-key-id 12345 –secret-key 12345
You can also choose not to specify a particular user and use the -all-users switch to scan all available users.
It is worth noting that privilege escalation itself via IAM is a relatively simple procedure. The most important thing is to realize that it’s always required to enumerate policies. Most often, the vulnerable configuration is located there.
Summary
With these simple methods, we can escalate your IAM privileges and get full administrator rights.
To be continued…
