AWS - IAM Post Exploitation

Reading time: 9 minutes

IAM

Pour plus d'informations sur l'accès IAM :

AWS - IAM, Identity Center & SSO Enum

Problème du Confused Deputy

Si vous autorisez un compte externe (A) à accéder à un rôle dans votre compte, vous aurez probablement 0 visibilité sur qui peut exactement accéder à ce compte externe. C'est un problème, car si un autre compte externe (B) peut accéder au compte externe (A), il est possible que B puisse également accéder à votre compte.

Donc, lorsque vous autorisez un compte externe à accéder à un rôle dans votre compte, il est possible de spécifier un ExternalId. Il s'agit d'une chaîne "secrète" que le compte externe (A) doit spécifier afin de assumer le rôle dans votre organisation. Comme le compte externe B ne connaîtra pas cette chaîne, même s'il a accès à A, il ne pourra pas accéder à votre rôle.

Cependant, notez que ce ExternalId "secret" est n'est pas un secret, quiconque peut lire la IAM assume role policy pourra le voir. Mais tant que le compte externe A le connaît, et que le compte externe B ne le connaît pas, cela empêche B d'abuser de A pour accéder à votre rôle.

Exemple:

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

Confiances inattendues

Wildcard en tant que principal

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

Cette politique autorise l'ensemble d'AWS à assumer le rôle.

Service en tant que principal

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

Cette politique autorise n'importe quel compte à configurer son apigateway pour appeler cette Lambda.

S3 en tant que principal

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

Si un S3 bucket est donné comme principal, puisque les S3 buckets n'ont pas d'Account ID, si vous avez supprimé votre bucket et que l'attaquant l'a recréé dans son propre compte, alors il pourrait en abuser.

Non pris en charge

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

Une méthode courante pour éviter les problèmes de Confused Deputy est d'utiliser une condition avec AWS:SourceArn pour vérifier l'ARN d'origine. Cependant, certains services peuvent ne pas le prendre en charge (comme CloudTrail d'après certaines sources).

Suppression des identifiants

Avec l'une des permissions suivantes — iam:DeleteAccessKey, iam:DeleteLoginProfile, iam:DeleteSSHPublicKey, iam:DeleteServiceSpecificCredential, iam:DeleteInstanceProfile, iam:DeleteServerCertificate, iam:DeleteCloudFrontPublicKey, iam:RemoveRoleFromInstanceProfile — un acteur peut supprimer access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates ou CloudFront public keys, ou dissocier des rôles des instance profiles. De telles actions peuvent immédiatement bloquer des utilisateurs et applications légitimes et provoquer un déni de service ou une perte d'accès pour les systèmes qui dépendent de ces credentials ; ces permissions IAM doivent donc être strictement restreintes et surveillées.

# 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

Suppression d'identités

Avec des permissions telles que iam:DeleteUser, iam:DeleteGroup, iam:DeleteRole ou iam:RemoveUserFromGroup, un acteur peut supprimer des users, roles ou groups — ou modifier la group membership — supprimant des identités et les traces associées. Cela peut immédiatement interrompre l'accès pour les personnes et les services qui dépendent de ces identités, provoquant un denial-of-service ou une perte d'accès ; ces actions IAM doivent donc être strictement restreintes et surveillées.

# 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>

Avec l'une des permissions suivantes — iam:DeleteGroupPolicy, iam:DeleteRolePolicy, iam:DeleteUserPolicy, iam:DeletePolicy, iam:DeletePolicyVersion, iam:DeleteRolePermissionsBoundary, iam:DeleteUserPermissionsBoundary, iam:DetachGroupPolicy, iam:DetachRolePolicy, iam:DetachUserPolicy — un acteur peut supprimer ou détacher des politiques gérées/intégrées, supprimer des versions de politique ou des limites de permissions, et dissocier des politiques d'utilisateurs, de groupes ou de rôles. Cela détruit des autorisations et peut altérer le modèle de permissions, provoquant une perte d'accès immédiate ou un déni de service pour les entités qui dépendaient de ces politiques, donc ces actions IAM doivent être strictement restreintes et surveillées.

# 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>

Suppression d'identité fédérée

Avec iam:DeleteOpenIDConnectProvider, iam:DeleteSAMLProvider et iam:RemoveClientIDFromOpenIDConnectProvider, un acteur peut supprimer des fournisseurs d'identité OIDC/SAML ou retirer des client IDs. Cela interrompt l'authentification fédérée, empêche la validation des tokens et refuse immédiatement l'accès aux utilisateurs et services qui reposent sur SSO jusqu'à ce que l'IdP ou les configurations soient restaurés.

# 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

Activation illégitime de MFA

Avec iam:EnableMFADevice, un attaquant peut enregistrer un dispositif MFA sur l’identité d’un utilisateur, empêchant l’utilisateur légitime de se connecter. Une fois qu’un MFA non autorisé est activé, l’utilisateur peut être verrouillé jusqu’à ce que le dispositif soit retiré ou réinitialisé (remarque : si plusieurs dispositifs MFA sont enregistrés, la connexion ne requiert qu’un seul, donc cette attaque n’aura aucun effet pour empêcher l’accès).

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

Altération des métadonnées de certificats/clés

Avec iam:UpdateSSHPublicKey, iam:UpdateCloudFrontPublicKey, iam:UpdateSigningCertificate, iam:UpdateServerCertificate, un acteur peut modifier le statut ou les métadonnées des clés publiques et des certificats.
En marquant les clés/certificats comme inactifs ou en altérant leurs références, il peut interrompre l'authentification SSH, invalider les validations X.509/TLS, et perturber immédiatement les services qui dépendent de ces identifiants, entraînant une perte d'accès ou de disponibilité.

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*

La wildcard IAM iam:Delete* accorde la capacité de supprimer de nombreux types de ressources IAM — users, roles, groups, policies, keys, certificates, MFA devices, policy versions, etc. — et a donc un rayon d'impact très élevé : un acteur auquel iam:Delete* est accordé peut détruire définitivement des identities, credentials, policies et artefacts associés, supprimer des audits/preuves, et provoquer des interruptions de service ou des pannes opérationnelles. Quelques exemples :

# 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

Un acteur disposant de l'action iam:EnableMFADevice peut enregistrer un appareil MFA sur une identity dans le account, à condition que le user n'en ait pas déjà un activé. Cela peut être utilisé pour perturber l'accès d'un user : une fois qu'un attacker enregistre un appareil MFA, le user légitime peut être empêché de sign in parce qu'il ne contrôle pas l'appareil MFA enregistré par l'attacker.

Cette attaque de déni d'accès ne fonctionne que si le user n'avait aucun MFA enregistré ; si l'attacker enregistre un appareil MFA pour ce user, le user légitime sera verrouillé hors de tous les flows qui exigent ce nouveau MFA. Si le user possède déjà un ou plusieurs appareils MFA sous son contrôle, l'ajout d'un MFA contrôlé par l'attacker ne bloque pas le user légitime — il peut continuer à s'authentifier en utilisant n'importe quel MFA qu'il possède déjà.

Pour enable (register) un appareil MFA pour un user un attacker pourrait exécuter :

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

Références

• https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html