AWS - IAM Post Exploitation

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

IAM

Para más información sobre el acceso a IAM:

AWS - IAM, Identity Center & SSO Enum

Confused Deputy Problem

Si permites que una cuenta externa (A) acceda a un role en tu cuenta, probablemente tendrás 0 visibilidad sobre quién puede exactamente acceder a esa cuenta externa. Esto es un problema, porque si otra cuenta externa (B) puede acceder a la cuenta externa (A), es posible que B también pueda acceder a tu cuenta.

Por lo tanto, al permitir que una cuenta externa acceda a un role en tu cuenta es posible especificar un ExternalId. Esta es una cadena “secreta” que la cuenta externa (A) debe especificar para asumir el role en tu organización. Como la cuenta externa B no conocerá esta cadena, incluso si tiene acceso a A no podrá acceder a tu role.

Sin embargo, ten en cuenta que este “secreto” ExternalId no es un secreto, cualquiera que pueda leer la IAM assume role policy podrá verlo. Pero mientras la cuenta externa A lo conozca, y la cuenta externa B no lo conozca, esto evita que B abuse de A para acceder a tu role.

Ejemplo:

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}

Warning

Para que un atacante explote un confused deputy, necesitará averiguar de algún modo si los principals de la cuenta actual pueden suplantar roles en otras cuentas.

Confianzas inesperadas

Comodín como principal

{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" }
}

Esta política permite a todo AWS asumir el rol.

Servicio como principal

{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}

Esta política permite a cualquier cuenta configurar su apigateway para invocar esta Lambda.

S3 como principal

"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}

Si se da un principal como S3 bucket, dado que los S3 buckets no tienen un Account ID, si eliminaste tu bucket y el attacker lo creó en su propia cuenta, entonces podrían abusar de esto.

No soportado

{
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}

A common way to avoid Confused Deputy problems is the use of a condition with AWS:SourceArn to check the origin ARN. However, algunos servicios podrían no admitir eso (por ejemplo CloudTrail según algunas fuentes).

Eliminación de credenciales

With any of the following permissions — iam:DeleteAccessKey, iam:DeleteLoginProfile, iam:DeleteSSHPublicKey, iam:DeleteServiceSpecificCredential, iam:DeleteInstanceProfile, iam:DeleteServerCertificate, iam:DeleteCloudFrontPublicKey, iam:RemoveRoleFromInstanceProfile — an actor can remove access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates or CloudFront public keys, or disassociate roles from instance profiles. Such actions can immediately block legitimate users and applications and cause denial-of-service or loss of access for systems that depend on those credentials, so these IAM permissions must be tightly restricted and monitored.

# 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

Eliminación de identidades

Con permisos como iam:DeleteUser, iam:DeleteGroup, iam:DeleteRole, o iam:RemoveUserFromGroup, un actor puede eliminar usuarios, roles o grupos—o cambiar la pertenencia a grupos—eliminando identidades y rastros asociados. Esto puede romper inmediatamente el acceso para personas y servicios que dependen de esas identidades, causando denial-of-service o pérdida de acceso, por lo que estas acciones de IAM deben estar estrictamente restringidas y monitorizadas.

# 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 cualquiera de los siguientes permisos — iam:DeleteGroupPolicy, iam:DeleteRolePolicy, iam:DeleteUserPolicy, iam:DeletePolicy, iam:DeletePolicyVersion, iam:DeleteRolePermissionsBoundary, iam:DeleteUserPermissionsBoundary, iam:DetachGroupPolicy, iam:DetachRolePolicy, iam:DetachUserPolicy — un actor puede eliminar o desvincular políticas administradas/inline, eliminar versiones de políticas o permissions boundaries, y desvincular políticas de usuarios, grupos o roles. Esto destruye autorizaciones y puede alterar el modelo de permisos, provocando pérdida inmediata de acceso o denegación de servicio para los principals que dependían de esas políticas, por lo que estas acciones de IAM deben restringirse y supervisarse estrictamente.

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

Eliminación de identidad federada

Con iam:DeleteOpenIDConnectProvider, iam:DeleteSAMLProvider, y iam:RemoveClientIDFromOpenIDConnectProvider, un actor puede eliminar proveedores de identidad OIDC/SAML o eliminar client IDs. Esto rompe la autenticación federada, impidiendo la validación de tokens y denegando inmediatamente el acceso a usuarios y servicios que dependen de SSO hasta que el IdP o las configuraciones se restablezcan.

# 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

Illegitimate MFA Activation

Con iam:EnableMFADevice, un actor puede registrar un dispositivo MFA en la identidad de un usuario, impidiendo que el usuario legítimo inicie sesión. Una vez que se habilita un MFA no autorizado, el usuario puede quedar bloqueado hasta que el dispositivo sea eliminado o restablecido (nota: si se registran múltiples dispositivos MFA, para iniciar sesión solo se requiere uno, por lo que este ataque no tendrá efecto para negar el acceso).

aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

Manipulación de metadatos de certificados/clave

Con iam:UpdateSSHPublicKey, iam:UpdateCloudFrontPublicKey, iam:UpdateSigningCertificate, iam:UpdateServerCertificate, un actor puede cambiar el estado o los metadatos de claves públicas y certificados. Al marcar claves/certificados como inactivos o alterar referencias, puede romper la autenticación SSH, invalidar las validaciones X.509/TLS y interrumpir de inmediato servicios que dependen de esas credenciales, causando pérdida de acceso o disponibilidad.

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*

El comodín de IAM iam:Delete* otorga la capacidad de eliminar muchos tipos de recursos de IAM—users, roles, groups, policies, keys, certificates, MFA devices, policy versions, etc. —y por lo tanto tiene un radio de impacto muy alto: un actor al que se le haya concedido iam:Delete* puede destruir permanentemente identities, credentials, policies y artefactos relacionados, eliminar audit/evidence y causar interrupciones de servicio u operativas. Algunos ejemplos son

# 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 la acción iam:EnableMFADevice puede registrar un dispositivo MFA en una identidad de la cuenta, siempre que el user no tuviera ya uno habilitado. Esto puede usarse para interferir con el acceso de un user: una vez que un attacker registra un dispositivo MFA, el user legítimo puede verse impedido de iniciar sesión porque no controla el MFA registrado por el attacker.

Este ataque de denegación de acceso solo funciona si el user no tenía registrado ningún MFA; si el attacker registra un dispositivo MFA para ese user, el user legítimo quedará bloqueado en cualquier flujo que requiera ese nuevo MFA. Si el user ya tiene uno o más dispositivos MFA bajo su control, añadir un MFA controlado por el attacker no bloquea al user legítimo: puede seguir autenticándose usando cualquier MFA que ya tenga.

Para habilitar (registrar) un dispositivo MFA para un user un attacker podría ejecutar:

aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks