AWS - STS Privesc

Reading time: 6 minutes

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

STS

sts:AssumeRole

Cada role é criado com uma política de confiança da role, essa política indica quem pode assumir a role criada. Se uma role da mesma conta indicar que uma conta pode assumi-la, isso significa que a conta poderá acessar a role (e potencialmente privesc).

Por exemplo, a seguinte política de confiança da role indica que qualquer pessoa pode assumi-la, portanto qualquer usuário poderá privesc para as permissões associadas a essa role.

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

Você pode se passar por uma role executando:

bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname

Impacto Potencial: Privesc para o role.

caution

Note que neste caso a permissão sts:AssumeRole precisa estar indicada no role a ser abusado e não em uma policy pertencente ao atacante.
Com uma exceção, para assumir um role de uma conta diferente a conta do atacante também precisa ter o sts:AssumeRole sobre o role.

sts:AssumeRoleWithSAML

Uma trust policy com este role concede a usuários autenticados via SAML acesso para impersonar o role.

Um exemplo de uma trust policy com essa permissão é:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "OneLogin",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}

Para gerar credenciais para impersonar a role, em geral você pode usar algo como:

bash
aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>

Mas os provedores podem ter suas próprias ferramentas para facilitar isso, como onelogin-aws-assume-role:

bash
onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600

Impacto Potencial: Privesc to the role.

sts:AssumeRoleWithWebIdentity

Esta permissão permite obter um conjunto de credenciais de segurança temporárias para usuários que foram autenticados em um aplicativo móvel, web, EKS... com um provedor de identidade web. Learn more here.

Por exemplo, se uma EKS service account deveria poder se passar por um IAM role, ela terá um token em /var/run/secrets/eks.amazonaws.com/serviceaccount/token e pode assumir o role e obter credenciais fazendo algo como:

bash
aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
# The role name can be found in the metadata of the configuration of the pod

Federation Abuse

AWS - Federation Abuse

IAM Roles Anywhere Privesc

AWS IAM RolesAnywhere permite que cargas de trabalho fora da AWS assumam IAM roles usando certificados X.509. Mas quando as trust policies não estão corretamente limitadas, elas podem ser abusadas para privilege escalation.

Para entender este ataque, é necessário explicar o que é um trust anchor. Um trust anchor no AWS IAM RolesAnywhere é a entidade raiz de confiança: ele contém o certificado público de uma Certificate Authority (CA) registrada na conta para que a AWS possa validar os certificados X.509 apresentados. Dessa forma, se o certificado do cliente foi emitido por essa CA e o trust anchor estiver ativo, a AWS o reconhecerá como válido.

Além disso, um profile é a configuração que define quais atributos do certificado X.509 (como CN, OU ou SAN) serão transformados em session tags, e essas tags serão posteriormente comparadas com as condições da trust policy.

Esta policy não impõe restrições sobre quais trust anchors ou atributos de certificado são permitidos. Como resultado, qualquer certificado vinculado a qualquer trust anchor na conta pode ser usado para assumir este role.

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}

Para privesc, o aws_signing_helper é necessário e pode ser obtido em https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html

Então, usando um certificado válido, o atacante pode pivot para um role com privilégios mais altos.

bash
aws_signing_helper credential-process \
--certificate readonly.pem \
--private-key readonly.key \
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin

A âncora de confiança valida que o certificado do cliente readonly.pem provém da sua CA autorizada, e dentro desse certificado readonly.pem está a chave pública que a AWS usa para verificar que a assinatura foi feita com a correspondente chave privada readonly.key.

O certificado também fornece atributos (como CN ou OU) que o perfil default transforma em tags, que a política de confiança da role pode usar para decidir se autoriza o acesso. Se não houver condições na política de confiança, essas tags não têm utilidade, e o acesso é concedido a qualquer pessoa com um certificado válido.

Para que este ataque seja possível, tanto a âncora de confiança quanto o perfil default devem estar ativos.

References

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks