AWS - IAM & STS Unauthenticated Enum

Reading time: 6 minutes

Enumerate Roles & Usernames in an account

Assume Role Brute-Force

Der Versuch, eine Rolle ohne die erforderlichen Berechtigungen anzunehmen, löst eine AWS-Fehlermeldung aus. Zum Beispiel könnte AWS bei fehlender Berechtigung zurückgeben:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS

Diese Meldung bestätigt die Existenz der Rolle, weist jedoch darauf hin, dass ihre assume role policy Ihre Übernahme nicht erlaubt. Im Gegensatz dazu führt der Versuch, assume a non-existent role leads to a different error:

An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole

Interessanterweise ist diese Methode, zwischen existierenden und nicht existierenden Rollen zu unterscheiden, sogar über verschiedene AWS-Konten anwendbar. Mit einer gültigen AWS account ID und einer gezielten wordlist kann man die im Konto vorhandenen roles auflisten, ohne auf inhärente Einschränkungen zu stoßen.

Sie können dieses script to enumerate potential principals verwenden, um dieses Problem auszunutzen.

Trust Policies: Brute-Force Cross Account roles and users

Configuring or updating an IAM role's trust policy involves defining which AWS resources or services are permitted to assume that role and obtain temporary credentials. If the specified resource in the policy exists, the trust policy saves successfully. However, if the resource does not exist, an error is generated, indicating that an invalid principal was provided.

Das ist ein Policy-Beispiel:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::216825089941:role/Test"
},
"Action": "sts:AssumeRole"
}
]
}

GUI

Das ist der Fehler, den du findest, wenn du eine Rolle verwendest, die nicht existiert. Wenn die Rolle existiert, wird die Policy ohne Fehler gespeichert. (Der Fehler tritt beim Aktualisieren auf, funktioniert aber auch beim Erstellen)

CLI

### You could also use: aws iam update-assume-role-policy
# When it works
aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
{
"Role": {
"Path": "/",
"RoleName": "Test-Role",
"RoleId": "AROA5ZDCUJS3DVEIYOB73",
"Arn": "arn:aws:iam::947247140022:role/Test-Role",
"CreateDate": "2022-05-03T20:50:04Z",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::316584767888:role/account-balance"
},
"Action": [
"sts:AssumeRole"
]
}
]
}
}
}

# When it doesn't work
aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"

Sie können diesen Prozess mit https://github.com/carlospolop/aws_tools automatisieren

• bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt

Oder mit Pacu:

• run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
• run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
• The admin role used in the example is a role in your account to by impersonated by pacu to create the policies it needs to create for the enumeration

Privesc

Falls die Rolle falsch konfiguriert war und es jedem erlaubt, sie zu übernehmen:

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

Der Angreifer könnte sie einfach übernehmen.

Third Party OIDC Federation

Angenommen, es gelingt dir, einen Github Actions workflow zu lesen, der auf eine role in AWS zugreift.
Dieses Vertrauen könnte Zugriff auf eine role mit folgender trust policy gewähren:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<acc_id>:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}

Diese Vertrauensrichtlinie könnte korrekt sein, aber das Fehlen weiterer Bedingungen sollte dich misstrauisch machen.
Dies liegt daran, dass die vorherige Rolle von ANYONE from Github Actions übernommen werden kann! Du solltest in den Bedingungen auch andere Dinge angeben, wie org name, repo name, env, branch...

Eine weitere mögliche Fehlkonfiguration ist, eine Bedingung hinzuzufügen, wie die folgende:

"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
}

Beachte, dass wildcard (*) vor dem Doppelpunkt (:) steht. Du kannst eine org erstellen, z. B. org_name1, und assume the role aus einer Github Action.

Referenzen

• https://www.youtube.com/watch?v=8ZXRw4Ry3mQ
• https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/