DynamoDB writes are actually reads

DynamoDB read operations like "GetItem", "Query", and "Scan" aren’t the only way to retrieve data.

🚨 Most people think they are. Most people are wrong.

Some write operations can also return data, and if you're not careful, you might be leaking information without even realizing it.

🚀 PutItem, UpdateItem, and DeleteItem can return data when "ReturnValues" is set.

✅ "PutItem" with "ReturnValues=ALL_OLD" returns the previous item if it existed.
✅ "UpdateItem" with "ReturnValues=ALL_OLD" returns the item before the update.
✅ "UpdateItem" with "ReturnValues=ALL_NEW" returns the item after the update.
✅ "DeleteItem" with "ReturnValues=ALL_OLD" returns the deleted item.

If you're only watching read operations, you might be missing a backdoor to data retrieval through writes.

🤔 What happens if a condition check fails? Can you still get data?

❌ No. If a condition check fails, the operation does not execute and no data is returned, even if "ReturnValues" is set.
❌ This applies to "PutItem", "UpdateItem", and "DeleteItem". If the condition expression is false, the request fails with "ConditionalCheckFailedException" and nothing is returned.
❌ Example: If "UpdateItem" includes "ConditionExpression=attribute_exists(id)" but the item does not exist, the operation fails and returns nothing.

🔍 CloudTrail does log "ReturnValues", but only if you enable DynamoDB data events.

🛑 Without data events, you’ll only see table-level operations like table creation and deletion, not individual item writes.
🛑 If "ReturnValues" was used, it appears in the "requestParameters" section of the log:
- Example: "returnValues": "ALL_OLD" in an "UpdateItem" log entry.
🛑 If you're not tracking this, you might miss an attacker extracting old data via writes.

🚧 Want to prevent data leaks? Use IAM to block or restrict "ReturnValues".

🛑 Deny any request that sets "ReturnValues" to anything other than "NONE". Example IAM condition:
"Condition": { "StringNotEqualsIfExists": { "dynamodb:ReturnValues": "NONE" } }
🛑 Limit "UpdateItem" and "DeleteItem" permissions to trusted roles.
🛑 Monitor CloudTrail for "ReturnValues=ALL_OLD" or "ALL_NEW" to detect possible data exfiltration.

DynamoDB write operations can expose data in ways many people don’t expect. If you're only watching "GetItem", you're missing part of the story.

📌 Everything you need to do it yourself and understand why it works

🔗 Condition keys for DynamoDB: https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-dynamodb_ReturnValues

🔗 PutItem: https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html

🔗 UpdateItem: https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateItem.html

🔗 DeleteItem: https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DeleteItem.html

☁️ You can't expect to know all the weird quirks and exploits of AWS, even if they've been around for almost 10 years.

But you can start a free trial of Plerion at any time to understand your AWS security posture. All you need is an email address.

Sign up at https://www.plerion.com/

Видео DynamoDB writes are actually reads канала Plerion