AWS - IAM & STS Enumerazione Non Autenticata

Reading time: 6 minutes

Enumerare Ruoli e Nomi Utente in un account

Forza Bruta per Assumere Ruolo

Tentare di assumere un ruolo senza le autorizzazioni necessarie attiva un messaggio di errore di AWS. Ad esempio, se non autorizzato, AWS potrebbe restituire:

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 policy di assunzione non consente la tua assunzione. Al contrario, cercare di assumere un ruolo inesistente porta a un errore diverso:

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

Interessantemente, questo metodo di distinguere tra ruoli esistenti e non esistenti è applicabile anche tra diversi account AWS. Con un ID account AWS valido e una wordlist mirata, è possibile enumerare i ruoli presenti nell'account senza affrontare alcuna limitazione intrinseca.

Puoi usare questo script per enumerare i potenziali principi sfruttando questo problema.

Politiche di Fiducia: Brute-Force ruoli e utenti Cross Account

Configurare o aggiornare la politica di fiducia di un ruolo IAM implica definire quali risorse o servizi AWS sono autorizzati ad assumere quel ruolo e ottenere credenziali temporanee. Se la risorsa specificata nella politica esiste, la politica di fiducia viene salvata con successo. Tuttavia, se la risorsa non esiste, viene generato un errore, indicando che è stato fornito un principale non valido.

Questo è un esempio di politica:

{
"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 utilizzi un ruolo che non esiste. Se il ruolo esiste, la policy sarà salvata senza errori. (L'errore è per l'aggiornamento, ma funziona anche durante la creazione)

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"

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

Utilizzando 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 utilizzato nell'esempio è un ruolo nel tuo account da impersonare da pacu per creare le politiche necessarie per l'enumerazione

Privesc

Nel caso in cui il ruolo fosse configurato male e consenta a chiunque di assumerlo:

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

L'attaccante potrebbe semplicemente presumere.

Federazione OIDC di terze parti

Immagina di riuscire a leggere un Github Actions workflow che sta accedendo a un role all'interno di AWS.
Questa fiducia potrebbe dare accesso a un role con la seguente trust policy:

{
"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 policy di fiducia potrebbe essere corretta, ma la mancanza di ulteriori condizioni dovrebbe farti diffidare.
Questo perché il ruolo precedente può essere assunto da CHIUNQUE da Github Actions! Dovresti specificare nelle condizioni anche altre cose come il nome dell'organizzazione, il nome del repository, l'ambiente, il ramo...

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

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

Nota che wildcard (*) prima dei due punti (:). Puoi creare un org come org_name1 e assumere il ruolo da un'azione Github.

Riferimenti

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