From 3a0a9a22cac2bd9d9eb04fa34db4a9c7fb94f015 Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 14 Feb 2026 19:50:09 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation --- .../aws-s3-post-exploitation/README.md | 67 +++++++++++++++---- 1 file changed, 53 insertions(+), 14 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md index 58d2de763..861ae66dc 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md @@ -1,41 +1,80 @@ -# AWS - S3 Post-Exploitation +# AWS - S3 Post Exploitation {{#include ../../../../banners/hacktricks-training.md}} ## S3 -Pour plus d'informations, consultez : +For more information check: {{#ref}} ../../aws-services/aws-s3-athena-and-glacier-enum.md {{#endref}} -### Informations sensibles +### Sensitive Information -Parfois, vous pourrez trouver des informations sensibles lisibles dans les buckets. Par exemple, terraform state secrets. +Parfois, vous pourrez trouver des informations sensibles lisibles dans les buckets. Par exemple, des secrets d'état terraform. ### Pivoting -Différentes plateformes peuvent utiliser S3 pour stocker des ressources sensibles. -Par exemple, **airflow** pourrait y stocker le **DAGs** **code**, ou des **web pages** pourraient être servies directement depuis S3. Un attaquant disposant d'autorisations d'écriture pourrait **modify the code** depuis le bucket pour **pivot** vers d'autres plateformes, ou **takeover accounts** en modifiant des fichiers JS. +Different platforms could be using S3 to store sensitive assets.\ +For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. Un attaquant disposant de permissions d'écriture pourrait **modifier le code** depuis le bucket pour **pivot** vers d'autres plateformes, ou **takeover accounts** en modifiant des fichiers JS. ### S3 Ransomware -Dans ce scénario, l'attaquant crée une **KMS (Key Management Service) key dans son propre compte AWS** ou dans un autre compte compromis. Il rend ensuite cette **key accessible à n'importe quel utilisateur, rôle ou compte dans le monde**, permettant à tout utilisateur, rôle ou compte AWS de chiffrer des objets avec cette key. Cependant, les objets ne peuvent pas être déchiffrés. +Dans ce scénario, l'**attaquant crée une clé KMS (Key Management Service) dans son propre compte AWS** ou dans un autre compte compromis. Il rend ensuite cette **clé accessible à n'importe qui dans le monde**, permettant à tout utilisateur, rôle ou compte AWS de chiffrer des objets avec cette clé. Cependant, les objets ne peuvent pas être déchiffrés. -L'attaquant identifie un bucket S3 cible et obtient un accès en écriture dessus en utilisant diverses méthodes. Cela peut être dû à une mauvaise configuration du bucket qui l'expose publiquement ou à l'accès de l'attaquant à l'environnement AWS lui-même. L'attaquant cible généralement des buckets contenant des informations sensibles telles que des PII, PHI, des logs, des backups, etc. +L'attaquant identifie un **S3 bucket** cible et obtient un accès en écriture dessus en utilisant diverses méthodes. Cela peut être dû à une mauvaise configuration du bucket l'exposant publiquement ou à l'accès de l'attaquant à l'environnement AWS lui-même. L'attaquant cible généralement les buckets contenant des informations sensibles telles que PII, PHI, les logs, les backups, et plus encore. -Pour déterminer si le bucket peut être ciblé pour du ransomware, l'attaquant vérifie sa configuration. Cela inclut la vérification si **S3 Object Versioning** est activé et si **multi-factor authentication delete (MFA delete)** est activé. Si Object Versioning n'est pas activé, l'attaquant peut continuer. Si Object Versioning est activé mais que MFA delete est désactivé, l'attaquant peut **disable Object Versioning**. Si Object Versioning et MFA delete sont tous deux activés, il devient plus difficile pour l'attaquant de chiffrer ce bucket spécifique avec un ransomware. +Pour déterminer si le bucket peut être ciblé pour du ransomware, l'attaquant vérifie sa configuration. Cela inclut la vérification si **S3 Object Versioning** est activé et si la **multi-factor authentication delete (MFA delete)** est activée. Si Object Versioning n'est pas activé, l'attaquant peut procéder. Si Object Versioning est activé mais que MFA delete est désactivé, l'attaquant peut **désactiver Object Versioning**. Si à la fois Object Versioning et MFA delete sont activés, il devient plus difficile pour l'attaquant d'exécuter un ransomware sur ce bucket spécifique. -En utilisant l'API AWS, l'attaquant **remplace chaque objet dans le bucket par une copie chiffrée utilisant leur KMS key**. Cela chiffre effectivement les données du bucket, les rendant inaccessibles sans la key. +En utilisant l'API AWS, l'attaquant **remplace chaque objet du bucket par une copie chiffrée utilisant sa clé KMS**. Cela chiffre effectivement les données du bucket, les rendant inaccessibles sans la clé. -Pour mettre davantage de pression, l'attaquant planifie la suppression de la KMS key utilisée dans l'attaque. Cela donne à la cible une fenêtre de 7 jours pour récupérer ses données avant que la key soit supprimée et que les données deviennent définitivement perdues. +Pour exercer une pression supplémentaire, l'attaquant planifie la suppression de la clé KMS utilisée dans l'attaque. Cela donne à la cible une fenêtre de 7 jours pour récupérer ses données avant que la clé soit supprimée et que les données deviennent irrémédiablement perdues. -Enfin, l'attaquant peut téléverser un fichier final, généralement nommé "ransom-note.txt", qui contient des instructions pour la cible sur la façon de récupérer ses fichiers. Ce fichier est téléversé sans chiffrement, probablement pour attirer l'attention de la cible et l'informer de l'attaque. +Enfin, l'attaquant peut uploader un fichier final, généralement nommé "ransom-note.txt", qui contient des instructions pour la cible sur la manière de récupérer ses fichiers. Ce fichier est uploadé sans chiffrement, probablement pour attirer l'attention de la cible et l'informer de l'attaque de ransomware. + +#### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like) + +Une autre variante abuse de **SSE-C** (S3 server-side encryption with **customer-provided keys**). Avec SSE-C, le **client fournit la clé de chiffrement à chaque requête** et **AWS ne stocke pas la clé**. Cela signifie que si un attaquant réécrit des objets en utilisant **sa propre clé SSE-C**, les données de la victime deviennent illisibles à moins que la victime puisse fournir cette clé contrôlée par l'attaquant. + +- **Preconditions:** Compromised AWS credentials (or any principal with the right permissions) and the ability to **rewrite objects** (e.g., `s3:PutObject` on the target keys/prefixes). This is often paired with the ability to set destructive lifecycle policies (see below), e.g. `s3:PutLifecycleConfiguration`. +- **Attack chain:** +1. Attacker generates a random 256-bit key (AES-256) and keeps it. +2. Attacker **rewrites** existing objects (same object keys) using SSE-C headers so the stored object is now encrypted with the attacker key. +3. Victim cannot download/decrypt without providing the SSE-C key (even if IAM permissions are fine). +4. Attacker can delete the key (or simply never provide it) to make data unrecoverable. + +Example (conceptual) CLI usage: +```bash +# Upload/overwrite an object encrypted with attacker-provided SSE-C key +aws s3 cp ./file s3:/// \ +--sse-c AES256 \ +--sse-c-key + +# Download requires providing the same key again +aws s3 cp s3:/// ./file \ +--sse-c AES256 \ +--sse-c-key +``` +##### Ajouter de la pression : abus du "timer" de cycle de vie + +Pour supprimer les options de récupération (comme les anciennes versions), un attaquant peut associer des réécritures SSE-C à des **règles de cycle de vie** qui expirent les objets et/ou suppriment les versions non actuelles après une courte période : + +- `s3:PutLifecycleConfiguration` sur le bucket permet à un attaquant de programmer des suppressions sans émettre d'opérations delete explicites pour chaque objet/version. +- Ceci est particulièrement impactant lorsque **la gestion des versions est activée**, car cela peut supprimer l'ancienne version valide qui permettrait autrement la récupération. + +##### Détection & atténuations + +- Préférez **SSE-KMS** (ou SSE-S3) à SSE-C sauf si vous avez une raison opérationnelle solide d'autoriser SSE-C. +- Surveillez/alertez les requêtes `PutObject` utilisant des en-têtes SSE-C (CloudTrail data events pour S3). +- Surveillez/alertez les `PutBucketLifecycleConfiguration` inattendus (changements de lifecycle). +- Surveillez/alertez les pics soudains d'activité d'écrasement (mêmes clés mises à jour rapidement) et les suppressions de delete-marker/version. +- Restreindre les permissions à haut risque : limitez `s3:PutObject` aux préfixes nécessaires ; restreignez fortement `s3:PutLifecycleConfiguration` et `s3:PutBucketVersioning` ; envisagez d'exiger MFA pour les actions d'administration sensibles (lorsque applicable) et utilisez des rôles admin séparés avec approbations. +- Posture de récupération : utilisez **versioning**, **backups**, et des copies immuables/hors ligne (S3 replication vers un compte protégé, backup vaults, etc.) ; protégez les versions non actuelles contre les suppressions agressives et protégez les changements de lifecycle avec des SCPs / guardrails. ### `s3:RestoreObject` -Un attaquant disposant de la permission s3:RestoreObject peut réactiver des objets archivés dans Glacier ou Deep Archive, les rendant temporairement accessibles. Cela permet la récupération et l'exfiltration de données historiquement archivées (backups, snapshots, logs, certifications, vieux secrets) qui seraient normalement hors de portée. Si l'attaquant combine cette permission avec des permissions de lecture (par exemple, s3:GetObject), il peut obtenir des copies complètes de données sensibles. +Un attaquant disposant de la permission `s3:RestoreObject` peut réactiver des objets archivés dans Glacier ou Deep Archive, les rendant temporairement accessibles. Cela permet la récupération et l'exfiltration de données archivées historiquement (sauvegardes, snapshots, logs, certifications, anciens secrets) qui seraient normalement hors de portée. Si l'attaquant combine cette permission avec des permissions de lecture (par ex., `s3:GetObject`), il peut obtenir des copies complètes de données sensibles. ```bash aws s3api restore-object \ --bucket \ @@ -47,7 +86,7 @@ aws s3api restore-object \ ``` ### `s3:Delete*` -Un attaquant disposant de la permission s3:Delete* peut supprimer des objets, des versions et des buckets entiers, perturber les sauvegardes et provoquer une perte de données immédiate et irréversible, la destruction de preuves et la compromission des artefacts de sauvegarde ou de récupération. +Un attaquant disposant de la permission s3:Delete* peut supprimer des objets, des versions et des buckets entiers, perturber les sauvegardes et provoquer une perte de données immédiate et irréversible, la destruction de preuves et la compromission d'artefacts de sauvegarde ou de récupération. ```bash # Delete an object from a bucket aws s3api delete-object \