AWS - IAM Post Exploitation

Reading time: 4 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

IAM

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

AWS - IAM, Identity Center & SSO Enum

Problème du Député Confus

Si vous permettez à un compte externe (A) d'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.

Par conséquent, lorsque vous permettez à un compte externe d'accéder à un rôle dans votre compte, il est possible de spécifier un ExternalId. C'est une chaîne "secrète" que le compte externe (A) doit spécifier pour 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" n'est pas un secret, quiconque peut lire la politique d'assumer le rôle IAM pourra le voir. Mais tant que le compte externe A le connaît, mais 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 :

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

Pour qu'un attaquant exploite un deputy confus, il devra trouver d'une manière ou d'une autre si les principaux du compte actuel peuvent usurper des rôles dans d'autres comptes.

Confiances inattendues

Wildcard comme principal

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

Cette politique permet à tous les AWS d'assumer le rôle.

Service en tant que principal

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

Cette politique permet à tout compte de configurer son apigateway pour appeler cette Lambda.

S3 en tant que principal

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

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

Non pris en charge

json
{
"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 l'utilisation d'une condition avec AWS:SourceArn pour vérifier l'ARN d'origine. Cependant, certains services pourraient ne pas le supporter (comme CloudTrail selon certaines sources).

Références

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks