Attacchi 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.

Contenuti

• Attacchi hardware
• Attacchi software

Attacchi hardware

Gli attacchi hardware sono generalmente utili solo quando l'attaccante ha accesso fisico a un sistema in cui il VMK è sigillato dal solo TPM.

Attacchi software

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.

dangerous association

Un sistema vulnerabile avrà installati gli aggiornamenti di maggio 2022 o giugno 2022, ma non eventuali aggiornamenti successivi.

Il GUID delle opzioni associate fa parte dei dati sottoposti a hash, quindi l'elemento device utilizzato deve essere contrassegnato come non verificato.
Non ci sono elementi utilizzabili su Windows 7 e precedenti (anche se con impostazioni personalizzate non predefinite potrebbe essere comunque possibile).
Su Windows 8 e versioni successive, osloader!osdevice non è verificato per impostazione predefinita e come tale può essere utilizzato.
Il modo più semplice per sfruttare questo problema è usare l'editor raw di dispositivi BCD, bcdeditmod, anche se è possibile anche modificare manualmente l'hive del registro BCD (prova a capirlo da solo).

Lo sfruttamento comporta:

• prendi il BCD dal dispositivo di destinazione, crea due elementi device
• copia l'osdevice da {default} al primo
• imposta il GUID delle opzioni associate in {default}!osdevice sul primo elemento device
• imposta il GUID delle opzioni associate in {first}!osdevice sul secondo elemento device
• imposta qualsiasi opzione "pericolosa" (come debug) nel secondo elemento device
• avvia il dispositivo di destinazione usando quel BCD e lo stesso binario bootmgfw che stava usando

bitpixie

Questa vulnerabilità è esistita per oltre 17 anni, la build più antica conosciuta in cui è stata introdotta è 6.0.5231.2 (winmain_idx03.051004-2120) dell'ottobre 2005.
Dove viene usata la convalida dell'integrità Secure Boot, un attacco di downgrade funzionerebbe ancora per sfruttare questa vulnerabilità.Configura un server di avvio PXE con un bootmgfw.efi vulnerabile (dove viene utilizzata la convalida dell'integrità legacy, deve essere il bootmgfw.efi del dispositivo di destinazione) rinominato correttamente per l'avvio EFI.

Per il BCD, configura una voce predefinita in cui device è l'osdevice crittografato con BitLocker; path è "\"; e una sequenza di ripristino.

La sequenza di ripristino deve puntare a una singola voce startup, dove device è boot, path punta a un'applicazione EFI da eseguire (dal server PXE); e pxesoftreboot è abilitato.

Quando Secure Boot è disabilitato, quell'applicazione EFI può essere semplicemente un'applicazione che esegue la scansione della memoria fisica alla ricerca di una keytable BitLocker da dumpare.

Quando Secure Boot è abilitato, quell'applicazione EFI può usare un bypass noto di Secure Boot (dove è richiesto l'accesso fisico se necessario).
Per sfruttare un'applicazione di avvio di Windows in questo modo, dovrai sostituire il BCD con il secondo sul server PXE.
Ciò significa premere un tasto freccia durante l'avvio di bootmgr per forzare la visualizzazione del menu di avvio; e poi sostituire il BCD sul server PXE in quel momento.

decrittazione con un pulsante

Lo sfruttamento prevede:

• Esegui il dump dell'osvolume protetto da BitLocker in un'immagine del disco. Questo metodo per ottenere l'FVEK comporta una reale perdita di dati!
• Avvia in WinRE usando qualsiasi mezzo (forzalo con la riparazione all'avvio se necessario, o imposta semplicemente l'elemento BCD bootsequence, ecc.).
• Avvia un reset (Risoluzione dei problemi -> Reimposta il PC -> Rimuovi tutto). È più veloce scegliere "Reinstallazione locale". Assicurati di scegliere "Rimuovi solo i miei file".
  • Scegliere di "mantenere i file" richiederà la chiave di ripristino.
  • Se il WinRE del sistema non è vulnerabile, richiederà anche una chiave di ripristino.
• Quando il reset arriva a circa il 98%, spegni forzatamente il sistema (tenendo premuto il pulsante di accensione per 7 secondi / ecc.).
• Riaccedi il sistema: dovrebbe avviarsi di nuovo in WinRE e mostrare un errore. Chiudendo l'errore dovrebbe riavviarsi.
• Quando vedi la schermata blu "aggiornamento", premi Shift+F10 per ottenere una shell.
• Esegui manage-bde -pause C: seguito da manage-bde -protectors -delete C:
• Spegni forzatamente il sistema (di nuovo).

A questo punto, i metadati BitLocker su disco conterranno un VMK in chiaro.
Esegui il dump del VMK e usalo per decrittare l'FVEK.
L'FVEK decrittato può essere usato sull'immagine del disco creata in precedenza per decrittare la partizione.

Nota: sono riuscito a sfruttare questo problema solo su Windows 10 in circostanze molto specifiche (BitLocker solo TPM senza chiave di ripristino). Tuttavia, altri sono riusciti a sfruttare questo problema usando un WinRE vulnerabile su Windows 11 (Nickel).

perdita di RAM

Per quanto ne so, questa vulnerabilità esiste da quando esiste il boot manager: sembra essere presente già nel 6.0.5098.0 (winmain_beta1.050628-1740) del giugno 2005, anche se questo precede il BCD, quindi lo sfruttamento sarebbe diverso in build così vecchie. Il codice rilevante sembra esistere anche prima (il codice relativo al ramdisk sembra essere lo stesso nella build 5048 dell'aprile 2005), ma la build 5098 è la build di cui esiste il dump più antica con BitLocker presente in qualche forma.

Per sfruttarlo, devi configurare una voce predefinita e una sequenza di ripristino come in bitpixie. Questo serve a far sì che le chiavi vengano derivate per il dispositivo del sistema operativo quando il file viene caricato.

La sequenza di ripristino deve avere una voce di dispositivo aggiuntiva per configurare il ramdisk. Usa bcdeditmod per questo. Usa qui un elemento personalizzato come custom:21100000. Un esempio di voce di dispositivo da usare qui sarebbe !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]] - vorrai sostituire qui il dispositivo a blocchi part2 con quello presente nel BCD del sistema di destinazione.

Il file può poi essere dumpato dalla memoria usando qualsiasi metodo funzioni per te. Preferisco usare un winload meno recente per caricare un mcupdate auto-firmato tramite il menu delle opzioni avanzate, ma ci sono altre opzioni disponibili (ad esempio PXE soft reboot in un sistema operativo di terze parti; il memory dumping da WinPE tramite un bugcheck o un driver vulnerabile noto è possibile, ma winload marcherà l'area di memoria come libera nella mappa di memoria NT, quindi potrebbe essere sovrascritta senza altre impostazioni per marcare quella memoria come danneggiata/ecc. in winload).

Una implementazione proof of concept del mio metodo preferito è inclusa in questo repository come ramleak.zip. Leggi il readme incluso per le istruzioni d'uso.

Un ringraziamento a Maxim Suhanov: questo è stato ispirato dalla lettura del writeup di CrashXTS e dall'aver trovato un altro modo per eventualmente dumpare hiberfil.sys.

E ora i miei pensieri su questo bug e su yellowkey:

Questa è stata la prima volta in cui ho avuto un vero problema con la segnalazione a MSRC, ed è stato principalmente un malinteso da parte loro relativo a Secure Boot. Dato che è stato rilasciato un altro 0day di BitLocker, ho deciso di rilasciare questo ora; ho tenuto questo per quasi un anno chiedendomi cosa farne.

A differenza di yellowkey, non farò dichiarazioni esagerate sul fatto che questo sia una "backdoor": a mio parere non penso che yellowkey sia una backdoor, il componente correlato ha a che fare con WinPE (non specifico di WinRE), e la principale "vuln" è riuscire a far eliminare winpeshl.ini per raggiungere quel percorso di codice; posso capire perfettamente perché Microsoft ritenesse che eliminarlo in uno scenario WinRE+BitLocker non fosse possibile.

Dato che caricare un ramdisk da una partizione crittografata con BitLocker è in realtà una funzionalità dell'ambiente di avvio, anche se ho dovuto usare un trucco esistente per farlo funzionare davvero, altri potrebbero dire che si tratta di una backdoor se volessero, ma non mi spingerò così in là. L'ambiente di avvio è complesso (e continua a crescere, l'ultimo bootmgfw_ex.efi non entra più in un'immagine da 2.88MB - fine di un'era), sono state scoperte diverse vulnerabilità a causa del modo in cui alcune funzionalità interagiscono tra loro.