gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-13 13:26:31 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2025-09-30 19:16:42 +00:00
parent 01ce56dcea
commit ea0bc193c8
1 changed files with 16 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
View File

@@ -30,13 +30,12 @@ aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
**Impacto potencial:** Privesc al rol.
> [!CAUTION]
> Ten en cuenta que en este caso el permiso `sts:AssumeRole` debe estar **indicado en el rol que se va a abusar** y no en una política perteneciente al atacante.\
> Con una excepción, para **asumir un rol desde otra cuenta** la cuenta atacante **también necesita** tener el **`sts:AssumeRole`** sobre el rol.
> Ten en cuenta que en este caso el permiso `sts:AssumeRole` necesita estar **indicado en el rol a abusar** y no en una política perteneciente al atacante.\
> Con una excepción, para **asumir un rol desde una cuenta diferente** la cuenta atacante **también necesita** tener el **`sts:AssumeRole`** sobre el rol.
### `sts:AssumeRoleWithSAML`
Una política de confianza para este rol concede **a los usuarios autenticados vía SAML acceso para suplantar el rol.**
Una política de confianza con este rol concede **a los usuarios autenticados vía SAML acceso para suplantar el rol.**
Un ejemplo de una política de confianza con este permiso es:
```json
@@ -63,7 +62,7 @@ Para generar credenciales para suplantar el rol, en general podrías usar algo c
```bash
aws sts assume-role-with-saml --role-arn <value> --principal-arn <value>
```
Pero **proveedores** podrían tener sus **propias herramientas** para facilitar esto, como [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
Pero los **proveedores** podrían tener sus **propias herramientas** para facilitar esto, como [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
```bash
onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
```
@@ -73,7 +72,7 @@ onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --
Este permiso permite obtener un conjunto de credenciales de seguridad temporales para **usuarios que han sido autenticados en una aplicación móvil, web, EKS...** con un proveedor de identidad web. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
Por ejemplo, si una **cuenta de servicio de EKS** debería poder **suplantar a un rol de IAM**, tendrá un token en **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** y podrá **asumir el rol y obtener credenciales** haciendo algo como:
Por ejemplo, si una **EKS service account** debería poder **hacerse pasar por un rol de IAM**, tendrá un token en **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** y puede **asumir el rol y obtener credenciales** haciendo algo como:
```bash
aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
# The role name can be found in the metadata of the configuration of the pod
@@ -86,9 +85,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
### IAM Roles Anywhere Privesc
AWS IAM RolesAnywhere permite que cargas de trabajo fuera de AWS asuman roles de IAM usando certificados X.509. Pero cuando las políticas de confianza no están correctamente acotadas, pueden ser abusadas para escalada de privilegios.
AWS IAM RolesAnywhere permite que cargas de trabajo fuera de AWS asuman roles de IAM usando certificados X.509. Pero cuando las políticas de confianza no están correctamente acotadas, pueden ser abusadas para privilege escalation.
Esta política no tiene restricciones sobre qué trust anchor o atributos del certificado están permitidos. Como resultado, cualquier certificado vinculado a cualquier trust anchor en la cuenta puede usarse para asumir este rol.
Para entender este ataque, es necesario explicar qué es una ancla de confianza. Una ancla de confianza en AWS IAM RolesAnywhere es la entidad raíz de confianza; contiene el certificado público de una Certificate Authority (CA) que está registrada en la cuenta para que AWS pueda validar los certificados X.509 presentados. De este modo, si el certificado del cliente fue emitido por esa CA y la ancla de confianza está activa, AWS lo reconoce como válido.
Además, un profile es la configuración que define qué atributos del certificado X.509 (como CN, OU o SAN) serán transformados en etiquetas de sesión, y estas etiquetas luego se compararán con las condiciones de la política de confianza.
Esta política carece de restricciones sobre qué ancla de confianza o atributos del certificado están permitidos. Como resultado, cualquier certificado vinculado a cualquier ancla de confianza en la cuenta puede usarse para asumir este role.
```json
{
"Version": "2012-10-17",
@@ -108,9 +111,9 @@ Esta política no tiene restricciones sobre qué trust anchor o atributos del ce
}
```
Para privesc, se requiere el `aws_signing_helper` desde https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
Para privesc, se requiere `aws_signing_helper` desde https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
Luego, usando un certificado válido, el atacante puede pivot hacia el role de mayor privilegio
Luego, usando un certificado válido, el atacante puede pivot hacia el rol de mayor privilegio
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
@@ -119,13 +122,11 @@ aws_signing_helper credential-process \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin
```
El trust anchor valida que el certificado de cliente `readonly.pem` proviene de su CA autorizada; cuando se creó el trust anchor se incluyó el certificado público de la CA (y ahora se usa para validar `readonly.pem`). Dentro de `readonly.pem` está la clave pública, que AWS usa para verificar que la firma fue hecha con su clave privada correspondiente `readonly.key`.
El ancla de confianza valida que el certificado `readonly.pem` del cliente proviene de su CA autorizada, y dentro de este certificado `readonly.pem` está la clave pública que AWS usa para verificar que la firma fue realizada con su clave privada correspondiente `readonly.key`.
El certificado también prueba la identidad y proporciona atributos (como CN u OU) que el perfil `default` transforma en tags, los cuales la trust policy del role puede usar para decidir si autorizar el acceso. Si no hay condiciones en la trust policy, esas tags se ignoran y cualquiera con un certificado válido puede acceder.
El certificado también proporciona atributos (como CN u OU) que el perfil `default` transforma en tags, que la política de confianza del rol puede usar para decidir si autoriza el acceso. Si no hay condiciones en la política de confianza, esas tags no sirven de nada y el acceso se concede a cualquiera con un certificado válido.
Para que este ataque sea posible, tanto el trust anchor como el perfil `default` deben estar activos.
### References
### Referencias
- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)