Translated ['', 'src/pentesting-cloud/aws-security/aws-services/aws-s3-a

This commit is contained in:
Translator
2026-02-12 13:05:57 +00:00
parent 5ef58236bc
commit 534611e304
@@ -6,34 +6,34 @@
Amazon S3 est un service qui vous permet de **stocker de grandes quantités de données**.
Amazon S3 fournit plusieurs options pour atteindre la **protection** des données au repos. Les options incluent **Permission** (Politique), **Encryption** (Côté Client et Côté Serveur), **Bucket Versioning** et **MFA** **basé sur la suppression**. L'**utilisateur peut activer** l'une de ces options pour atteindre la protection des données. La **réplication des données** est une fonctionnalité interne d'AWS où **S3 réplique automatiquement chaque objet à travers toutes les zones de disponibilité** et l'organisation n'a pas besoin de l'activer dans ce cas.
Amazon S3 fournit plusieurs options pour assurer la **protection** des données au repos. Les options incluent **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** et **MFA** **based delete**. L'**utilisateur peut activer** n'importe laquelle de ces options pour assurer la protection des données. La **réplication des données** est une fonctionnalité interne d'AWS où **S3 réplique automatiquement chaque objet à travers toutes les Availability Zones** et l'organisation n'a pas besoin de l'activer dans ce cas.
Avec des permissions basées sur les ressources, vous pouvez définir des permissions pour les sous-répertoires de votre bucket séparément.
Avec des permissions basées sur les ressources, vous pouvez définir séparément les permissions pour des sous-répertoires de votre bucket.
### Bucket Versioning et suppression basée sur MFA
### Bucket Versioning and MFA based delete
Lorsque le versionnage de bucket est activé, toute action qui tente de modifier un fichier à l'intérieur d'un fichier générera une nouvelle version du fichier, conservant également le contenu précédent de celui-ci. Par conséquent, cela ne remplacera pas son contenu.
When Bucket Versioning is enabled, any action that tries to alter a file inside a file will generate a new version of the file, keeping also the previous content of the same. Therefore, it won't overwrite its content.
De plus, la suppression basée sur MFA empêchera les versions de fichiers dans le bucket S3 d'être supprimées et également le versionnage de bucket d'être désactivé, donc un attaquant ne pourra pas modifier ces fichiers.
Moreover, MFA based delete will prevent versions of file in the S3 bucket from being deleted and also Bucket Versioning from being disabled, so an attacker won't be able to alter these files.
### Journaux d'accès S3
### S3 Access logs
Il est possible d'**activer la connexion d'accès S3** (qui est désactivée par défaut) pour un certain bucket et de sauvegarder les journaux dans un autre bucket pour savoir qui accède au bucket (les deux buckets doivent être dans la même région).
Il est possible d'**activer S3 access logging** (qui est désactivé par défaut) pour un bucket et d'enregistrer les logs dans un bucket différent afin de savoir qui accède au bucket (les deux buckets doivent être dans la même région).
### URLs pré-signées S3
### S3 Presigned URLs
Il est possible de générer une URL pré-signée qui peut généralement être utilisée pour **accéder au fichier spécifié** dans le bucket. Une **URL pré-signée ressemble à ceci** :
Il est possible de générer une presigned URL qui peut généralement être utilisée pour **accéder au fichier spécifié** dans le bucket. Une **presigned URL ressemble à ceci**:
```
https://<bucket-name>.s3.us-east-1.amazonaws.com/asd.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUUE8GZC4S5L3TY3P%2F20230227%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230227T142551Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjELf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIBhQpdETJO3HKKDk2hjNIrPWwBE8gZaQccZFV3kCpPCWAiEAid3ueDtFFU%2FOQfUpvxYTGO%2BHoS4SWDMUrQAE0pIaB40qggMIYBAAGgwzMTgxNDIxMzg1NTMiDJLI5t7gr2EGxG1Y5CrfAioW0foHIQ074y4gvk0c%2B%2Fmqc7cNWb1njQslQkeePHkseJ3owzc%2FCwkgE0EuZTd4mw0aJciA2XIbJRCLPWTb%2FCBKPnIMJ5aBzIiA2ltsiUNQTTUxYmEgXZoJ6rFYgcodnmWW0Et4Xw59UlHnCDB2bLImxPprriyCzDDCD6nLyp3J8pFF1S8h3ZTJE7XguA8joMs4%2B2B1%2FeOZfuxXKyXPYSKQOOSbQiHUQc%2BFnOfwxleRL16prWk1t7TamvHR%2Bt3UgMn5QWzB3p8FgWwpJ6GjHLkYMJZ379tkimL1tJ7o%2BIod%2FMYrS7LDCifP9d%2FuYOhKWGhaakPuJKJh9fl%2B0vGl7kmApXigROxEWon6ms75laXebltsWwKcKuYca%2BUWu4jVJx%2BWUfI4ofoaGiCSaKALTqwu4QNBRT%2BMoK6h%2BQa7gN7JFGg322lkxRY53x27WMbUE4unn5EmI54T4dWt1%2Bg8ljDS%2BvKfBjqmAWRwuqyfwXa5YC3xxttOr3YVvR6%2BaXpzWtvNJQNnb6v0uI3%2BTtTexZkJpLQYqFcgZLQSxsXWSnf988qvASCIUhAzp2UnS1uqy7QjtD5T73zksYN2aesll7rvB80qIuujG6NOdHnRJ2M5%2FKXXNo1Yd15MtzPuSjRoSB9RSMon5jFu31OrQnA9eCUoawxbB0nHqwK8a43CKBZHhA8RoUAJW%2B48EuFsp3U%3D&X-Amz-Signature=3436e4139e84dbcf5e2e6086c0ebc92f4e1e9332b6fda24697bc339acbf2cdfa
```
Une URL pré-signée peut être **créée depuis le cli en utilisant les identifiants d'un principal ayant accès à l'objet** (si le compte que vous utilisez n'a pas accès, une URL pré-signée plus courte sera créée mais elle sera inutile)
Une URL présignée peut être **créée depuis la CLI en utilisant les identifiants d'un principal ayant accès à l'objet** (si le compte que vous utilisez n'a pas accès, une URL présignée plus courte sera créée mais elle sera inutile)
```bash
aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'
```
> [!NOTE]
> La seule autorisation requise pour générer une URL pré-signée est l'autorisation accordée, donc pour la commande précédente, la seule autorisation nécessaire pour le principal est `s3:GetObject`
> La seule permission requise pour générer une URL pré-signée est la permission qui est accordée, donc pour la commande précédente la seule permission nécessaire pour le principal est `s3:GetObject`
Il est également possible de créer des URL pré-signées avec **d'autres autorisations** :
Il est également possible de créer des URL pré-signées avec **d'autres permissions** :
```python
import boto3
url = boto3.client('s3').generate_presigned_url(
@@ -44,57 +44,57 @@ ExpiresIn=3600
```
### Mécanismes de chiffrement S3
**DEK signifie Data Encryption Key** et est la clé qui est toujours générée et utilisée pour chiffrer les données.
**DEK signifie Data Encryption Key** et correspond à la clé toujours générée et utilisée pour chiffrer les données.
<details>
<summary><strong>Chiffrement côté serveur avec des clés gérées par S3, SSE-S3</strong></summary>
<summary><strong>Chiffrement côté serveur avec clés gérées par S3, SSE-S3</strong></summary>
Cette option nécessite une configuration minimale et toute la gestion des clés de chiffrement utilisées est gérée par AWS. Tout ce que vous avez à faire est de **télécharger vos données et S3 s'occupera de tous les autres aspects**. Chaque bucket dans un compte S3 se voit attribuer une clé de bucket.
Cette option nécessite une configuration minimale et toute la gestion des clés de chiffrement est assurée par AWS. Tout ce que vous avez à faire est de **téléverser vos données et S3 gèrera tous les autres aspects**. Chaque bucket dans un compte S3 se voit attribuer une bucket key.
- Chiffrement :
- Données de l'objet + DEK en clair créé --> Données chiffrées (stockées dans S3)
- DEK en clair créé + Clé maître S3 --> DEK chiffré (stocké dans S3) et le texte en clair est supprimé de la mémoire
- Déchiffrement :
- DEK chiffré + Clé maître S3 --> DEK en clair
- DEK en clair + Données chiffrées --> Données de l'objet
- Encryption :
- Object Data + DEK en clair créé --> Données chiffrées (stockées dans S3)
- DEK en clair créé + S3 Master Key --> DEK chiffré (stocké dans S3) et le texte en clair est supprimé de la mémoire
- Decryption :
- DEK chiffré + S3 Master Key --> DEK en clair
- DEK en clair + données chiffrées --> Object Data
Veuillez noter que dans ce cas **la clé est gérée par AWS** (rotation uniquement tous les 3 ans). Si vous utilisez votre propre clé, vous pourrez faire pivoter, désactiver et appliquer un contrôle d'accès.
Veuillez noter que dans ce cas **la clé est gérée par AWS** (rotation uniquement tous les 3 ans). Si vous utilisez votre propre clé, vous pourrez la faire tourner, la désactiver et appliquer des contrôles d'accès.
</details>
<details>
<summary><strong>Chiffrement côté serveur avec des clés gérées par KMS, SSE-KMS</strong></summary>
<summary><strong>Chiffrement côté serveur avec clés gérées par KMS, SSE-KMS</strong></summary>
Cette méthode permet à S3 d'utiliser le service de gestion des clés pour générer vos clés de chiffrement de données. KMS vous offre une bien plus grande flexibilité sur la gestion de vos clés. Par exemple, vous pouvez désactiver, faire pivoter et appliquer des contrôles d'accès au CMK, et ordonner leur utilisation à l'aide d'AWS Cloud Trail.
Cette méthode permet à S3 d'utiliser le Key Management Service pour générer vos data encryption keys. KMS vous donne une bien plus grande flexibilité sur la gestion de vos clés. Par exemple, vous pouvez désactiver, faire pivoter et appliquer des contrôles d'accès au CMK, et auditer leur utilisation via AWS Cloud Trail.
- Chiffrement :
- S3 demande des clés de données à KMS CMK
- KMS utilise un CMK pour générer la paire DEK en clair et DEK chiffré et les envoie à S3
- S3 utilise la clé en clair pour chiffrer les données, stocke les données chiffrées et la clé chiffrée et supprime de la mémoire la clé en clair
- Déchiffrement :
- S3 demande à KMS de déchiffrer la clé de données chiffrée de l'objet
- KMS déchiffre la clé de données avec le CMK et la renvoie à S3
- Encryption :
- S3 demande des data keys à KMS CMK
- KMS utilise un CMK pour générer la paire DEK en clair et DEK chiffré et les renvoie à S3
- S3 utilise la clé en clair pour chiffrer les données, stocke les données chiffrées et la clé chiffrée puis supprime la clé en clair de la mémoire
- Decryption :
- S3 demande à KMS de déchiffrer la data key chiffrée de l'objet
- KMS déchiffre la data key avec le CMK et la renvoie à S3
- S3 déchiffre les données de l'objet
</details>
<details>
<summary><strong>Chiffrement côté serveur avec des clés fournies par le client, SSE-C</strong></summary>
<summary><strong>Chiffrement côté serveur avec clés fournies par le client, SSE-C</strong></summary>
Cette option vous donne l'opportunité de fournir votre propre clé maître que vous utilisez peut-être déjà en dehors d'AWS. Votre clé fournie par le client serait alors envoyée avec vos données à S3, où S3 effectuerait ensuite le chiffrement pour vous.
Cette option vous donne la possibilité de fournir votre propre clé maîtresse que vous utilisez éventuellement en dehors d'AWS. Votre clé fournie par le client serait alors envoyée avec vos données à S3, où S3 effectuerait le chiffrement pour vous.
- Chiffrement :
- L'utilisateur envoie les données de l'objet + clé client à S3
- Encryption :
- L'utilisateur envoie les données de l'objet + la clé fournie par le client à S3
- La clé client est utilisée pour chiffrer les données et les données chiffrées sont stockées
- une valeur HMAC salée de la clé client est également stockée pour la validation future de la clé
- une valeur HMAC salée de la clé client est également stockée pour validation future de la clé
- la clé client est supprimée de la mémoire
- Déchiffrement :
- Decryption :
- L'utilisateur envoie la clé client
- La clé est validée par rapport à la valeur HMAC stockée
- La clé fournie par le client est ensuite utilisée pour déchiffrer les données
- La clé est validée contre la valeur HMAC stockée
- La clé fournie par le client est alors utilisée pour déchiffrer les données
</details>
@@ -102,39 +102,39 @@ Cette option vous donne l'opportunité de fournir votre propre clé maître que
<summary><strong>Chiffrement côté client avec KMS, CSE-KMS</strong></summary>
De manière similaire à SSE-KMS, cela utilise également le service de gestion des clés pour générer vos clés de chiffrement de données. Cependant, cette fois, KMS est appelé via le client et non S3. Le chiffrement a alors lieu côté client et les données chiffrées sont ensuite envoyées à S3 pour être stockées.
De façon similaire à SSE-KMS, ceci utilise aussi le Key Management Service pour générer vos data encryption keys. Cependant, cette fois KMS est appelé par le client et non par S3. Le chiffrement a lieu côté client puis les données chiffrées sont envoyées à S3 pour stockage.
- Chiffrement :
- Le client demande une clé de données à KMS
- Encryption :
- Le client demande une data key à KMS
- KMS renvoie le DEK en clair et le DEK chiffré avec le CMK
- Les deux clés sont renvoyées
- Le client chiffre ensuite les données avec le DEK en clair et envoie à S3 les données chiffrées + le DEK chiffré (qui est enregistré comme métadonnées des données chiffrées dans S3)
- Déchiffrement :
- Les données chiffrées avec le DEK chiffré sont envoyées au client
- Le client chiffre ensuite les données avec le DEK en clair et envoie à S3 les données chiffrées + le DEK chiffré (qui est sauvegardé en tant que metadata des données chiffrées dans S3)
- Decryption :
- Les données chiffrées avec le DEK chiffré sont renvoyées au client
- Le client demande à KMS de déchiffrer la clé chiffrée en utilisant le CMK et KMS renvoie le DEK en clair
- Le client peut maintenant déchiffrer les données chiffrées
- Le client peut alors déchiffrer les données chiffrées
</details>
<details>
<summary><strong>Chiffrement côté client avec des clés fournies par le client, CSE-C</strong></summary>
<summary><strong>Chiffrement côté client avec clés fournies par le client, CSE-C</strong></summary>
En utilisant ce mécanisme, vous pouvez utiliser vos propres clés fournies et utiliser un client AWS-SDK pour chiffrer vos données avant de les envoyer à S3 pour stockage.
Avec ce mécanisme, vous pouvez utiliser vos propres clés fournies et un client AWS-SDK pour chiffrer vos données avant de les envoyer à S3 pour stockage.
- Chiffrement :
- Encryption :
- Le client génère un DEK et chiffre les données en clair
- Ensuite, en utilisant son propre CMK personnalisé, il chiffre le DEK
- Puis, en utilisant son propre CMK personnalisé, il chiffre le DEK
- soumet les données chiffrées + DEK chiffré à S3 où elles sont stockées
- Déchiffrement :
- Decryption :
- S3 envoie les données chiffrées et le DEK
- Comme le client a déjà le CMK utilisé pour chiffrer le DEK, il déchiffre le DEK et utilise ensuite le DEK en clair pour déchiffrer les données
- Comme le client possède déjà le CMK utilisé pour chiffrer le DEK, il déchiffre le DEK puis utilise le DEK en clair pour déchiffrer les données
</details>
### **Énumération**
### **Enumeration**
L'un des moyens traditionnels de compromettre les organisations AWS commence par compromettre les buckets accessibles publiquement. **Vous pouvez trouver** [**des énumérateurs de buckets publics sur cette page**](../aws-unauthenticated-enum-access/#s3-buckets)**.**
Une des méthodes traditionnelles principales pour compromettre des organisations AWS consiste à compromettre des buckets accessibles publiquement. **Vous pouvez trouver** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
```bash
# Get buckets ACLs
aws s3api get-bucket-acl --bucket <bucket-name>
@@ -229,22 +229,22 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
```
### dual-stack <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
Vous pouvez accéder à un bucket S3 via un point de terminaison dual-stack en utilisant un nom de point de terminaison de style hébergé virtuel ou de style chemin. Ceux-ci sont utiles pour accéder à S3 via IPv6.
Vous pouvez accéder à un S3 bucket via un endpoint dual-stack en utilisant un nom d'endpoint de type virtual hosted-style ou path-style. Ceux-ci sont utiles pour accéder à S3 via IPv6.
Les points de terminaison dual-stack utilisent la syntaxe suivante :
Les endpoints dual-stack utilisent la syntaxe suivante :
- `bucketname.s3.dualstack.aws-region.amazonaws.com`
- `s3.dualstack.aws-region.amazonaws.com/bucketname`
### Privesc
Dans la page suivante, vous pouvez vérifier comment **abuser des permissions S3 pour escalader les privilèges** :
Sur la page suivante, vous pouvez consulter comment **abuse S3 permissions to escalate privileges** :
{{#ref}}
../aws-privilege-escalation/aws-s3-privesc/README.md
{{#endref}}
### Accès non authentifié
### Unauthenticated Access
{{#ref}}
../aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md
@@ -256,29 +256,29 @@ Dans la page suivante, vous pouvez vérifier comment **abuser des permissions S3
../aws-post-exploitation/aws-s3-post-exploitation/README.md
{{#endref}}
### Persistance
### Persistence
{{#ref}}
../aws-persistence/aws-s3-persistence/README.md
{{#endref}}
## Autres vulnérabilités S3
## Other S3 vulns
### Problème de Poisoning du Cache HTTP S3 <a href="#heading-s3-http-desync-cache-poisoning-issue" id="heading-s3-http-desync-cache-poisoning-issue"></a>
### S3 HTTP Cache Poisoning Issue <a href="#heading-s3-http-desync-cache-poisoning-issue" id="heading-s3-http-desync-cache-poisoning-issue"></a>
[**Selon cette recherche**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue), il était possible de mettre en cache la réponse d'un bucket arbitraire comme si elle appartenait à un autre. Cela aurait pu être abusé pour changer par exemple les réponses de fichiers javascript et compromettre des pages arbitraires utilisant S3 pour stocker du code statique.
[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) il était possible de mettre en cache la réponse d'un bucket arbitraire comme si elle appartenait à un autre. Cela aurait pu être abusé pour modifier, par exemple, les réponses de fichiers javascript et compromettre des pages arbitraires utilisant S3 pour stocker du code statique.
## Amazon Athena
Amazon Athena est un service de requête interactif qui facilite **l'analyse des données** directement dans Amazon Simple Storage Service (Amazon **S3**) **en utilisant** le **SQL** standard.
Amazon Athena est un service de requêtes interactif qui facilite l'**analyse des données** directement dans Amazon Simple Storage Service (Amazon **S3**) **en utilisant** le standard **SQL**.
Vous devez **préparer une table de base de données relationnelle** avec le format du contenu qui va apparaître dans les buckets S3 surveillés. Ensuite, Amazon Athena pourra peupler la base de données à partir des journaux, afin que vous puissiez l'interroger.
Vous devez préparer une table de base de données relationnelle correspondant au format du contenu qui va apparaître dans les buckets S3 surveillés. Ensuite, Amazon Athena pourra remplir la base de données à partir des logs, afin que vous puissiez l'interroger.
Amazon Athena prend en charge la **possibilité d'interroger des données S3 qui sont déjà chiffrées** et si configuré pour le faire, **Athena peut également chiffrer les résultats de la requête qui peuvent ensuite être stockés dans S3**.
Amazon Athena prend en charge la **possibilité d'interroger des données S3 déjà chiffrées** et, si configuré pour le faire, **Athena peut également chiffrer les résultats de la requête qui peuvent ensuite être stockés dans S3**.
**Ce chiffrement des résultats est indépendant des données S3 sous-jacentes interrogées**, ce qui signifie que même si les données S3 ne sont pas chiffrées, les résultats interrogés peuvent être chiffrés. Quelques points à prendre en compte sont qu'Amazon Athena ne prend en charge que les données qui ont été **chiffrées** avec les **méthodes de chiffrement S3 suivantes**, **SSE-S3, SSE-KMS et CSE-KMS**.
**Ce chiffrement des résultats est indépendant des données S3 sous-jacentes interrogées**, ce qui signifie que même si les données S3 ne sont pas chiffrées, les résultats de la requête peuvent l'être. Quelques points à noter : Amazon Athena ne prend en charge que les données qui ont été **chiffrées** avec les **méthodes de chiffrement S3 suivantes**, **SSE-S3, SSE-KMS, and CSE-KMS**.
SSE-C et CSE-E ne sont pas pris en charge. De plus, il est important de comprendre qu'Amazon Athena n'exécutera des requêtes que sur **des objets chiffrés qui se trouvent dans la même région que la requête elle-même**. Si vous devez interroger des données S3 qui ont été chiffrées à l'aide de KMS, des permissions spécifiques sont requises par l'utilisateur Athena pour leur permettre d'effectuer la requête.
SSE-C et CSE-C ne sont pas pris en charge. De plus, il est important de comprendre qu'Amazon Athena n'exécutera des requêtes que sur des **objets chiffrés qui se trouvent dans la même région que la requête elle-même**. Si vous devez interroger des données S3 chiffrées avec KMS, des permissions spécifiques sont alors requises pour l'utilisateur Athena afin de lui permettre d'exécuter la requête.
### Enumeration
```bash