From 119281cd31011f41a8e462ef3cf37e7a9447db4b Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 15 Nov 2025 16:36:49 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/confidential-computing/luks2-header-ma --- ...2-header-malleability-null-cipher-abuse.md | 141 ++++++++++++++++++ .../pentesting-cloud-methodology.md | 91 ++++++----- 2 files changed, 186 insertions(+), 46 deletions(-) create mode 100644 src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md diff --git a/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md b/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md new file mode 100644 index 000000000..aed8ec716 --- /dev/null +++ b/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md @@ -0,0 +1,141 @@ +# Malleabilité de l'en-tête LUKS2 et abus du Null-Cipher dans les Confidential VMs + +{{#include ../../banners/hacktricks-training.md}} + +## TL;DR + +- De nombreuses Confidential VMs (CVMs) basées sur Linux et exécutées sur AMD SEV-SNP ou Intel TDX utilisent LUKS2 pour le stockage persistant. L'en-tête LUKS2 sur disque est malléable et n'est pas protégé en intégrité contre des attaquants disposant d'un accès en écriture adjacent au stockage. +- Si le chiffrement du segment de données dans l'en-tête est réglé sur un null cipher (par ex. "cipher_null-ecb"), cryptsetup l'accepte et l'invité lit/écrit en clair de manière transparente tout en croyant que le disque est chiffré. +- Avant et y compris cryptsetup 2.8.0, les null ciphers pouvaient être utilisés pour les keyslots ; depuis 2.8.1 ils sont rejetés pour les keyslots avec des mots de passe non vides, mais les null ciphers restent autorisés pour les segments de volume. +- L'attestation à distance mesure généralement le code/la configuration de la VM, pas les en-têtes LUKS externes modifiables ; sans validation/mesure explicite, un attaquant avec accès en écriture au disque peut forcer des E/S en clair. + +## Contexte : format sur disque de LUKS2 (ce qui compte pour les attaquants) + +- Un périphérique LUKS2 commence par un en-tête suivi de données chiffrées. +- L'en-tête contient deux copies identiques d'une section binaire et une section de métadonnées JSON, plus un ou plusieurs keyslots. +- Les métadonnées JSON définissent : +- les keyslots activés et leur KDF/cipher de wrapping +- les segments qui décrivent la zone de données (cipher/mode) +- des digests (par ex. le hash de la volume key pour vérifier les passphrases) +- Valeurs sécurisées typiques : KDF de keyslot argon2id ; chiffrement du keyslot et du segment de données aes-xts-plain64. + +Inspecter rapidement le cipher du segment directement depuis le JSON: +```bash +# Read JSON metadata and print the configured data segment cipher +cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \ +| jq -r '.segments["0"].encryption' +``` +## Root cause + +- Les en-têtes LUKS2 ne sont pas authentifiés contre la modification du stockage. Un attaquant côté hôte/stockage peut réécrire les métadonnées JSON acceptées par cryptsetup. +- Depuis cryptsetup 2.8.0, les en-têtes qui définissent le chiffrement d'un segment sur cipher_null-ecb sont acceptés. Le null cipher ignore les clés et renvoie le texte en clair. +- Jusqu'à la version 2.8.0, les null ciphers pouvaient aussi être utilisés pour les keyslots (le keyslot s'ouvre avec n'importe quelle passphrase). Depuis 2.8.1, les null ciphers sont rejetés pour les keyslots avec des mots de passe non vides, mais restent autorisés pour les segments. Modifier uniquement le cipher du segment donne toujours des E/S en clair après 2.8.1. + +## Threat model: why attestation didn’t save you by default + +- Les CVM visent à assurer la confidentialité, l'intégrité et l'authenticité dans un hôte non fiable. +- L'attestation distante mesure habituellement l'image de la VM et la configuration de lancement, pas l'en-tête LUKS mutable qui réside sur un stockage non fiable. +- Si votre CVM fait confiance à un en-tête sur disque sans validation/mesure robuste, un attaquant sur le stockage peut le modifier en null cipher et votre machine invitée montera un volume en clair sans erreur. + +## Exploitation (storage write access required) + +Préconditions: +- Accès en écriture au bloc device chiffré LUKS2 de la CVM. +- La machine invitée utilise l'en-tête LUKS2 présent sur disque sans validation/attestation robuste. + +Steps (high level): +1) Lire le JSON de l'en-tête et identifier la définition du segment de données. Champ cible exemple : segments["0"].encryption. +2) Définir le chiffrement du segment de données sur un null cipher, p.ex. cipher_null-ecb. Conserver les paramètres du keyslot et la structure de digest intactes pour que la passphrase habituelle de la machine invitée continue de « fonctionner ». +3) Mettre à jour les deux copies d'en-tête et les digests associés pour que l'en-tête soit cohérent en interne. +4) Au prochain boot, la machine invitée exécute cryptsetup, déverrouille avec succès le keyslot existant avec sa passphrase et monte le volume. Comme le cipher du segment est un null cipher, toutes les lectures/écritures sont en clair. + +Variant (pre-2.8.1 keyslot abuse): si area.encryption d'un keyslot est un null cipher, il s'ouvre avec n'importe quelle passphrase. Combinez avec un null segment cipher pour un accès en clair transparent sans connaître le secret de la machine invitée. + +## Robust mitigations (avoid TOCTOU with detached headers) + +Traitez toujours les en-têtes LUKS sur disque comme des entrées non fiables. Utilisez le detached-header mode afin que la validation et l'ouverture utilisent les mêmes octets de confiance provenant de la RAM protégée: +```bash +# Copy header into protected memory (e.g., tmpfs) and open from there +cryptsetup luksHeaderBackup --header-backup-file /tmp/luks_header /dev/VDISK +cryptsetup open --type luks2 --header /tmp/luks_header /dev/VDISK --key-file=key.txt +``` +Ensuite, appliquer une (ou plusieurs) des mesures suivantes : + +1) MAC the full header +- Calculer/vérifier un MAC sur l'intégralité de l'en-tête avant utilisation. +- N'ouvrir le volume que si le MAC est validé. +- Exemples observés : Flashbots tdx-init et Fortanix Salmiac ont adopté une vérification basée sur MAC. + +2) Strict JSON validation (backward compatible) +- Exporter les métadonnées JSON et valider une liste blanche stricte des paramètres (KDF, ciphers, segment count/type, flags). +```bash +#!/bin/bash +set -e +# Store header in confidential RAM fs +cryptsetup luksHeaderBackup --header-backup-file /tmp/luks_header $BLOCK_DEVICE +# Dump JSON metadata header to a file +cryptsetup luksDump --type luks2 --dump-json-metadata /tmp/luks_header > header.json +# Validate the header +python validate.py header.json +# Open the cryptfs using key.txt +cryptsetup open --type luks2 --header /tmp/luks_header $BLOCK_DEVICE --key-file=key.txt +``` +
+Exemple de validateur (faire respecter des champs sûrs) +```python +from json import load +import sys +with open(sys.argv[1], "r") as f: +header = load(f) +if len(header["keyslots"]) != 1: +raise ValueError("Expected 1 keyslot") +if header["keyslots"]["0"]["type"] != "luks2": +raise ValueError("Expected luks2 keyslot") +if header["keyslots"]["0"]["area"]["encryption"] != "aes-xts-plain64": +raise ValueError("Expected aes-xts-plain64 encryption") +if header["keyslots"]["0"]["kdf"]["type"] != "argon2id": +raise ValueError("Expected argon2id kdf") +if len(header["tokens"]) != 0: +raise ValueError("Expected 0 tokens") +if len(header["segments"]) != 1: +raise ValueError("Expected 1 segment") +if header["segments"]["0"]["type"] != "crypt": +raise ValueError("Expected crypt segment") +if header["segments"]["0"]["encryption"] != "aes-xts-plain64": +raise ValueError("Expected aes-xts-plain64 encryption") +if "flags" in header["segments"]["0"] and header["segments"]["0"]["flags"]: +raise ValueError("Segment contains unexpected flags") +``` +
+ +3) Mesurer/attester l'en-tête +- Supprimez les salts/digests aléatoires et mesurez l'en-tête assaini dans les PCR TPM/TDX/SEV ou dans l'état de politique KMS. +- Ne libérez les clés de déchiffrement que lorsque l'en-tête mesuré correspond à un profil approuvé et sûr. + +Directives opérationnelles : +- Appliquez detached header + MAC ou une validation stricte ; ne faites jamais confiance aux en-têtes on-disk directement. +- Les consommateurs d'attestation doivent refuser les versions de framework pré-correctif dans les allow-lists. + +## Notes sur les versions et la position du mainteneur + +- Les mainteneurs de cryptsetup ont précisé que LUKS2 n'a pas été conçu pour fournir l'intégrité contre la falsification du stockage dans ce contexte ; les null ciphers sont conservés pour la rétrocompatibilité. +- cryptsetup 2.8.1 (19 oct. 2025) refuse les null ciphers pour les keyslots avec des mots de passe non vides mais autorise toujours les null ciphers pour les segments. + +## Vérifications rapides et triage + +- Vérifiez si le chiffrement d'un segment est configuré sur un null cipher : +```bash +cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \ +| jq -r '.segments | to_entries[] | "segment=" + .key + ", enc=" + .value.encryption' +``` +- Vérifiez les keyslot and segment algorithms avant d'ouvrir le volume. Si vous ne pouvez pas MAC, appliquez une validation JSON stricte et ouvrez en utilisant le detached header depuis la mémoire protégée. + +## Références + +- [Vulnerabilities in LUKS2 disk encryption for confidential VMs (Trail of Bits)](https://blog.trailofbits.com/2025/10/30/vulnerabilities-in-luks2-disk-encryption-for-confidential-vms/) +- [cryptsetup issue #954 (null cipher acceptance and integrity considerations)](https://gitlab.com/cryptsetup/cryptsetup/-/issues/954) +- [CVE-2025-59054](https://nvd.nist.gov/vuln/detail/CVE-2025-59054) +- [CVE-2025-58356](https://nvd.nist.gov/vuln/detail/CVE-2025-58356) +- [Related context: CVE-2021-4122 (auto-recovery path silently decrypting disks)](https://www.cve.org/CVERecord?id=CVE-2021-4122) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index 8fd094551..e9f9f38fb 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -1,4 +1,4 @@ -# Pentesting Cloud Methodology +# Méthodologie Pentesting Cloud {{#include ../banners/hacktricks-training.md}} @@ -6,39 +6,39 @@ ## 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'il teste un environnement cloud : +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 : -- **Vérifications de benchmark** +- **Benchmark checks** - 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 lors des tests de benchmark. +- 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 - Cela aidera beaucoup pour les étapes suivantes -- **Vérifier les ressources exposées** -- 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 considère **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 par le cloud qui peuvent être configurés** pour être exposés (comme des DB ou des buckets) -- Ensuite, vous devriez vérifier **si cette ressource peut compromettre la confidentialité ou non** (informations confidentielles ? vulnérabilités ? mauvaises configurations dans le service exposé ?) -- **Vérifier les permissions** -- Ici vous devez **identifier toutes les permissions de chaque rôle/utilisateur** à l'intérieur du cloud et comment elles sont utilisées -- Trop de comptes **hautement privilégiés** (contrôlent tout) ? Clefs générées non utilisées ?... La plupart de ces vérifications devraient déjà avoir été faites dans les 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 si le rôle admin est attribué à 1 utilisateur ou à 100) -- Il ne suffit pas de trouver quels utilisateurs 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 **possibles privesc** à exploiter en abusant des permissions. Toutes ces choses doivent être prises en compte et **autant de chemins de privesc que possible** doivent être reportés. -- **Vérifier les intégrations** +- **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 AWS bucket d'où GCP récupère des données (demandez à quel point l'action est sensible dans GCP en traitant ces données). -- Pour **les intégrations dans le cloud que vous auditez** depuis des plateformes externes, vous devriez demander **qui a un 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 la modifier et quelles informations sensibles et quels accès cette image obtiendra lorsqu'elle sera exécutée à l'intérieur d'un cloud AWS. +- 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. -## Outils multi-cloud +## Multi-Cloud tools 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 les chemins de privesc dans les clouds et entre clouds/SaaS.** +Un outil pour **identifier les mauvaises configurations et privesc path dans les clouds et entre clouds/SaaS.** {{#tabs }} {{#tab name="Install" }} @@ -146,7 +146,7 @@ done {{#tabs }} {{#tab name="Install" }} -Téléchargez et installez Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Ou utilisez Brew: +Téléchargez et installez Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Ou utilisez Brew : ``` brew tap turbot/tap brew install steampipe @@ -170,7 +170,7 @@ steampipe check all Vérifier tous les projets -Pour 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 projets, vous devez générer le fichier `gcp.spc` indiquant tous les projets à tester. Vous pouvez simplement suivre les indications du script suivant ```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -194,11 +194,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate ``` -Pour consulter **d'autres insights GCP** (utile pour énumérer les services) utilisez : [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) +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 le code Terraform GCP : [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) +Pour consulter le code Terraform GCP : [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) -Plus de plugins GCP pour Steampipe : [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) +D'autres plugins GCP pour Steampipe : [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) {{#endtab }} {{#tab name="AWS" }} @@ -225,24 +225,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 le 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 pour 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 nécessite python2.7 et semble non maintenu. +Il requiert python2.7 et semble non maintenu. ### Nessus -Nessus propose un scan _**Audit Cloud Infrastructure**_ prenant en charge : AWS, Azure, Office 365, Rackspace, Salesforce. Quelques configurations supplémentaires dans **Azure** sont nécessaires pour obtenir un **Client Id**. +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**. ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) -Cloudlist est un **outil multi-cloud pour obtenir des actifs** (noms d'hôte, adresses IP) à partir de fournisseurs cloud. +Cloudlist est un **outil multi-cloud pour récupérer des Assets** (Hostnames, IP Addresses) auprès des fournisseurs cloud. {{#tabs }} {{#tab name="Cloudlist" }} @@ -265,7 +265,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartography est un outil Python qui consolide les ressources d'infrastructure et leurs relations dans une vue en graphe intuitive alimentée par une base de données Neo4j. +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. {{#tabs }} {{#tab name="Install" }} @@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \ ### [**starbase**](https://github.com/JupiterOne/starbase) -Starbase collecte les actifs et les relations depuis des services et systèmes, y compris l'infrastructure cloud, les applications SaaS, les contrôles de sécurité, et plus encore, dans une vue graphe intuitive reposant sur la base de données Neo4j. +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. {{#tabs }} {{#tab name="Install" }} @@ -361,7 +361,7 @@ uri: bolt://localhost:7687 ### [**SkyArk**](https://github.com/cyberark/SkyArk) -Permet d'identifier les utilisateurs les plus privilégiés dans l'environnement AWS ou Azure scanné, y compris les AWS Shadow Admins. Il utilise powershell. +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. ```bash Import-Module .\SkyArk.ps1 -force Start-AzureStealth @@ -372,13 +372,13 @@ Scan-AzureAdmins ``` ### [Cloud Brute](https://github.com/0xsha/CloudBrute) -Un outil pour trouver l'infrastructure, les fichiers et les applications d'une entreprise (cible) sur les principaux fournisseurs cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). +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). ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox est un outil pour trouver des cheminements d'attaque exploitables dans l'infrastructure cloud (actuellement seuls AWS & Azure sont supportés, GCP à venir). -- C'est un outil d'énumération destiné à compléter le pentesting manuel. -- Il ne crée ni ne modifie aucune donnée dans l'environnement cloud. +- 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. ### More lists of cloud security tools @@ -410,13 +410,12 @@ aws-security/ azure-security/ {{#endref}} -### Graphe d'attaque +## Fonctionnalités communes de sécurité cloud -[**Stormspotter** ](https://github.com/Azure/Stormspotter) crée un « graphe d'attaque » des ressources dans une subscription Azure. Il permet aux red teams et pentesters de visualiser la surface d'attaque et les opportunités de pivot au sein d'un tenant, et permet à vos défenseurs de s'orienter rapidement et de prioriser le travail de réponse aux incidents. - -### Office365 - -Vous avez besoin de **Global Admin** ou au moins de **Global Admin Reader** (notez toutefois que Global Admin Reader est un peu limité). Cependant, ces limitations apparaissent dans certains modules PS et peuvent être contournées en accédant aux fonctionnalités **via l'application web**. +### Confidential Computing +{{#ref}} +confidential-computing/luks2-header-malleability-null-cipher-abuse.md +{{#endref}} {{#include ../banners/hacktricks-training.md}}