AWS - IAM & STS Unauthenticated Enum

Reading time: 6 minutes

Enumerar Roles & Usernames em uma conta

Assume Role Brute-Force

Tentar assumir uma role sem as permissões necessárias dispara uma mensagem de erro da AWS. Por exemplo, se não autorizado, a AWS pode retornar:

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

Esta mensagem confirma a existência da função, mas indica que a sua política de assumir a função não permite que você a assuma. Em contraste, tentar assumir uma função inexistente leva a um erro diferente:

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

Interessantemente, este método de distinguir entre roles existentes e não existentes é aplicável mesmo entre diferentes contas AWS. Com um ID de conta AWS válido e uma wordlist direcionada, é possível enumerar os roles presentes na conta sem enfrentar limitações inerentes.

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

Trust Policies: Brute-Force Cross Account roles and users

Configurar ou atualizar a trust policy de uma role do IAM envolve definir quais recursos ou serviços AWS têm permissão para assumir essa role e obter credenciais temporárias. Se o recurso especificado na política existe, a trust policy é salva com sucesso. Contudo, se o recurso não existe, um erro é gerado, indicando que um principal inválido foi fornecido.

Este é um exemplo de política:

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

GUI

Esse é o erro que você encontrará se usar uma role que não existe. Se a role existir, a policy será salva sem quaisquer erros. (O erro ocorre ao atualizar, mas também acontece ao criar)

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"

Você pode automatizar esse processo com https://github.com/carlospolop/aws_tools

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

Ou 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
• O admin role usado no exemplo é um role na sua conta a ser assumido pelo pacu para criar as políticas necessárias para a enumeração

Privesc

No caso o role esteja mal configurado e permita que qualquer um o assuma:

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

O atacante poderia simplesmente assumir isso.

Federação OIDC de Terceiros

Imagine que você consiga ler um Github Actions workflow que está acessando um role dentro do AWS.
Essa confiança pode dar acesso a um role com a seguinte política de confiança:

{
"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 confiança pode estar correta, mas a falta de mais condições deve fazê-lo desconfiar dela.
Isso porque a role anterior pode ser assumida por QUALQUER PESSOA do Github Actions! Você deve especificar nas condições também outras coisas, como org name, repo name, env, brach...

Outra misconfiguração potencial é adicionar uma condição como a seguinte:

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

Observe que o wildcard (*) vem antes do colon (:). Você pode criar uma org como org_name1 e assume the role a partir de uma Github Action.

Referências

• https://www.youtube.com/watch?v=8ZXRw4Ry3mQ
• https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/