AWS - IAM & STS Unauthenticated Enum

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

Enumerar Roles & Usernames en una cuenta

Assume Role Brute-Force

Caution

Esta técnica ya no funciona porque, exista el role o no, siempre obtienes 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 role sin los permisos necesarios genera un mensaje de error de AWS. Por ejemplo, si no estás 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 role pero indica que su assume role policy no permite que lo asumas. En contraste, intentar assume a non-existent role leads to a different error:

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

Curiosamente, este método de distinguir entre roles existentes y no existentes es aplicable incluso entre diferentes cuentas AWS. Con un AWS account ID válido y un wordlist dirigido, se pueden enumerar los roles presentes en la cuenta sin enfrentar limitaciones inherentes.

You can use this script to enumerate potential principals abusing this issue.

Trust Policies: Brute-Force Cross Account roles and users

Configurar o actualizar la IAM role’s trust policy implica definir qué recursos o servicios de AWS están permitidos para asumir ese role y obtener credenciales temporales. Si el recurso especificado en la policy existe, la trust policy se guarda correctamente. Sin embargo, si el recurso no existe, se genera un error, indicando que se proporcionó un principal inválido.

Warning

Tenga en cuenta que en ese recurso puede especificar un cross account role o user:

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

Este es un ejemplo de policy:

{
"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 role que no existe. Si el role existe, la policy será guardada sin errores. (El error aparece al hacer update, pero también ocurre 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

O 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
  • The admin role used in the example is a role in your account to by impersonated by pacu to create the policies it needs to create for the enumeration

Privesc

En el caso de que el rol esté mal configurado y permita que cualquiera lo asuma:

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

El atacante podría simplemente asumirlo.

Federación OIDC de terceros

Imagina que logras leer un Github Actions workflow que está accediendo a un role dentro de AWS.
Esta confianza podría dar acceso a un role con la siguiente trust policy:

{
"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 trust policy podría 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 CUALQUIERA desde Github Actions! Deberías especificar en las condiciones también otras cosas como nombre de la organización, nombre del repo, env, 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 que el wildcard (*) va antes de los dos puntos (:). Puedes crear una org como org_name1 y assume the role desde una Github Action.

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