AWS - STS Privesc

Tip

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

Apoya a HackTricks

STS

sts:AssumeRole

Cada rol se crea con una política de confianza del rol, esta política indica quién puede asumir el rol creado. Si un rol de la misma cuenta indica que una cuenta puede asumirlo, significa que la cuenta podrá acceder al rol (y potencialmente privesc).

Por ejemplo, la siguiente política de confianza del rol indica que cualquiera puede asumirlo; por lo tanto, cualquier usuario podrá privesc a los permisos asociados con ese rol.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole"
}
]
}

Puedes suplantar un rol en ejecución:

aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname

Impacto potencial: Privesc to the role.

Caution

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 con este rol otorga a los usuarios autenticados vía SAML acceso para suplantar el rol.

Un ejemplo de una política de confianza con este permiso es:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "OneLogin",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}

Para generar credenciales que permitan suplantar el role, en general podrías usar algo como:

aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>

Pero los proveedores podrían tener sus propias herramientas para facilitar esto, como onelogin-aws-assume-role:

onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600

Impacto potencial: Privesc al role.

sts:AssumeRoleWithWebIdentity

Este permiso otorga la capacidad de obtener un conjunto de credenciales de seguridad temporales para usuarios que hayan sido autenticados en una aplicación móvil, web, EKS… con un proveedor de identidad web. Learn more here.

Por ejemplo, si una EKS service account debería poder impersonate an IAM role, tendrá un token en /var/run/secrets/eks.amazonaws.com/serviceaccount/token y puede assume the role and get credentials haciendo algo como:

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

Federation Abuse

AWS - Federation Abuse

IAM Roles Anywhere Privesc

AWS IAM RolesAnywhere permite que workloads fuera de AWS asuman IAM roles usando certificados X.509. Pero cuando las trust policies no están correctamente acotadas, pueden ser abusadas para escalada de privilegios.

Para entender este ataque, es necesario explicar qué es un trust anchor. Un trust anchor en AWS IAM RolesAnywhere es la entidad raíz de confianza; contiene el certificado público de una Certificate Authority (CA) 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 el trust anchor está activo, 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) se transformarán en session tags, y estas tags luego se compararán con las condiciones de la trust policy.

Esta policy carece de restricciones sobre qué trust anchor o atributos de certificado están permitidos. Como resultado, cualquier certificado vinculado a cualquier trust anchor en la cuenta puede usarse para asumir este role.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}

Para privesc, se requiere el 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 rol de mayor privilegio

aws_signing_helper credential-process \
--certificate readonly.pem \
--private-key readonly.key \
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin

El ancla de confianza valida que el certificado readonly.pem del cliente proviene de su CA autorizada, y dentro de ese certificado readonly.pem está la clave pública que AWS usa para verificar que la firma fue creada con su clave privada correspondiente readonly.key.

El certificado también proporciona atributos (como CN u OU) que el perfil default transforma en etiquetas, 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 etiquetas no tienen uso y el acceso se concede a cualquiera con un certificado válido.

Para que este ataque sea posible, tanto el ancla de confianza como el perfil default deben estar activos.

Referencias

Tip

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

Apoya a HackTricks