AWS - IAM Post Exploitation

Soutenez 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 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.

Par conséquent, lorsque vous autorisez un compte externe à 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 afin de prendre 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, toute personne pouvant lire la politique de prise de 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 :

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

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

Confiances Inattendues

Wildcard comme principal

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

Cette politique permet à tous les AWS d'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 permet à n'importe quel compte de configurer leur apigateway pour appeler ce Lambda.

S3 en tant que principal

"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 supprimez votre bucket et que l'attaquant le crée dans son propre compte, alors il pourrait en abuser.

Non supporté

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

Une façon courante d'é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

Soutenez HackTricks

Last updated