# AWS - API Gateway Unauthenticated Enum

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

### Contournement de l'invocation de l'API

Selon la présentation [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), les Lambda Authorizers peuvent être configurés **en utilisant la syntaxe IAM** pour donner des permissions d'invocation des points de terminaison API. Cela est tiré [**de la documentation**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html):
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Permission",
"Action": ["execute-api:Execution-operation"],
"Resource": [
"arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path"
]
}
]
}
```
Le problème avec cette façon de donner des permissions pour invoquer des points de terminaison est que le **"\*" implique "tout"** et qu'il **n'y a plus de syntaxe regex supportée**.

Quelques exemples :

- Une règle telle que `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` afin de donner à chaque utilisateur accès à `/dashboard/user/{username}` leur donnera accès à d'autres routes telles que `/admin/dashboard/createAdmin` par exemple.

> [!WARNING]
> Notez que **"\*" ne cesse pas de s'étendre avec des barres obliques**, donc, si vous utilisez "\*" dans api-id par exemple, cela pourrait également indiquer "n'importe quelle étape" ou "n'importe quelle méthode" tant que la regex finale est toujours valide.\
> Donc `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\
> Peut valider une requête post pour tester l'étape au chemin `/prod/GET/dashboard/admin` par exemple.

Vous devez toujours avoir clairement en tête ce que vous souhaitez autoriser à accéder et ensuite vérifier si d'autres scénarios sont possibles avec les permissions accordées.

Pour plus d'infos, en plus des [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), vous pouvez trouver du code pour implémenter des autorisateurs dans [**ce github officiel aws**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints).

### Injection de politique IAM

Dans la même [**discussion**](https://www.youtube.com/watch?v=bsPKk7WDOnE), il est exposé que si le code utilise **l'entrée utilisateur** pour **générer les politiques IAM**, des jokers (et d'autres tels que "." ou des chaînes spécifiques) peuvent y être inclus dans le but de **contourner les restrictions**.

### Modèle d'URL publique
```
https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided}
```
### Obtenir l'ID de compte à partir de l'URL publique de l'API Gateway

Tout comme avec les buckets S3, Data Exchange et les URL de passerelles Lambda, il est possible de trouver l'ID de compte d'un compte en abusant de la **`aws:ResourceAccount`** **Policy Condition Key** à partir d'une URL publique de l'API Gateway. Cela se fait en trouvant l'ID de compte un caractère à la fois en abusant des jokers dans la section **`aws:ResourceAccount`** de la politique.\
Cette technique permet également d'obtenir **les valeurs des tags** si vous connaissez la clé du tag (il y en a quelques-unes par défaut intéressantes).

Vous pouvez trouver plus d'informations dans la [**recherche originale**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) et l'outil [**conditional-love**](https://github.com/plerionhq/conditional-love/) pour automatiser cette exploitation.

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