baton drop (CVE-2022-21894): vulnerabilità di bypass della funzionalità di sicurezza Secure Boot

Le applicazioni di avvio di Windows consentono all'impostazione truncatememory di rimuovere blocchi di memoria contenenti intervalli "persistenti" di dati serializzati dalla mappa di memoria, portando al bypass di Secure Boot.

• L'elemento BCD truncatememory rimuoverà tutta la memoria al di sopra di un indirizzo fisico specificato dalla mappa di memoria.
• Questa operazione viene eseguita per ogni applicazione di avvio durante l'inizializzazione, prima che i criteri Secure Boot serializzati vengano letti dalla memoria.
• Pertanto, tale elemento può essere utilizzato per rimuovere i criteri Secure Boot serializzati dalla mappa di memoria.
• Ciò consentirà l'uso di impostazioni pericolose in un'applicazione di avvio (bootdebug, testsigning, nointegritychecks), rompendo così Secure Boot.

Questo problema è stato corretto con due modifiche distinte:

• Dopo aver tentato di caricare dei criteri Secure Boot serializzati, se non viene caricato alcun criterio, se Secure Boot è abilitato, se l'applicazione di avvio non è stata caricata direttamente dal firmware UEFI e se l'applicazione di avvio non è bootmgr, l'inizializzazione dell'applicazione di avvio fallisce.
• Quando si carica un'applicazione di avvio, se questa ha una risorsa VERSIONINFO contenente un OriginalFilename e se tale nome file è incluso in un blocklist (contenente bootmgr.exe e hvloader.exe; in Nickel, è stato aggiunto hvloader.efi ma non è stato backportato), il caricamento fallisce.
  • In Windows 8 e Windows 8.1, hvloader.exe non è incluso nella blocklist di winload - originariamente lo era, il che ha rotto il caricamento di Hyper-V!
  • Dalla versione 1809 di Windows 10, se un determinato bit dei flag è impostato (usato con l'elemento flightedbootmgr per caricare bootmgr dal disco), OriginalFilename deve essere bootmgr.exe.

Sfruttamento

L'attaccante deve assicurarsi che i criteri Secure Boot serializzati vengano allocati al di sopra di un indirizzo fisico noto.

• Per impostazione predefinita, vengono allocati all'indirizzo più basso possibile.
• Originariamente, i criteri Secure Boot serializzati venivano allocati dopo il loro caricamento, prima di utilizzare qualsiasi configurazione caricata dal BCD.
  • Dalla RS1, i criteri Secure Boot serializzati vengono allocati durante il caricamento di un'applicazione di avvio.
  • Dalla RS2, qualsiasi criterio Secure Boot serializzato esistente viene liberato quando si serializzano i criteri Secure Boot.
• I criteri Secure Boot serializzati vengono riallocati se, durante il caricamento di un'applicazione di avvio, osdevice della voce BCD è una partizione crittografata con BitLocker in cui il VMK è stato derivato utilizzando il TPM.
  • Questo può essere finto impostando il bit 0 dei flag di chiave dopo il corretto de-sigillamento del TPM; questo bit può essere impostato manualmente nei metadati BitLocker, con metadati aggiuntivi aggiunti per specificare che Secure Boot viene utilizzato per la convalida dell'integrità.

L'elemento avoidlowmemory può essere utilizzato per garantire che tutte le allocazioni di memoria fisica avvengano al di sopra di un indirizzo fisico specificato:

• Dalla versione Windows 10, questo elemento non è consentito se VBS è abilitato, ma poiché viene utilizzato durante l'inizializzazione dell'applicazione di avvio, prima che i criteri Secure Boot serializzati vengano letti dalla memoria, il caricamento di bootmgr e la specifica di un percorso BCD personalizzato (usando l'elemento bcdfilepath aka custom:22000023) possono essere utilizzati per bypassare questo limite.
• Se BitLocker è presente sul volume del sistema operativo, o il sistema di destinazione esegue TH1 o TH2, questo metodo fallirà; è quindi anche possibile eseguire l'attacco una volta con un bootmgr di Windows 8.x per disabilitare VBS e poi tornare al bootloader originale.
  • Windows 10 ha modificato l'inizializzazione dell'applicazione di avvio per limitare una volta tutti i PCR del TPM, quindi un bootmgr di Windows 8.x non riuscirà a de-sigillare il VMK su un sistema Windows 10+.

hvloader.efi può essere caricato con l'elemento nointegritychecks per caricare una mcupdate.dll autofirmata, il cui punto di ingresso verrà chiamato prima di ExitBootServices.

In alternativa, sui sistemi non AMD64, winload.efi precedente a TH2 può essere utilizzato con l'elemento testsigning; questo consente binari autofirmati con l'EKU szOID_NT5_CRYPTO nel certificato.

Sui sistemi ARMv7, per ottenere l'esecuzione di codice sarà necessario caricare una hal.dll autofirmata e modificata con un'importazione verso mcupdate.dll.

Sui sistemi x86 e AMD64, il file caricato come mcupdate.dll deve essere denominato mcupdate_*.dll, dove * è la stringa del produttore CPUID (GenuineIntel, AuthenticAMD, ecc.).

Sui sistemi ARM64, questa tecnica non può essere utilizzata perché la prima build di produzione firmata disponibile è una WinPE di RS2; quindi attualmente è possibile eseguire solo codice in modalità tethered (usando bootdebug).

File inclusi

Questo repository include i seguenti file:

• Viene fornito il codice sorgente di un semplice payload. Questo payload attende semplicemente un interrupt all'infinito, poiché senza trovare funzioni e variabili interessanti nell'applicazione di avvio chiamante, è impossibile fare qualsiasi altra cosa.
  • Poiché mcupdate.dll viene eseguita a un indirizzo virtuale con paging abilitato, è impossibile chiamare direttamente le funzioni EFI (il paging deve essere disabilitato per chiamare le funzioni EFI; tornare a un indirizzo virtuale con paging disattivato non porta a nulla di buono).
  • Per chiamare le funzioni EFI, un payload dovrebbe chiamare BlImgLoadPEImageEx o BlImgLoadPEImageFromSourceBuffer con il bit 0 impostato nei flag per caricare un payload aggiuntivo in un mapping 1:1 tra indirizzo fisico e indirizzo virtuale.
    • In alternativa, può chiamare BlImgAllocateImageBuffer con lo stesso bit impostato per allocare memoria in un mapping 1:1 tra indirizzo fisico e indirizzo virtuale; quindi caricare un payload da sé (o rimapparsi lì).
• Un ISO che sfrutta questo problema su AMD64 utilizzando bootmgfw di Windows 8 RTM e hvloader di TH1 RTM.
  • Il payload usato qui stampa un messaggio sullo schermo utilizzando una funzione di hvloader ottenuta tramite offset e poi entra in un loop infinito.
• Un ISO che sfrutta questo problema su AMD64 utilizzando bootmgr di RS1 e hvloader di TH1 RTM.

Poscritto

Questo problema può essere utilizzato per dumpare le chiavi BitLocker (dove Secure Boot viene utilizzato per la convalida dell'integrità).

• Sebbene sia possibile, il metodo esatto per ottenere l'esecuzione di codice con le chiavi BitLocker derivate per un volume arbitrario in memoria non verrà divulgato.

La correzione di questo problema ha anche risolto un altro problema che non ha un CVE.

• bootmgr ignora qualsiasi keytable BitLocker già presente in memoria e ne alloca una nuova, senza cancellare quella vecchia.
  • Pertanto, un attaccante potrebbe caricare bootmgr RS2+ da bootmgr (specificando un osdevice arbitrario in cui Secure Boot viene utilizzato per la convalida dell'integrità), avviare WinPE, caricare un driver vulnerabile noto e usarlo per cercare e dumpare la keytable BitLocker esistente nella memoria fisica.

Nessuna applicazione di avvio vulnerabile nota è stata ancora revocata.

• Fino a quando non avverrà la revoca, un attaccante può semplicemente portare i propri bootloader vulnerabili.
• La revoca farebbe fallire l'avvio di tutti i supporti di installazione/ripristino di Windows esistenti e dei vecchi backup.
  • Il fallimento dell'avvio avverrebbe anche con Secure Boot disabilitato, a causa della verifica della propria firma da parte di bootmgr.

Aggiornamento (2023-05-10)

C'è stata una revoca incompleta, e un altro CVE (CVE-2023-24932). Ci sono ancora bootmgfw vulnerabili che non sono stati revocati, oltre a patch aggiuntive che correggono solo il caso in cui bootmgr carica bootmgr. È bastato un bootkit copiato e incollato per far agire Microsoft ;)
Se sei abbastanza creativo, troverai un modo per aggirare la revoca di oltre 2000 file bootmgfw ;)