Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Amazon DynamoDB is presented by AWS as a fully managed, serverless, key-value NoSQL database, tailored for powering high-performance applications regardless of their size. The service ensures robust features including inherent security measures, uninterrupted backups, automated replication across multiple regions, integrated in-memory caching, and convenient data export utilities.
In the context of DynamoDB, instead of establishing a traditional database, tables are created. Each table mandates the specification of a partition key as an integral component of the table's primary key. This partition key, essentially a hash value, plays a critical role in both the retrieval of items and the distribution of data across various hosts. This distribution is pivotal for maintaining both scalability and availability of the database. Additionally, there's an option to incorporate a sort key to further refine data organization.
By default, DynamoDB uses a KMS key that **belongs to Amazon DynamoDB,**not even the AWS managed key that at least belongs to your account.
It's possible to schedule the generation of table backups or create them on demand. Moreover, it's also possible to enable Point-in-time recovery (PITR) for a table. Point-in-time recovery provides continuous backups of your DynamoDB data for 35 days to help you protect against accidental write or delete operations.
It's also possible to export the data of a table to S3, but the table needs to have PITR enabled.
There is a GUI for local Dynamo services like DynamoDB Local, dynalite, localstack, etc, that could be useful: https://github.com/aaronshaf/dynamodb-admin
There are ways to access DynamoDB data with SQL syntax, therefore, typical SQL injections are also possible.
In DynamoDB different conditions can be used to retrieve data, like in a common NoSQL Injection if it's possible to chain more conditions to retrieve data you could obtain hidden data (or dump the whole table). You can find here the conditions supported by DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html
Note that different conditions are supported if the data is being accessed via query or via scan.
Actually, Query actions need to specify the condition "EQ" (equals) in the primary key to works, making it much less prone to NoSQL injections (and also making the operation very limited).
If you can change the comparison performed or add new ones, you could retrieve more data.
This vulnerability is based on dynamodb Scan Filter which is now deprecated!
DynamoDB accepts Json objects to search for data inside the DB. If you find that you can write in the json object sent to search, you could make the DB dump, all the contents.
For example, injecting in a request like:
an attacker could inject something like:
1000"}],"ComparisonOperator": "GT","AttributeValueList": [{"N": "0
fix the "EQ" condition searching for the ID 1000 and then looking for all the data with a Id string greater and 0, which is all.
Another vulnerable example using a login could be:
This would be vulnerable to:
Some SDKs allows to use a string indicating the filtering to be performed like:
You need to know that searching in DynamoDB for substituting an attribute value in filter expressions while scanning the items, the tokens should begin with the : character. Such tokens will be replaced with actual attribute value at runtime.
Therefore, a login like the previous one can be bypassed with something like:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
