AWS - IAM & STS Unauthenticated Enum
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:
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:
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:
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
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:
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:
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:
Nota che il jolly (*) prima dei due punti (:). Puoi creare un'organizzazione come org_name1 e assumere il ruolo da un'azione Github.
Riferimenti
Last updated