AWS - IAM Post Exploitation

Reading time: 9 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

IAM

Para mais informações sobre o acesso IAM:

AWS - IAM, Identity Center & SSO Enum

Confused Deputy Problem

Se você permitir que uma conta externa (A) acesse uma role na sua conta, provavelmente terá 0 visibilidade sobre quem exatamente pode acessar essa conta externa. Isto é um problema, porque se outra conta externa (B) puder acessar a conta externa (A), é possível que B também consiga acessar sua conta.

Portanto, ao permitir que uma conta externa acesse uma role na sua conta, é possível especificar um ExternalId. Esta é uma string "secreta" que a conta externa (A) precisa especificar para assumir a role na sua organização. Como a conta externa B não conhecerá essa string, mesmo que ela tenha acesso à A, não poderá acessar sua role.

No entanto, note que esse "segredo" ExternalId não é um segredo; qualquer um que consiga ler a IAM assume role policy poderá vê-lo. Mas enquanto a conta externa A souber dele, e a conta externa B não souber, isso impede que B abuse de A para acessar sua role.

Exemplo:

json
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}

warning

Para que um attacker explore um confused deputy, ele precisará descobrir, de alguma forma, se os principals da conta atual podem impersonate roles em outras accounts.

Confianças inesperadas

Wildcard como principal

json
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" }
}

Esta política permite que toda a AWS assuma a função.

Serviço como principal

json
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}

Esta política permite que qualquer conta configure sua apigateway para chamar esta Lambda.

S3 como principal

json
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}

Se um bucket S3 for dado como principal, porque buckets S3 não têm um Account ID, se você excluiu seu bucket e o atacante o criou na própria conta dele, então ele poderia abusar disso.

Não suportado

json
{
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}

Uma forma comum de evitar problemas de Confused Deputy é usar uma condição com AWS:SourceArn para verificar o ARN de origem. No entanto, alguns serviços podem não suportar isso (como CloudTrail segundo algumas fontes).

Exclusão de credenciais

Com qualquer uma das seguintes permissões — iam:DeleteAccessKey, iam:DeleteLoginProfile, iam:DeleteSSHPublicKey, iam:DeleteServiceSpecificCredential, iam:DeleteInstanceProfile, iam:DeleteServerCertificate, iam:DeleteCloudFrontPublicKey, iam:RemoveRoleFromInstanceProfile — um ator pode remover chaves de acesso, perfis de login, chaves SSH, credenciais específicas de serviço, perfis de instância, certificados ou chaves públicas do CloudFront, ou desassociar roles de perfis de instância. Tais ações podem bloquear imediatamente usuários e aplicações legítimas e causar negação de serviço ou perda de acesso para sistemas que dependem dessas credenciais, portanto essas permissões IAM devem ser rigidamente restritas e monitoradas.

bash
# Remove Access Key of a user
aws iam delete-access-key \
--user-name <Username> \
--access-key-id AKIAIOSFODNN7EXAMPLE

## Remove ssh key of a user
aws iam delete-ssh-public-key \
--user-name <Username> \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE

Exclusão de Identidade

Com permissões como iam:DeleteUser, iam:DeleteGroup, iam:DeleteRole, ou iam:RemoveUserFromGroup, um agente pode excluir usuários, funções ou grupos — ou alterar a filiação a grupos — removendo identidades e rastros associados. Isso pode interromper imediatamente o acesso de pessoas e serviços que dependem dessas identidades, causando denial-of-service ou perda de acesso, portanto essas ações do IAM devem ser rigidamente restritas e monitoradas.

bash
# Delete a user
aws iam delete-user \
--user-name <Username>

# Delete a group
aws iam delete-group \
--group-name <Username>

# Delete a role
aws iam delete-role \
--role-name <Role>

Com qualquer uma das seguintes permissões — iam:DeleteGroupPolicy, iam:DeleteRolePolicy, iam:DeleteUserPolicy, iam:DeletePolicy, iam:DeletePolicyVersion, iam:DeleteRolePermissionsBoundary, iam:DeleteUserPermissionsBoundary, iam:DetachGroupPolicy, iam:DetachRolePolicy, iam:DetachUserPolicy — um ator pode excluir ou desanexar políticas gerenciadas/inline, remover versões de políticas ou limites de permissões, e desvincular políticas de usuários, grupos ou funções. Isso destrói autorizações e pode alterar o modelo de permissões, causando perda imediata de acesso ou negação de serviço para entidades que dependiam dessas políticas, portanto essas ações do IAM devem ser estritamente restritas e monitoradas.

bash
# Delete a group policy
aws iam delete-group-policy \
--group-name <GroupName> \
--policy-name <PolicyName>

# Delete a role policy
aws iam delete-role-policy \
--role-name <RoleName> \
--policy-name <PolicyName>

Exclusão de Identidade Federada

Com iam:DeleteOpenIDConnectProvider, iam:DeleteSAMLProvider e iam:RemoveClientIDFromOpenIDConnectProvider, um ator pode excluir provedores de identidade OIDC/SAML ou remover client IDs. Isso interrompe a autenticação federada, impedindo a validação de tokens e negando imediatamente o acesso a usuários e serviços que dependem de SSO até que o IdP ou as configurações sejam restaurados.

bash
# Delete OIDCP provider
aws iam delete-open-id-connect-provider \
--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com

# Delete SAML provider
aws iam delete-saml-provider \
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS

Ativação ilegítima de MFA

Com iam:EnableMFADevice, um agente pode registrar um dispositivo MFA na identidade do usuário, impedindo que o usuário legítimo efetue login. Uma vez que um MFA não autorizado seja habilitado, o usuário pode ficar bloqueado até que o dispositivo seja removido ou redefinido (nota: se vários dispositivos MFA estiverem registrados, o login exige apenas um, portanto este ataque não terá efeito para negar acesso).

bash
aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

Manipulação de Metadados de Certificado/Chave

Com iam:UpdateSSHPublicKey, iam:UpdateCloudFrontPublicKey, iam:UpdateSigningCertificate, iam:UpdateServerCertificate, um atacante pode alterar o status ou os metadados de chaves públicas e certificados. Ao marcar chaves/certificados como inativos ou alterar referências, ele pode quebrar a autenticação SSH, invalidar validações X.509/TLS e interromper imediatamente serviços que dependem dessas credenciais, causando perda de acesso ou disponibilidade.

bash
aws iam update-ssh-public-key \
--user-name <Username> \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
--status Inactive

aws iam update-server-certificate \
--server-certificate-name <Certificate_Name> \
--new-path /prod/

iam:Delete*

O curinga IAM iam:Delete* concede a capacidade de remover muitos tipos de recursos IAM — usuários, funções, grupos, políticas, chaves, certificados, dispositivos MFA, versões de políticas, etc. — e, portanto, tem um raio de impacto muito alto: um ator com iam:Delete* pode destruir permanentemente identidades, credenciais, políticas e artefatos relacionados, remover auditoria/evidência e causar interrupções de serviço ou operacionais. Alguns exemplos são

bash
# Delete a user
aws iam delete-user --user-name <Username>

# Delete a role
aws iam delete-role --role-name <RoleName>

# Delete a managed policy
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>

iam:EnableMFADevice

Um ator com a permissão iam:EnableMFADevice pode registrar um MFA device em uma identidade na conta, desde que o usuário não tivesse já um habilitado. Isso pode ser usado para interferir no acesso de um usuário: uma vez que um attacker registre um MFA device, o usuário legítimo pode ser impedido de fazer login porque não controla o MFA registrado pelo attacker.

Esse ataque de negação de acesso só funciona se o usuário não tivesse nenhum MFA registrado; se o attacker registrar um MFA device para esse usuário, o usuário legítimo ficará bloqueado em qualquer fluxo que exija esse novo MFA. Se o usuário já tiver um ou mais MFA devices sob seu controle, adicionar um MFA controlado pelo attacker não bloqueia o usuário legítimo — ele pode continuar a autenticar-se usando qualquer MFA que já possua.

Para habilitar (registrar) um MFA device para um usuário, um attacker poderia executar:

bash
aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

Referências

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