wack0/bitlocker-attacksUn elenco di attacchi pubblici a BitLocker
Un elenco di attacchi pubblici a BitLocker. Qualsiasi attacco pubblico con il potenziale di colpire BitLocker ma di cui il metodo esatto non è ancora pubblico (come baton drop) è fuori ambito.
La maggior parte degli attacchi riguarda i casi in cui il VMK è sigillato dal solo TPM, che è l'impostazione predefinita, ed è ciò che BitLocker automatico usa insieme all'escrow della chiave di ripristino su un account Microsoft.
Per impostazione predefinita, a partire da Windows 8, la convalida dell'integrità di Secure Boot viene utilizzata se Secure Boot è abilitato.
Se è necessario sigillare il VMK con il solo TPM, la configurazione più sicura prevede l'uso della convalida dell'integrità legacy con i PCR 0, 2, 4, 7, 11 (e anche di mantenere il sistema completamente aggiornato).
Si noti che questo protegge solo dagli attacchi software.
Gli attacchi hardware sono generalmente utili solo quando l'attaccante ha accesso fisico a un sistema in cui il VMK è sigillato dal solo TPM.
| Riepilogo | Descrizione | Corretto | Periodo di divulgazione pubblica | Scoperto da |
|---|---|---|---|---|
| Sniffing del TPM: bootmgr comunica con il TPM in chiaro | Windows Boot Manager comunica con il TPM in chiaro, quindi se viene utilizzato un chip TPM separato sul bus LPC (cioè non fTPM o "Pluton"/HSP), un analizzatore logico su quel bus può essere usato per estrarre il VMK. Vedi anche post del blog di Pulse Security, codice Verilog per LPC sniffer. | Nessuno, ma i TPM firmware non erano comunque vulnerabili | gennaio 2019 | marcan |
| Debugger hardware: alcuni sistemi non misurano nel PCR7 prima di abilitare un debugger hardware | La TCG EFI Platform Specification for TPM (sezione 6.4) include quanto segue: "Se la piattaforma fornisce una modalità debugger firmware che può essere utilizzata prima dell'ambiente UEFI o se la piattaforma fornisce un debugger per l'ambiente UEFI, allora la piattaforma DEVE estendere un evento EV_EFI_ACTION nel PCR[7] prima di consentire l'uso del debugger" Alcuni sistemi non eseguono questa misurazione prima di abilitare alcuni debugger hardware (come Intel DCI). Pertanto, su un tale sistema vulnerabile, un bypass di Secure Boot (l'accesso fisico ne consentirebbe almeno due con Secure Boot ancora abilitato) o un attacco hardware (scrivendo direttamente sulla flash SPI) può essere utilizzato per abilitare il debugger hardware; impostare un punto di interruzione (ad esempio) all'interno di bootmgr!FvebUnsealCallback può quindi consentire di estrarre il VMK. Vedi anche questo articolo della Digital Forensics Research Conference Europe 2023. | Nessuno, per i sistemi vulnerabili. Un elenco esatto dei sistemi vulnerabili è sconosciuto. | marzo 2023 | Polizia Federale Brasiliana |
| Glitching del fTPM: esecuzione di codice tramite glitching per compromettere completamente lo stato del fTPM | Se un processore/microcontrollore su SoC che implementa un fTPM è vulnerabile al glitching in modo da poter ottenere l'esecuzione di codice nelle prime fasi dell'avvio, l'intero stato del fTPM può essere compromesso, portando all'estrazione del VMK (ecc.). Vedi anche l'articolo di ricerca, payload/ecc. per AMD PSP | IntelME: novembre 2021 / Alder Lake AMD: sconosciuto, nessuno? Altri (ARM64, ARMv7, ecc.): sconosciuto | aprile 2023 | Hans Niklas Jacob, Christian Werling, Robert Buhren, Jean-Pierre Seifert della Technische Universit ät Berlin - SecT |
| Disabilitazione dell'IOMMU all'avvio: la modifica dello storage delle variabili non volatili UEFI con dump/riscrittura della flash può disabilitare l'IOMMU all'avvio | Alcuni firmware UEFI non abiliteranno l'IOMMU all'avvio in base ai dati delle variabili. Scaricando la flash, modificando quelle var(s) e riscrivendola, l'IOMMU verrà disabilitato all'avvio con lo stato non volatile del TPM ancora valido. A quel punto, un attaccante può sovrascrivere la tabella ACPI DMAR usando PCI DMA prima che bootmgr venga avviato, entrare in Modalità provvisoria e usare di nuovo PCI DMA per ottenere una shell SYSTEM. Vedi il writeup. Non è noto in quale componente si trovi; il writeup usa un sistema Intel, il codice pertinente è fornito dall'Intel Firmware Support Package. Non è noto se anche l'equivalente AMD (AGESA/CBS) sia interessato. | Intel Firmware Support Package: sconosciuto AMD AGESA/CBS: sconosciuto | marzo 2026 | Craig S. Blackie di MDSec |
Gli attacchi software sono tipicamente vulnerabilità in bootmgr o in qualche altra applicazione di avvio in cui lo sfruttamento è possibile con le chiavi BitLocker derivate in memoria per un volume arbitrario.
Dove l'esecuzione di codice può essere ottenuta all'interno di un'applicazione di avvio, può essere possibile per un attaccante "evil cleaner" installare un bootkit che a sua volta verrà eseguito con le chiavi derivate in memoria (o quando le chiavi possono ancora essere derivate), compromettendo così un sistema in cui viene usata una password o una chiave di avvio invece di o in aggiunta a un TPM.
