AWS - IAM Post Exploitation

Reading time: 8 minutes

tip

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) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

IAM

Per maggiori informazioni sull'accesso IAM:

AWS - IAM, Identity Center & SSO Enum

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 <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

tip

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) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks