[LAB] [CTF] iam:PutRolePolicy PrivEsc

Scenario 🧪

AWS IAM roles are incredibly useful and powerful, and you can assume them to receive permissions either within your account, or even for cross-account access.

You can do that using AssumeRole which returns a set of temporary security credentials that can then be used in a similar way to regular access keys, except they are short-term credentials instead of long-term credentials.

If your IAM user has AssumeRole permissions for a particular role (which is dictated by a role’s trust policy), you can assume that role and whatever permissions it has. If you have that permission plus the iam:PutRolePolicy permission, then you can update the permissions for that role using whatever custom IAM policy you want (instead of having to use a managed policy like we saw in the prior lab).

Your lab user has access to perform support functions by assuming roles with AssumeRole, including a role that has access to a non-sensitive S3 bucket containing generic files for an application that you support.

However, this lab has been misconfigured to grant you iam:PutRolePolicy. Leverage this misconfiguration to give that role additional permissions to access secrets in Secrets Manager.

You’ve captured the flag when you’ve successfully decoded the secret string stored in Secrets Manager and you’re able to read it in plaintext.

Tips

Tip #1: Since there can be a lot of roles in AWS accounts, you can use list-roles --query to filter out unwanted results. To speed things up in this lab, I recommend typing this in (whenever you’re ready to enumerate roles) to surface the role you will be interested in:

aws iam list-roles --query "Roles[?RoleName=='SupportRole']"

Code language: CSS (css)

Tip #2: When creating the custom IAM policy, I recommend uploading a full permissions policy like this:

vim policy.json

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

Code language: JavaScript (javascript)

(I’m using vim but you can use whatever text editor you’re comfortable with)

Tip #3: The encoding applied to the secret string is nothing fancy. You can use simple online tools like this to decode it.

Steps

• Using the provided Access Key ID and Secret Access Key, configure your AWS CLI profile
• Using the AWS CLI, identify what permissions your current user has access to and perform general reconnaissance to familiarize yourself with the AWS environment
• Leverage your iam:PutRolePolicy permissions to gain access to a secret encoded string value stored in Secrets Manager
• Decode the string and read it in plaintext
• Submit the decoded secret as the flag