# 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**.
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 \ --access-key-id AKIAIOSFODNN7EXAMPLE ## Remove ssh key of a user aws iam delete-ssh-public-key \ --user-name \ --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 # Delete a group aws iam delete-group \ --group-name # Delete a role aws iam delete-role \ --role-name ``` ### 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 \ --policy-name # Delete a role policy aws iam delete-role-policy \ --role-name \ --policy-name ``` ### 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 \ --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 \ --ssh-public-key-id APKAEIBAERJR2EXAMPLE \ --status Inactive aws iam update-server-certificate \ --server-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 # Delete a role aws iam delete-role --role-name # Delete a managed policy aws iam delete-policy --policy-arn arn:aws:iam:::policy/ ``` ### `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 \ --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}}