Last updated
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Questa tecnica non funziona più poiché se il ruolo esiste 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
Tentare di assumere un ruolo senza le autorizzazioni necessarie attiva un messaggio di errore AWS. Ad esempio, se non autorizzato, AWS potrebbe restituire:
Questo messaggio conferma l'esistenza del ruolo ma indica che la sua politica di assunzione del ruolo non consente la tua assunzione. Al contrario, cercare di assumere un ruolo inesistente porta a un errore diverso:
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 limitazioni intrinseche.
Puoi usare questo script per enumerare potenziali principi abusando di questo problema.
Configurare o aggiornare una 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.
Nota che in quella risorsa potresti specificare un ruolo o utente cross account:
arn:aws:iam::acc_id:role/role_name
arn:aws:iam::acc_id:user/user_name
Questo è un esempio di politica:
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)
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 di cui ha bisogno per l'enumerazione
Nel caso in cui il ruolo fosse configurato male e consenta a chiunque di assumerlo:
L'attaccante potrebbe semplicemente assumerlo.
Immagina di riuscire a leggere un Github Actions workflow che sta accedendo a un ruolo all'interno di AWS. Questa fiducia potrebbe dare accesso a un ruolo con la seguente politica di fiducia:
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:
Nota che il carattere jolly (*) prima dei due punti (:). Puoi creare un'organizzazione come org_name1 e assumere il ruolo da un'azione Github.
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)
