IAM PRIVESC BY KEY ROTATION

This is a challenge from RhinoSecurity Labs to explore AWS IAM permissions. Let’s consider a scenario where we obtained an AWS key need to escalate privileges with the objective to know the impact of the secret.

From the first key, we have an interesting role attached, named as “cg_secretsmanager_iam_privesc_by_key_rotation_cgidoamkiu1siv”. This roles are used to allow certain access in the AWS context, from one role we can assume it and perform actions. To use the secrets manager role, we need to establish a condition, which is the presence of the multifactor authentication attribute.

After knowing the roles, the following command was used to show the users. From the output, we could notice the presence of three users with potentially different privileges reading the username: administrator, manager and developer.

Listing the policies of each user, we can identify that the unique user that can assume the role shown in the beginning of the report is the admin. The developer can view secrets, and the respective user can self-manage MFA related scopes and tag sources.

Reading each policy, we could know that to use “SelfManageAccess” related, the tag of developer is needed to be set as true.

Describing the policy to tag users:

When we try to create or delete an access key of the admin user, we can't perform these actions yet.

From this point, I could know that to perform changes in the user admin, the tag developer is needed to be set. The following command was used to perform changes:

aws iam tag-user --tags '[{"Key":"developer","Value":"true"}]' --user-name admin_iam_privesc_by_key_rotation_cgidpyfrwbgz27 --profile iampriv

After setting the tag, the deletion of the access key of the administrator user was done with the “delete-access-key” command.

aws iam delete-access-key --access-key-id AKIA2UC3EPL3CFXKMGN6 --user-name admin_iam_privesc_by_key_rotation_cgidpyfrwbgz27 --profile iampriv

Previously, I tried to perform other actions with the manager user and the developer, but this path didn’t result in good ways to perform privilege escalation and the execution of the role. Creation of an administration access key:

To achieve “MultiFactorAuthPresent” an MFA is needed. The following steps were used to configure and activate MFA device, a principal virtual device exists, but in this process we will create other.

From the documentation, we could find the description of the flags needed to be passed to create a new virtual device: https://docs.aws.amazon.com/cli/latest/reference/iam/create-virtual-mfa-device.html.

The QRCodePNG bootstrap method was used to provide an image that is scanned in the MFA app, returning us the temporary tokens to be used in services (The creation of the device is through the manager access key).

aws iam create-virtual-mfa-device --virtual-mfa-device-name tempdevice --outfile ./output --bootstrap-method QRCodePNG --profile iampriv

Image to be scanned:

After creating the device, it needs to be activated using the serial number, the username to which the device will be attached, and two authentication tokens provided by the TOTP app.

aws iam enable-mfa-device --serial-number arn:aws:iam::730335574774:mfa/tempdevice --user-name admin_iam_privesc_by_key_rotation_cgidpyfrwbgz27 --authentication-code1 xxxxxx --authentication-code2 xxxxxx --profile iampriv

With the device enabled in the administrator account, the STS is used to generate a session key: https://repost.aws/knowledge-center/authenticate-mfa-cli.

Verification of success:

aws sts get-caller-identity --profile adminsession

At this point, we have all the conditions needed to run the role that allow us to read secrets.

From the temporary role, the secrets manager was listed.

This is the flag of the challenge, all the steps were followed to reach this point, allowing us to use the secrets manager role, the commands and steps were made to reach this point, this is a simple report showing how to explore these vulnerabilities.