Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Trova ulteriori informazioni su IAM in:
iam.roles.update (iam.roles.get)Un attaccante con i permessi menzionati sarà in grado di aggiornare un ruolo assegnato a te e darti permessi extra su altre risorse come:
Puoi trovare uno script per automatizzare la creazione, sfruttamento e pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui. Per ulteriori informazioni, controlla la ricerca originale.
iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)Un attaccante con i permessi menzionati sarà in grado di richiedere un token di accesso che appartiene a un Service Account, quindi è possibile richiedere un token di accesso di un Service Account con più privilegi dei nostri.
Puoi trovare uno script per automatizzare la creazione, sfruttamento e pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui. Per ulteriori informazioni, controlla la ricerca originale.
iam.serviceAccountKeys.createUn attaccante con i permessi menzionati sarà in grado di creare una chiave gestita dall'utente per un Service Account, che ci permetterà di accedere a GCP come quel Service Account.
Puoi trovare uno script per automatizzare la creazione, sfruttamento e pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui. Per ulteriori informazioni, controlla la ricerca originale.
Nota che iam.serviceAccountKeys.update non funzionerà per modificare la chiave di un SA perché per farlo è necessaria anche la permission iam.serviceAccountKeys.create.
iam.serviceAccounts.implicitDelegationSe hai la iam.serviceAccounts.implicitDelegation permission su un Service Account che ha la iam.serviceAccounts.getAccessToken permission su un terzo Service Account, allora puoi usare implicitDelegation per creare un token per quel terzo Service Account. Ecco un diagramma per aiutare a spiegare.
Nota che secondo la documentazione, la delega di gcloud funziona solo per generare un token utilizzando il metodo generateAccessToken(). Quindi ecco come ottenere un token utilizzando direttamente l'API:
Puoi trovare uno script per automatizzare la creazione, sfruttamento e pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui. Per ulteriori informazioni consulta la ricerca originale.
iam.serviceAccounts.signBlobUn attaccante con i permessi menzionati sarà in grado di firmare payload arbitrari in GCP. Quindi sarà possibile creare un JWT non firmato del SA e poi inviarlo come blob per ottenere il JWT firmato dal SA che stiamo prendendo di mira. Per ulteriori informazioni leggi questo.
Puoi trovare uno script per automatizzare la creazione, sfruttamento e pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui e qui. Per ulteriori informazioni consulta la ricerca originale.
iam.serviceAccounts.signJwtUn attaccante con i permessi menzionati sarà in grado di firmare token web JSON (JWT) ben formati. La differenza con il metodo precedente è che invece di far firmare a Google un blob contenente un JWT, utilizziamo il metodo signJWT che già si aspetta un JWT. Questo rende più facile l'uso, ma puoi solo firmare JWT invece di qualsiasi byte.
Puoi trovare uno script per automatizzare la creazione, sfruttamento e pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui. Per ulteriori informazioni consulta la ricerca originale.
iam.serviceAccounts.setIamPolicyUn attaccante con i permessi menzionati sarà in grado di aggiungere politiche IAM agli account di servizio. Puoi abusarne per concederti i permessi di cui hai bisogno per impersonare l'account di servizio. Nel seguente esempio ci stiamo concedendo il ruolo roles/iam.serviceAccountTokenCreator sull'SA interessante:
Puoi trovare uno script per automatizzare la creazione, sfruttamento e pulizia di un ambiente vulnerabile qui.
iam.serviceAccounts.actAsIl permesso iam.serviceAccounts.actAs è simile al permesso iam:PassRole di AWS. È essenziale per eseguire compiti, come avviare un'istanza di Compute Engine, poiché concede la possibilità di "agire come" un Service Account, garantendo una gestione sicura dei permessi. Senza questo, gli utenti potrebbero ottenere accessi indebiti. Inoltre, sfruttare il iam.serviceAccounts.actAs comporta vari metodi, ognuno dei quali richiede un insieme di permessi, a differenza di altri metodi che necessitano solo di uno.
Impersonare un service account può essere molto utile per ottenere nuovi e migliori privilegi. Ci sono tre modi in cui puoi impersonare un altro service account:
Autenticazione utilizzando chiavi private RSA (trattato sopra)
Autorizzazione utilizzando politiche Cloud IAM (trattato qui)
Distribuzione di lavori sui servizi GCP (più applicabile al compromesso di un account utente)
iam.serviceAccounts.getOpenIdTokenUn attaccante con i permessi menzionati sarà in grado di generare un OpenID JWT. Questi vengono utilizzati per affermare l'identità e non portano necessariamente alcuna autorizzazione implicita contro una risorsa.
Secondo questo interessante post, è necessario indicare il pubblico (servizio dove si desidera utilizzare il token per autenticarsi) e si riceverà un JWT firmato da google che indica il service account e il pubblico del JWT.
Puoi generare un OpenIDToken (se hai accesso) con:
Poi puoi semplicemente usarlo per accedere al servizio con:
Alcuni servizi che supportano l'autenticazione tramite questo tipo di token sono:
Google Cloud Endpoints (se si utilizza Google OIDC)
Puoi trovare un esempio su come creare un token OpenID per conto di un account di servizio qui.
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
