# AWS - IAM Post Exploitation

{{#include ../../../banners/hacktricks-training.md}}

## IAM

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

{{#ref}}
../aws-services/aws-iam-enum.md
{{#endref}}

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

<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>

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

- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)

{{#include ../../../banners/hacktricks-training.md}}
