gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-28 13:43:24 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/confidential-computing/luks2-header-ma

Browse Source
This commit is contained in:
Translator
2025-11-15 16:36:19 +00:00
parent 420929d30a
commit d51d7541f5
2 changed files with 183 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files

141
src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md Normal file
View File

@@ -0,0 +1,141 @@
# Malleabilità dell'header LUKS2 e abuso del Null-Cipher nelle Confidential VMs
{{#include ../../banners/hacktricks-training.md}}
## TL;DR
- Molte Confidential VMs (CVMs) basate su Linux che girano su AMD SEV-SNP o Intel TDX usano LUKS2 per lo storage persistente. L'header LUKS2 sul disco è malleabile e non è protetto per integrità contro attaccanti adiacenti allo storage.
- Se la cifratura del segmento dati nell'header è impostata su un null cipher (es., "cipher_null-ecb"), cryptsetup lo accetta e il guest legge/scrive trasparentemente in chiaro pur credendo che il disco sia cifrato.
- Fino a e incluso cryptsetup 2.8.0, i null cipher potevano essere usati per i keyslots; da 2.8.1 vengono rifiutati per keyslots con password non vuote, ma i null cipher restano ammessi per i segmenti del volume.
- La remote attestation di solito misura il codice/config del VM, non header LUKS esterni e mutabili; senza validazione/measurements espliciti, un attaccante con accesso in scrittura al disco può forzare I/O in chiaro.
## Contesto: formato on-disk di LUKS2 (cosa importa per gli attaccanti)
- Un device LUKS2 inizia con un header seguito dai dati cifrati.
- L'header contiene due copie identiche di una sezione binaria e una sezione di metadata JSON, più uno o più keyslots.
- I metadata JSON definiscono:
- i keyslot abilitati e la loro wrapping KDF/cipher
- i segmenti che descrivono l'area dati (cipher/mode)
- digest (es., hash della chiave del volume per verificare le passphrase)
- Valori tipicamente sicuri: keyslot KDF argon2id; cifratura del keyslot e dei segmenti dati aes-xts-plain64.
Ispeziona rapidamente il cipher del segmento direttamente dal 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 principale
- Gli header LUKS2 non sono autenticati contro manomissioni dello storage. Un host/storage attacker può riscrivere i metadata JSON accettati da cryptsetup.
- A partire da cryptsetup 2.8.0, sono accettati header che impostano la cifratura di un segmento su cipher_null-ecb. The null cipher ignores keys and returns plaintext.
- Fino alla 2.8.0, null ciphers potevano anche essere usati per i keyslots (il keyslot si apre con qualsiasi passphrase). Dalla 2.8.1, null ciphers sono respinti per keyslots con password non vuote, ma rimangono consentiti per segments. Cambiare solo il segment cipher continua a produrre plaintext I/O anche dopo la 2.8.1.
## Modello di minaccia: perché l'attestazione non ti ha salvato di default
- I CVM mirano a garantire riservatezza, integrità e autenticità in un host non attendibile.
- L'attestazione remota di solito misura l'immagine VM e la configurazione di lancio, non l'header LUKS mutabile che risiede su uno storage non attendibile.
- Se il tuo CVM si fida di un on-disk header senza robusta validazione/misurazione, un storage attacker può alterarlo impostando una null cipher e il tuo guest monterà un volume in plaintext senza errori.
## Sfruttamento (accesso in scrittura allo storage richiesto)
Prerequisiti:
- Accesso in scrittura al block device LUKS2-encrypted del CVM.
- Il guest usa l'header LUKS2 on-disk senza robusta validazione/attestazione.
Passaggi (ad alto livello):
1) Read the header JSON and identify the data segment definition. Example target field: segments["0"].encryption.
2) Set the data segment encryption to a null cipher, e.g., cipher_null-ecb. Keep keyslot parameters and digest structure intact so the guest’s usual passphrase still “works.”
3) Update both header copies and associated header digests so the header is self-consistent.
4) On next boot, the guest runs cryptsetup, successfully unlocks the existing keyslot with its passphrase, and mounts the volume. Because the segment cipher is a null cipher, all reads/writes are plaintext.
Variant (pre-2.8.1 keyslot abuse): if a keyslot’s area.encryption is a null cipher, it opens with any passphrase. Combine with a null segment cipher for seamless plaintext access without knowing the guest secret.
## Mitigazioni robuste (evitare TOCTOU con detached headers)
Always treat on-disk LUKS headers as untrusted input. Use detached-header mode so validation and opening use the same trusted bytes from protected RAM:
```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
```
Applicare quindi una (o più) delle seguenti misure:
1) MAC the full header
- Calcolare/verificare un MAC sull'intero header prima dell'uso.
- Aprire il volume solo se il MAC è valido.
- Esempi reali: Flashbots tdx-init e Fortanix Salmiac hanno adottato la verifica basata su MAC.
2) Strict JSON validation (backward compatible)
- Dump dei metadata JSON e validare una allowlist rigorosa di parametri (KDF, ciphers, numero/tipo di segmenti, 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>Esempio di validator (imporre campi sicuri)</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) Misurare/attestare l'header
- Rimuovere random salts/digests e misurare l'header sanificato nei PCR di TPM/TDX/SEV o nello stato della policy KMS.
- Rilasciare le chiavi di decrittazione solo quando l'header misurato corrisponde a un profilo approvato e sicuro.
Indicazioni operative:
- Applicare detached header + MAC o una validazione rigorosa; non fidarsi mai direttamente degli on-disk headers.
- I consumatori dell'attestazione dovrebbero negare le versioni del framework pre-patch nelle allow-list.
## Note su versioni e posizione dei manutentori
- I manutentori di cryptsetup hanno chiarito che LUKS2 non è stato progettato per fornire integrità contro la manomissione dello storage in questo contesto; i null ciphers sono mantenuti per compatibilità con le versioni precedenti.
- cryptsetup 2.8.1 (Oct 19, 2025) rifiuta i null ciphers per i keyslots con password non vuote ma consente ancora i null ciphers per i segments.
## Controlli rapidi e triage
- Verificare se la cifratura di qualche segment è impostata su un null cipher:
```bash
cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \
| jq -r '.segments | to_entries[] | "segment=" + .key + ", enc=" + .value.encryption'
```
- Verificare gli algoritmi del keyslot e dei segment prima di aprire il volume. Se non puoi MAC, applica una validazione JSON rigorosa e apri usando il detached header dalla memoria protetta.
## Riferimenti
- [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}}

85
src/pentesting-cloud/pentesting-cloud-methodology.md
View File

@@ -1,4 +1,4 @@
# Metodologia Pentesting Cloud
# Metodologia di Pentesting Cloud
{{#include ../banners/hacktricks-training.md}}
@@ -10,35 +10,35 @@ Ogni cloud ha le sue peculiarità ma, in generale, ci sono alcune **cose comuni
- **Controlli di benchmark**
- Questo ti aiuterà a **capire la dimensione** dell'ambiente e i **servizi utilizzati**
- Permetterà anche di trovare alcune **misconfigurazioni rapide** poiché puoi eseguire la maggior parte di questi test con **strumenti automatici**
- Ti permetterà anche di trovare alcune **misconfigurazioni rapide**, dato che puoi eseguire la maggior parte di questi test con **strumenti automatizzati**
- **Enumerazione dei servizi**
- Probabilmente non troverai molte altre misconfigurazioni se hai eseguito correttamente i controlli di benchmark, ma potresti trovare alcune cose che non sono state cercate nei controlli di benchmark.
- Questo ti permetterà di sapere **cosa viene esattamente utilizzato** nell'ambiente cloud
- Questo aiuterà molto nei passi successivi
- **Controlla le risorse esposte**
- Questo può essere fatto durante la sezione precedente: devi **scoprire tutto ciò che è potenzialmente esposto** a Internet in qualche modo e come può essere accessibile.
- Qui intendo l'infrastruttura **esposta manualmente** come istanze con pagine web o altre porte esposte, e anche altri **servizi gestiti cloud che possono essere configurati** per essere esposti (ad esempio DB o bucket)
- Poi dovresti verificare **se quella risorsa è effettivamente esposta o meno** (informazioni riservate? vulnerabilità? misconfigurazioni nel servizio esposto?)
- **Verifica le autorizzazioni**
- Qui dovresti **scoprire tutte le autorizzazioni di ciascun ruolo/utente** all'interno del cloud e come vengono utilizzate
- Troppi account **con privilegi elevati** (controllano tutto)? Chiavi generate non usate?... La maggior parte di questi controlli dovrebbe essere già stata fatta nei test di benchmark
- Se il cliente usa OpenID, SAML o un'altra **federazione**, potrebbe essere necessario chiedere ulteriori **informazioni** su **come viene assegnato ciascun ruolo** (non è lo stesso che il ruolo admin sia assegnato a 1 utente o a 100)
- Non basta **identificare** quali utenti hanno permessi **admin** "\*:\*". Ci sono molte **altre autorizzazioni** che, a seconda dei servizi usati, possono essere molto **sensibili**.
- Inoltre, esistono possibili vie di **privesc** sfruttando le autorizzazioni. Tutte queste cose devono essere prese in considerazione e devono essere riportati **quanti più percorsi di privesc possibile**.
- **Verifica le integrazioni**
- È molto probabile che all'interno dell'ambiente cloud siano usate **integrazioni con altri cloud o SaaS**.
- Per le **integrazioni del cloud che stai auditando** con altre piattaforme dovresti notificare **chi ha accesso per (ab)usare quell'integrazione** e dovresti chiedere **quanto è sensibile** l'azione eseguita.\
Per esempio, chi può scrivere in un bucket AWS da cui GCP sta prendendo dati (chiedi quanto è sensibile l'azione in GCP nel trattare quei dati).
- Per le **integrazioni all'interno del cloud che stai auditando** provenienti da piattaforme esterne, dovresti chiedere **chi ha accesso esterno per (ab)usare quell'integrazione** e verificare come vengono utilizzati quei dati.\
Per esempio, se un servizio utilizza un'immagine Docker ospitata in GCR, dovresti chiedere chi ha accesso per modificarla e quali informazioni sensibili e accessi otterrà quell'immagine quando eseguita all'interno di un cloud AWS.
- Probabilmente non troverai molte altre misconfigurazioni qui se hai eseguito correttamente i controlli di benchmark, ma potresti trovare alcune che non sono state cercate nei test di benchmark.
- Questo ti permetterà di sapere **cosa è esattamente utilizzato** nell'ambiente cloud
- Questo aiuterà molto nei passaggi successivi
- **Verifica degli asset esposti**
- Questo può essere fatto durante la sezione precedente: devi **scoprire tutto ciò che è potenzialmente esposto** su Internet in qualche modo e come può essere accessibile.
- Qui intendo l'**infrastruttura esposta manualmente** come istanze con pagine web o altre porte esposte, e anche altri **servizi gestiti cloud che possono essere configurati** per essere esposti (come DBs o bucket)
- Poi dovresti verificare **se quella risorsa può essere esposta o meno** (informazioni confidenziali? vulnerabilità? misconfigurazioni nel servizio esposto?)
- **Controlla le autorizzazioni**
- Qui dovresti **scoprire tutte le autorizzazioni di ogni ruolo/utente** all'interno del cloud e come vengono utilizzate
- Troppi account **altamente privilegiati** (controllano tutto)? Chiavi generate non utilizzate?... La maggior parte di questi controlli dovrebbe essere già stata fatta nei test di benchmark
- Se il cliente utilizza OpenID o SAML o un'altra **federazione**, potrebbe essere necessario chiedere ulteriori **informazioni** su **come viene assegnato ciascun ruolo** (non è la stessa cosa che il ruolo admin sia assegnato a 1 utente o a 100)
- Non è **sufficiente identificare** quali utenti hanno permessi **admin** "\*:\*". Ci sono molte **altre autorizzazioni** che, a seconda dei servizi utilizzati, possono essere molto **sensibili**.
- Inoltre, esistono **potenziali privesc** da seguire abusando delle autorizzazioni. Tutte queste cose dovrebbero essere prese in considerazione e dovrebbero essere segnalati **il maggior numero possibile di percorsi di privesc**.
- **Verifica delle integrazioni**
- È molto probabile che **integrazioni con altri clouds o SaaS** vengano utilizzate all'interno dell'ambiente cloud.
- Per le **integrazioni del cloud che stai auditando** con altre piattaforme dovresti notificare **chi ha accesso ad (ab)usare quell'integrazione** e dovresti chiedere **quanto è sensibile** l'azione che viene eseguita.\
Ad esempio, chi può scrivere in un bucket AWS da cui GCP ottiene dati (chiedi quanto è sensibile l'azione in GCP che tratta quei dati).
- Per le **integrazioni all'interno del cloud che stai auditando** provenienti da piattaforme esterne, dovresti chiedere **chi ha accesso esternamente ad (ab)usare quell'integrazione** e verificare come vengono utilizzati quei dati.\
Ad esempio, se un servizio usa un'immagine Docker ospitata in GCR, dovresti chiedere chi ha accesso a modificarla e quali informazioni sensibili e accessi otterrà quell'immagine quando eseguita all'interno di un cloud AWS.
## Strumenti multi-cloud
## Strumenti Multi-Cloud
Esistono diversi strumenti che possono essere usati per testare diversi ambienti cloud. I passaggi di installazione e i link saranno indicati in questa sezione.
Ci sono diversi strumenti che possono essere usati per testare diversi ambienti cloud. I passaggi di installazione e i link saranno indicati in questa sezione.
### [PurplePanda](https://github.com/carlospolop/purplepanda)
Uno strumento per **identificare configurazioni errate e percorsi di privesc nei cloud e tra cloud/SaaS.**
Uno strumento per **identificare configurazioni errate e percorsi di privesc nei clouds e attraverso clouds/SaaS.**
{{#tabs }}
{{#tab name="Install" }}
@@ -170,7 +170,7 @@ steampipe check all
<summary>Controlla tutti i progetti</summary>
Per controllare tutti i progetti è necessario generare il file `gcp.spc` indicando tutti i progetti da testare. Puoi semplicemente seguire le istruzioni del seguente script
Per controllare tutti i progetti devi generare il file `gcp.spc` indicando tutti i progetti da testare. Puoi seguire le indicazioni del seguente script
```bash
FILEPATH="/tmp/gcp.spc"
rm -rf "$FILEPATH" 2>/dev/null
@@ -194,7 +194,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
```
</details>
Per controllare **altri insight GCP** (utile per enumerare servizi) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
Per controllare **altri insight GCP** (utile per enumerare i servizi) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
Per controllare il codice Terraform GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
@@ -225,9 +225,9 @@ cd steampipe-mod-aws-compliance
steampipe dashboard # To see results in browser
steampipe check all --export=/tmp/output4.json
```
Per controllare il codice Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
Altri plugin AWS per Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
{{#endtab }}
{{#endtabs }}
@@ -238,11 +238,11 @@ Richiede python2.7 e sembra non essere mantenuto.
### Nessus
Nessus ha una scansione _**Audit Cloud Infrastructure**_ che supporta: AWS, Azure, Office 365, Rackspace, Salesforce. Sono necessarie alcune configurazioni aggiuntive in **Azure** per ottenere un **Client Id**.
Nessus dispone di una scansione _**Audit Cloud Infrastructure**_ che supporta: AWS, Azure, Office 365, Rackspace, Salesforce. Sono necessarie alcune configurazioni aggiuntive in **Azure** per ottenere un **Client Id**.
### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
Cloudlist è uno **strumento multi-cloud per ottenere Assets** (Hostnames, IP Addresses) dai fornitori cloud.
Cloudlist è uno **strumento multi-cloud per ottenere Assets** (Hostnames, IP Addresses) dai Cloud Providers.
{{#tabs }}
{{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
### [**cartography**](https://github.com/lyft/cartography)
Cartography è uno strumento Python che consolida gli asset dell'infrastruttura e le relazioni tra di essi in una visualizzazione a grafo intuitiva alimentata da un database Neo4j.
Cartography è uno strumento in Python che consolida le risorse dell'infrastruttura e le relazioni tra di esse in una vista a grafo intuitiva alimentata da un database Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \
### [**starbase**](https://github.com/JupiterOne/starbase)
Starbase raccoglie asset e relazioni da servizi e sistemi, incluse infrastrutture cloud, applicazioni SaaS, controlli di sicurezza e altro, in una visualizzazione a grafo intuitiva supportata dal database Neo4j.
Starbase raccoglie asset e relazioni da servizi e sistemi, tra cui l'infrastruttura cloud, le applicazioni SaaS, i controlli di sicurezza e altro, in una vista grafica intuitiva supportata dal database Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
### [**SkyArk**](https://github.com/cyberark/SkyArk)
Individua gli utenti più privilegiati nell'ambiente AWS o Azure scansionato, inclusi gli AWS Shadow Admins. Usa powershell.
Scopri gli utenti con i privilegi più elevati nell'ambiente AWS o Azure scansionato, inclusi gli AWS Shadow Admins. Usa powershell.
```bash
Import-Module .\SkyArk.ps1 -force
Start-AzureStealth
@@ -372,13 +372,13 @@ Scan-AzureAdmins
```
### [Cloud Brute](https://github.com/0xsha/CloudBrute)
Uno strumento per trovare l'infrastruttura di un'azienda (target), file e app sui principali provider cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
Uno strumento per trovare l'infrastruttura, i file e le app di un'azienda (target) sui principali cloud provider (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
### [CloudFox](https://github.com/BishopFox/cloudfox)
- CloudFox è uno strumento per trovare exploitable attack paths nella cloud infrastructure (attualmente supportati solo AWS & Azure con GCP in arrivo).
- È un enumeration tool pensato per integrare il pentesting manuale.
- Non crea né modifica alcun dato all'interno dell'ambiente cloud.
- CloudFox è uno strumento per identificare percorsi di attacco sfruttabili nell'infrastruttura cloud (attualmente supportati solo AWS & Azure, GCP in arrivo).
- È uno strumento di enumeration pensato per integrare il pentesting manuale.
- Non crea né modifica alcun dato nell'ambiente cloud.
### More lists of cloud security tools
@@ -410,13 +410,12 @@ aws-security/
azure-security/
{{#endref}}
### Attack Graph
## Funzionalità comuni della sicurezza cloud
[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “attack graph” delle risorse in una subscription Azure. Permette a red teams e pentesters di visualizzare la attack surface e le opportunità di pivot all'interno di un tenant, e potenzia i tuoi defender per orientarsi rapidamente e prioritizzare il lavoro di incident response.
### Office365
Hai bisogno di **Global Admin** o almeno **Global Admin Reader** (nota però che Global Admin Reader è un po' limitato). Tuttavia, tali limitazioni si presentano in alcuni moduli PS e possono essere bypassate accedendo alle funzionalità **tramite l'applicazione web**.
### Confidential Computing
{{#ref}}
confidential-computing/luks2-header-malleability-null-cipher-abuse.md
{{#endref}}
{{#include ../banners/hacktricks-training.md}}