Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws

This commit is contained in:
Translator
2025-10-23 20:48:56 +00:00
parent 3fc13bd3a8
commit 060c839d56
18 changed files with 560 additions and 571 deletions

View File

@@ -4,7 +4,7 @@
## IAM
Para más información sobre el acceso IAM:
Para más información sobre el acceso a IAM:
{{#ref}}
../../aws-services/aws-iam-enum.md
@@ -12,13 +12,13 @@ Para más información sobre el acceso IAM:
## Confused Deputy Problem
Si permites que una cuenta externa (A) acceda a un rol en tu cuenta, probablemente tendrás 0 visibilidad sobre quién exactamente puede 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.
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 rol en tu cuenta, es posible especificar un `ExternalId`. Esta es una cadena "secreta" que la cuenta externa (A) necesita especificar para poder asumir el rol en tu organización. Como la cuenta externa B no conocerá esta cadena, incluso si tiene acceso a A no podrá acceder a tu rol.
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**.
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
Sin embargo, ten en cuenta que este "secreto" `ExternalId` **no es un secreto**: cualquiera que pueda leer la política de assume role de IAM 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 rol.
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:
```json
@@ -39,11 +39,11 @@ Ejemplo:
}
```
> [!WARNING]
> Para que un atacante explote un confused deputy, necesitará averiguar de alguna manera si los principals de la cuenta actual pueden suplantar roles en otras accounts.
> 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
#### Wildcard como principal
#### Comodín como principal
```json
{
"Action": "sts:AssumeRole",
@@ -62,7 +62,7 @@ Esta política **permite a todo AWS** asumir el rol.
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
```
Esta política **permite a cualquier cuenta** configurar su apigateway para llamar a esta Lambda.
Esta política **permite a cualquier cuenta** configurar su apigateway para invocar esta Lambda.
#### S3 como principal
```json
@@ -73,7 +73,7 @@ Esta política **permite a cualquier cuenta** configurar su apigateway para llam
}
}
```
Si se especifica un S3 bucket como principal, dado que los S3 buckets no tienen Account ID, si **eliminaste tu bucket y el attacker lo creó** en su propia cuenta, entonces podrían abusar de esto.
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
```json
@@ -84,10 +84,10 @@ Si se especifica un S3 bucket como principal, dado que los S3 buckets no tienen
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
```
Una forma común de evitar problemas de Confused Deputy es el uso de una condición con `AWS:SourceArn` para comprobar el ARN de origen. Sin embargo, **algunos servicios podrían no soportarlo** (como CloudTrail según algunas fuentes).
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
Con cualquiera de los siguientes permisos — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile`un actor puede eliminar claves de acceso, perfiles de inicio de sesión, claves SSH, credenciales específicas de servicio, perfiles de instancia, certificados o claves públicas de CloudFront, o desasociar roles de perfiles de instancia. Tales acciones pueden bloquear inmediatamente a usuarios y aplicaciones legítimas y provocar denegación de servicio o pérdida de acceso para sistemas que dependen de esas credenciales, por lo que estos permisos de IAM deben estar estrictamente restringidos y vigilados.
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.
```bash
# Remove Access Key of a user
aws iam delete-access-key \
@@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \
--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 un grupo—eliminando identidades y trazas asociadas. Esto puede interrumpir 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.
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.
```bash
# Delete a user
aws iam delete-user \
@@ -115,7 +115,7 @@ 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/en línea, eliminar versiones de políticas o límites de permisos, 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 las entidades que dependían de esas políticas, por lo que estas acciones de IAM deben estar fuertemente restringidas y monitorizadas.
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.
```bash
# Delete a group policy
aws iam delete-group-policy \
@@ -128,7 +128,7 @@ aws iam delete-role-policy \
--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 interrumpe 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.
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.
```bash
# Delete OIDCP provider
aws iam delete-open-id-connect-provider \
@@ -138,8 +138,8 @@ aws iam delete-open-id-connect-provider \
aws iam delete-saml-provider \
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
```
### Activación no autorizada de MFA
Con `iam:EnableMFADevice`, un atacante 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, iniciar sesión requiere solo uno, por lo que este ataque no tendrá efecto para negar el acceso).
### 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).
```bash
aws iam enable-mfa-device \
--user-name <Username> \
@@ -147,8 +147,8 @@ aws iam enable-mfa-device \
--authentication-code1 123456 \
--authentication-code2 789012
```
### Certificate/Key Metadata Tampering
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 e interrumpir inmediatamente servicios que dependen de esas credenciales, provocando pérdida de acceso o disponibilidad.
### 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.
```bash
aws iam update-ssh-public-key \
--user-name <Username> \
@@ -161,7 +161,7 @@ aws iam update-server-certificate \
```
### `iam:Delete*`
El comodín de IAM iam:Delete* otorga la capacidad de eliminar muchos tipos de recursos de IAM —usuarios, roles, grupos, políticas, claves, certificados, dispositivos MFA, versiones de políticas, etc.— y, por lo tanto, tiene un radio de impacto muy alto: un actor al que se le conceda iam:Delete* puede destruir permanentemente identidades, credenciales, políticas y artefactos relacionados, eliminar auditoría/evidencia y provocar interrupciones de servicio u operativas. Algunos ejemplos son
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
```bash
# Delete a user
aws iam delete-user --user-name <Username>
@@ -174,11 +174,11 @@ aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
```
### `iam:EnableMFADevice`
Un actor al que se le conceda la acción `iam:EnableMFADevice` puede registrar un MFA device en una identidad de la cuenta, siempre que el usuario no tuviera ya uno habilitado. Esto puede usarse para interferir con el acceso de un usuario: una vez que un attacker registra un MFA device, el usuario legítimo puede verse impedido de iniciar sesión porque no controla el MFA registrado por el attacker.
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 usuario no tenía ningún MFA registrado; si el attacker registra un MFA device para ese usuario, el usuario legítimo quedará bloqueado en cualquier flujo que requiera ese nuevo MFA. Si el usuario ya tiene uno o más MFA devices bajo su control, añadir un MFA controlado por el attacker no bloquea al usuario legítimo — este puede seguir autenticándose usando cualquier MFA que ya posea.
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 MFA device para un usuario, un attacker podría ejecutar:
Para habilitar (registrar) un dispositivo MFA para un user un attacker podría ejecutar:
```bash
aws iam enable-mfa-device \
--user-name <Username> \