AWS - IAM & STS Enum Não Autenticado

Reading time: 6 minutes

Enumerar Funções e Nomes de Usuários em uma conta

Força Bruta para Assumir Função

Tentar assumir uma função sem as permissões necessárias aciona 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 do papel, mas indica que sua política de assunção de papel não permite sua assunção. Em contraste, tentar assumir um papel 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 funções existentes e não existentes é aplicável mesmo entre diferentes contas AWS. Com um ID de conta AWS válido e uma lista de palavras-alvo, é possível enumerar as funções presentes na conta sem enfrentar limitações inerentes.

Você pode usar este script para enumerar potenciais principais abusando desse problema.

Políticas de Confiança: Força Bruta de funções e usuários entre contas

Configurar ou atualizar a política de confiança de uma função IAM envolve definir quais recursos ou serviços AWS estão autorizados a assumir essa função e obter credenciais temporárias. Se o recurso especificado na política existe, a política de confiança é salva com sucesso. No entanto, 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 função que não existe. Se a função existir, a política será salva sem erros. (O erro é para atualização, mas também funciona 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

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 papel admin usado no exemplo é um papel na sua conta que pode ser impersonado pelo pacu para criar as políticas que ele precisa para a enumeração

Privesc

No caso de o papel estar mal configurado e permitir 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 fluxo de trabalho do Github Actions que está acessando um papel dentro da AWS.
Essa confiança pode dar acesso a um papel 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 fazer você desconfiar dela.
Isso ocorre porque o papel anterior pode ser assumido por QUALQUER UM do Github Actions! Você deve especificar nas condições também outras coisas, como nome da org, nome do repositório, env, brach...

Outra possível má configuração é adicionar uma condição como a seguinte:

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

Note que wildcard (*) antes do dois-pontos (:). Você pode criar uma org como org_name1 e assumir o papel a partir de uma Ação do Github.

Referências

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