Translated ['src/pentesting-cloud/pentesting-cloud-methodology.md', 'src

src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md

@@ -0,0 +1,141 @@
+# Maleabilidad del encabezado LUKS2 y abuso de null-cipher en Confidential VMs
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## TL;DR
+
+- Muchas Confidential VMs (CVMs) basadas en Linux que se ejecutan en AMD SEV-SNP o Intel TDX usan LUKS2 para almacenamiento persistente. El encabezado LUKS2 en disco es maleable y no está protegido por integridad frente a atacantes adyacentes al almacenamiento.
+- Si el cifrado del segmento de datos en el encabezado se configura con un null cipher (p. ej., "cipher_null-ecb"), cryptsetup lo acepta y el guest lee/escribe en texto plano de forma transparente mientras cree que el disco está cifrado.
+- Hasta cryptsetup 2.8.0 inclusive, los null ciphers podían usarse para keyslots; desde 2.8.1 se rechazan para keyslots con contraseñas no vacías, pero los null ciphers siguen permitidos para los segmentos de volumen.
+- La remote attestation normalmente mide el código/configuración de la VM, no los encabezados LUKS externos y mutables; sin una validación/medición explícita, un atacante con acceso de escritura al disco puede forzar I/O en texto plano.
+
+## Antecedentes: formato en disco de LUKS2 (lo que importa para los atacantes)
+
+- Un dispositivo LUKS2 comienza con un encabezado seguido de datos cifrados.
+- El encabezado contiene dos copias idénticas de una sección binaria y una sección de metadatos JSON, además de uno o más keyslots.
+- Los metadatos JSON definen:
+  - los keyslots habilitados y su KDF/cipher de envoltura
+  - los segmentos que describen el área de datos (cipher/mode)
+  - digests (p. ej., hash de la clave de volumen para verificar contraseñas)
+- Valores típicos seguros: keyslot KDF argon2id; cifrado de keyslot y segmentos de datos aes-xts-plain64.
+
+Inspeccione rápidamente el cipher del segmento directamente desde el 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'
+```
+## Causa raíz
+
+- Los LUKS2 headers no están autenticados contra manipulaciones del almacenamiento. Un atacante del host/almacenamiento puede reescribir los metadatos JSON aceptados por cryptsetup.
+- Desde cryptsetup 2.8.0, se aceptan headers que fijan la encriptación de un segmento a cipher_null-ecb. El null cipher ignora las claves y devuelve texto en claro.
+- Hasta la 2.8.0, los null ciphers también podían usarse para keyslots (el keyslot se abre con cualquier passphrase). Desde 2.8.1, los null ciphers se rechazan para keyslots con passwords no vacías, pero siguen permitidos para segmentos. Cambiar solo el cipher del segmento sigue produciendo I/O en texto en claro después de 2.8.1.
+
+## Modelo de amenaza: por qué la attestation no te salvó por defecto
+
+- CVMs buscan asegurar confidencialidad, integridad y autenticidad en un host no confiable.
+- Remote attestation normalmente mide la imagen de la VM y la configuración de lanzamiento, no el header LUKS mutable que vive en almacenamiento no confiable.
+- Si tu CVM confía en un header en disco sin validación/medición robusta, un atacante del almacenamiento puede alterarlo a un null cipher y tu guest montará un volumen en texto en claro sin error.
+
+## Explotación (se requiere acceso de escritura al almacenamiento)
+
+Precondiciones:
+- Acceso de escritura al dispositivo de bloque cifrado LUKS2 del CVM.
+- El guest usa el header LUKS2 en disco sin validación/attestation robusta.
+
+Pasos (a alto nivel):
+1) Leer el JSON del header e identificar la definición del segmento de datos. Campo de ejemplo: segments["0"].encryption.
+2) Ajustar la encriptación del segmento de datos a un null cipher, p.ej., cipher_null-ecb. Mantener los parámetros del keyslot y la estructura de digest intactos para que la passphrase habitual del guest siga “funcionando”.
+3) Actualizar ambas copias del header y los digest asociados para que el header sea autoconsistente.
+4) En el siguiente arranque, el guest ejecuta cryptsetup, desbloquea con éxito el keyslot existente usando su passphrase y monta el volumen. Debido a que el cipher del segmento es un null cipher, todas las lecturas/escrituras son en texto en claro.
+
+Variante (abuso de keyslot pre-2.8.1): si el area.encryption de un keyslot es un null cipher, se abre con cualquier passphrase. Combínalo con un null segment cipher para acceso en texto en claro sin conocer el secreto del guest.
+
+## Mitigaciones robustas (evitar TOCTOU con detached headers)
+
+Siempre trata los LUKS headers en disco como entrada no confiable. Usa detached-header mode para que la validación y la apertura usen los mismos bytes de confianza procedentes de la RAM protegida:
+```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
+```
+A continuación, aplique una (o más) de las siguientes medidas:
+
+1) Aplicar un MAC al header completo
+- Calcular/verificar un MAC sobre todo el header antes de su uso.
+- Abrir el volume solo cuando el MAC verifique.
+- Ejemplos en la práctica: Flashbots tdx-init y Fortanix Salmiac adoptaron verificación basada en MAC.
+
+2) Validación estricta de JSON (compatible hacia atrás)
+- Volcar los metadatos JSON y validar una lista blanca estricta de parámetros (KDF, ciphers, recuento/tipo de segmentos, 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
+```
+<details>
+<summary>Validador de ejemplo (hacer cumplir campos seguros)</summary>
+```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")
+```
+</details>
+
+3) Medir/atestiguar la cabecera
+- Eliminar salts/digests aleatorios y medir la cabecera saneada en los PCRs de TPM/TDX/SEV o en el estado de política de KMS.
+- Liberar las claves de descifrado solo cuando la cabecera medida coincida con un perfil aprobado y seguro.
+
+Orientación operativa:
+- Aplicar detached header + MAC o validación estricta; nunca confiar directamente en on-disk headers.
+- Los consumidores de attestation deberían denegar versiones del framework previas al parche en las allow-lists.
+
+## Notas sobre versiones y la postura del mantenedor
+
+- Los mantenedores de cryptsetup aclararon que LUKS2 no fue diseñado para proporcionar integridad frente a la manipulación del almacenamiento en este contexto; null ciphers se mantienen por compatibilidad hacia atrás.
+- cryptsetup 2.8.1 (Oct 19, 2025) rechaza null ciphers para keyslots con contraseñas no vacías pero aún permite null ciphers para segments.
+
+## Comprobaciones rápidas y triaje
+
+- Inspeccionar si la encriptación de algún segmento está configurada con un null cipher:
+```bash
+cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \
+| jq -r '.segments | to_entries[] | "segment=" + .key + ", enc=" + .value.encryption'
+```
+- Verifica los algoritmos de keyslot y segment antes de abrir el volumen. Si no puedes comprobar el MAC, aplica una validación JSON estricta y ábrelo usando el detached header desde protected memory.
+
+## Referencias
+
+- [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}}

src/pentesting-cloud/pentesting-cloud-methodology.md

@@ -1,44 +1,44 @@
-# Pentesting Cloud Methodology
+# Metodología de pentesting en la nube
 
 {{#include ../banners/hacktricks-training.md}}
 
 <figure><img src="../images/CLOUD-logo-letters.svg" alt=""><figcaption></figcaption></figure>
 
-## Basic Methodology
+## Metodología básica
 
-Cada cloud tiene sus propias peculiaridades pero en general hay unas pocas **cosas comunes que un pentester debe comprobar** al evaluar un entorno cloud:
+Cada nube tiene sus propias peculiaridades pero en general hay algunas **cosas comunes que un pentester debería revisar** al evaluar un entorno en la nube:
 
-- **Benchmark checks**
-- Esto te ayudará a **entender el tamaño** del entorno y **los servicios usados**
-- También te permitirá encontrar algunas **configuraciones erróneas rápidas** ya que puedes realizar la mayoría de estas pruebas con **herramientas automatizadas**
-- **Services Enumeration**
-- Probablemente no encontrarás muchas más configuraciones erróneas aquí si realizaste correctamente las pruebas de benchmark, pero podrías encontrar algunas que no se buscaron en el test de benchmark.
-- Esto te permitirá saber **qué se está usando exactamente** en el entorno cloud
+- **Comprobaciones de benchmark**
+- Esto te ayudará a **entender el tamaño** del entorno y **los servicios utilizados**
+- También te permitirá encontrar algunas **misconfiguraciones rápidas**, ya que puedes realizar la mayoría de estas pruebas con **herramientas automatizadas**
+- **Enumeración de servicios**
+- Probablemente no encontrarás muchas más misconfiguraciones aquí si realizaste correctamente las comprobaciones de benchmark, pero podrías encontrar algunas que no se buscaron en las pruebas de benchmark.
+- Esto te permitirá saber **qué se está usando exactamente** en el entorno en la nube
 - Esto ayudará mucho en los siguientes pasos
-- **Check exposed assets**
-- Esto puede hacerse durante la sección anterior, necesitas **identificar todo lo que potencialmente está expuesto** a Internet de alguna forma y cómo puede accederse.
-- Aquí me refiero a **infraestructura expuesta manualmente** como instancias con páginas web u otros puertos expuestos, y también a otros **cloud managed services que pueden ser configurados** para estar expuestos (como DBs o buckets)
-- Luego debes comprobar **si ese recurso puede estar expuesto o no** (¿información confidencial? ¿vulnerabilidades? ¿configuraciones erróneas en el servicio expuesto?)
-- **Check permissions**
-- Aquí debes **averiguar todos los permisos de cada role/user** dentro del cloud y cómo se usan
-- ¿Demasiadas cuentas con **altos privilegios** (controlan todo)? ¿Claves generadas sin usar?... La mayoría de estas comprobaciones deberían haberse hecho ya en los tests de benchmark
-- Si el cliente está usando OpenID o SAML u otra **federation** puede que necesites pedirles más **información** sobre **cómo se asigna cada role** (no es lo mismo que el role admin esté asignado a 1 usuario que a 100)
-- **No basta con encontrar** qué usuarios tienen permisos de admin "\*:\*". Hay muchos **otros permisos** que dependiendo de los servicios usados pueden ser muy **sensibles**.
-- Además, hay **posibles formas de privesc** a seguir abusando de permisos. Todas estas cosas deben tenerse en cuenta y **deben reportarse tantas rutas de privesc como sea posible**.
-- **Check Integrations**
-- Es muy probable que **se usen integraciones con otras clouds o SaaS** dentro del entorno cloud.
-- Para **integraciones del cloud que estás auditando** con otra plataforma deberías notificar **quién tiene acceso para (ab)usar esa integración** y deberías preguntar **qué tan sensible** es la acción que se realiza.\
-Por ejemplo, quién puede escribir en un AWS bucket del que GCP está obteniendo datos (pregunta qué tan sensible es la acción en GCP al tratar esos datos).
-- Para **integraciones dentro del cloud que estás auditando** desde plataformas externas, deberías preguntar **quién tiene acceso externo para (ab)usar esa integración** y comprobar cómo se están usando esos datos.\
-Por ejemplo, si un servicio está usando una imagen Docker alojada en GCR, deberías preguntar quién tiene acceso para modificarla y qué información sensible y accesos obtendrá esa imagen cuando se ejecute dentro de un cloud AWS.
+- **Comprobar activos expuestos**
+- Esto puede hacerse durante la sección anterior; necesitas **identificar todo lo que potencialmente está expuesto** a Internet de alguna manera y cómo puede ser accedido.
+- Aquí me refiero a **infraestructura expuesta manualmente** como instancias con páginas web u otros puertos expuestos, y también a otros **servicios gestionados en la nube que pueden configurarse** para estar expuestos (como DBs o buckets)
+- Luego deberías comprobar **si ese recurso puede ser expuesto o no** (¿información confidencial? ¿vulnerabilidades? ¿misconfiguraciones en el servicio expuesto?)
+- **Comprobar permisos**
+- Aquí deberías **identificar todos los permisos de cada rol/usuario** dentro de la nube y cómo se usan
+- ¿Demasiadas cuentas con **privilegios elevados** (controlan todo)? ¿Claves generadas que no se usan?... La mayoría de estas comprobaciones deberían haberse hecho ya en los tests de benchmark
+- Si el cliente está usando OpenID o SAML u otra **federación** puede que necesites pedirles más **información** sobre **cómo se asigna cada rol** (no es lo mismo que el rol admin esté asignado a 1 usuario o a 100)
+- **No es suficiente encontrar** qué usuarios tienen permisos **admin** "*:*". Hay muchos **otros permisos** que, dependiendo de los servicios usados, pueden ser muy **sensibles**.
+- Además, existen **posibles rutas de privesc** que se pueden seguir abusando de permisos. Todas estas cosas deben tenerse en cuenta y **se deben reportar tantos caminos de privesc como sea posible**.
+- **Comprobar integraciones**
+- Es altamente probable que **se estén usando integraciones con otras nubes o SaaS** dentro del entorno en la nube.
+- Para **las integraciones de la nube que estás auditando** con otra plataforma, deberías notificar **quién tiene acceso para (ab)usar esa integración** y deberías preguntar **qué tan sensible** es la acción que se realiza.\
+Por ejemplo, quién puede escribir en un bucket de AWS del cual GCP está obteniendo datos (preguntar qué tan sensible es la acción en GCP al tratar esos datos).
+- Para **las integraciones dentro de la nube que estás auditando** desde plataformas externas, deberías preguntar **quién tiene acceso externamente para (ab)usar esa integración** y comprobar cómo se están usando esos datos.\
+Por ejemplo, si un servicio está usando una imagen Docker alojada en GCR, deberías preguntar quién tiene acceso para modificarla y qué información sensible y accesos obtendrá esa imagen cuando se ejecute dentro de una nube AWS.
 
-## Multi-Cloud tools
+## Herramientas Multi-Cloud
 
-Hay varias herramientas que pueden usarse para testear diferentes entornos cloud. Los pasos de instalación y los enlaces se indicarán en esta sección.
+Hay varias herramientas que se pueden usar para evaluar diferentes entornos en la nube. Los pasos de instalación y los enlaces se indicarán en esta sección.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Una herramienta para **identificar malas configuraciones y privesc path en clouds y entre clouds/SaaS.**
+Una herramienta para **identificar malas configuraciones y rutas de privesc en nubes y entre nubes/SaaS.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -171,8 +171,6 @@ steampipe check all
 <summary>Comprobar todos los proyectos</summary>
 
 Para comprobar todos los proyectos necesitas generar el archivo `gcp.spc` indicando todos los proyectos a probar. Puedes seguir las indicaciones del siguiente script
-
-</details>
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -196,7 +194,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Para consultar **otros insights de GCP** (útiles para enumerar servicios) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Para comprobar **otros GCP insights** (útiles para enumerar servicios) utilice: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
 Para revisar código Terraform de GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
@@ -240,11 +238,11 @@ Requiere python2.7 y parece no estar mantenido.
 
 ### Nessus
 
-Nessus tiene un escaneo _**Audit Cloud Infrastructure**_ que soporta: AWS, Azure, Office 365, Rackspace, Salesforce. Se requieren algunas configuraciones adicionales en **Azure** para obtener un **Client Id**.
+Nessus tiene un escaneo _**Audit Cloud Infrastructure**_ que soporta: AWS, Azure, Office 365, Rackspace, Salesforce. Se necesitan algunas configuraciones adicionales en **Azure** para obtener un **Client Id**.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist es una **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) de Cloud Providers.
+Cloudlist es una **herramienta multi-cloud para obtener activos** (nombres de host, direcciones IP) de proveedores de nube.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -363,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Descubre los usuarios más privilegiados en el entorno AWS o Azure escaneado, incluyendo los AWS Shadow Admins. Usa powershell.
+Detecta los usuarios más privilegiados en el entorno AWS o Azure escaneado, incluyendo los AWS Shadow Admins. Utiliza powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -374,13 +372,13 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Una herramienta para encontrar la infraestructura, archivos y aplicaciones de una empresa (target) en los principales proveedores de la nube (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+Una herramienta para encontrar la infraestructura de una empresa (objetivo), archivos y apps en los principales proveedores de nube (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox es una herramienta para encontrar exploitable attack paths en la infraestructura cloud (actualmente solo soporta AWS & Azure; GCP próximamente).
+- CloudFox es una herramienta para encontrar rutas de ataque explotables en la infraestructura en la nube (actualmente solo soporta AWS & Azure, con GCP próximamente).
 - Es una herramienta de enumeración destinada a complementar el pentesting manual.
-- No crea ni modifica ningún dato dentro del entorno cloud.
+- No crea ni modifica ningún dato dentro del entorno en la nube.
 
 ### More lists of cloud security tools
 
@@ -412,13 +410,12 @@ aws-security/
 azure-security/
 {{#endref}}
 
-### Attack Graph
+## Common Cloud Security Features
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “attack graph” de los recursos en una suscripción de Azure. Permite a red teams y pentesters visualizar la superficie de ataque y las oportunidades de pivot dentro de un tenant, y potencia a tus defensores para orientarse y priorizar rápidamente el trabajo de respuesta a incidentes.
-
-### Office365
-
-Necesitas **Global Admin** o al menos **Global Admin Reader** (ten en cuenta que Global Admin Reader es algo limitado). Sin embargo, esas limitaciones aparecen en algunos PS modules y pueden ser eludidas accediendo a las funciones **vía la aplicación web**.
+### Confidential Computing
 
+{{#ref}}
+confidential-computing/luks2-header-malleability-null-cipher-abuse.md
+{{#endref}}
 
 {{#include ../banners/hacktricks-training.md}}