Windows aggiornato ma ancora vulnerabile: BlackX aggira Secure Boot

Un computer Windows completamente aggiornato, con la protezione Secure Boot attiva e tutte le patch di sicurezza installate, può comunque risultare vulnerabile a un attacco capace di compromettere il sistema prima ancora che l’avvio sia completato. Kaspersky ha documentato una campagna di cyberspionaggio che utilizza BlackX, nuovo bootkit UEFI in grado di aggirare le protezioni di avvio sfruttando una vulnerabilità nota dal 2022.

La vicenda riporta alla memoria BlackLotus, il malware che nell’ottobre 2022 comparve sui forum criminali al prezzo di 5.000 dollari. A marzo 2023, ESET dimostrò che BlackLotus funzionava realmente, riuscendo a compromettere anche Windows 11 con Secure Boot abilitato. Sembrava che gli interventi successivi di Microsoft avessero progressivamente neutralizzato la minaccia.

La nuova indagine pubblicata da Kaspersky racconta qualcosa di diverso: all’inizio dell’anno i ricercatori hanno individuato attacchi contro organizzazioni diplomatiche in Tagikistan, Uzbekistan e Turkmenistan. Gli aggressori utilizzavano BlackX, una variante tecnicamente vicina a BlackLotus, installata su macchine che disponevano già degli aggiornamenti Windows.

BlackX sfrutta una vecchia vulnerabilità per superare Secure Boot

Per comprendere la gravità della scoperta bisogna considerare il ruolo di UEFI Secure Boot: il firmware verifica le firme crittografiche dei componenti coinvolti nell’avvio e dovrebbe impedire l’esecuzione di codice non autorizzato prima del caricamento del sistema operativo. Il controllo si basa su database di certificati e firme attendibili, oltre che su un elenco di elementi esplicitamente revocati.

BlackX prende di mira proprio il meccanismo di fiducia attraverso Baton Drop, CVE-2022-21894, una vulnerabilità di aggiramento di Secure Boot corretta da Microsoft a gennaio 2022. Sebbene la falla sia nota da quasi 5 anni, la disponibilità di vecchi componenti di avvio Microsoft firmati e vulnerabili può consentirne ancora lo sfruttamento.

Se un aggressore riesce a introdurre una precedente versione del bootloader, firmata con un certificato tuttora considerato attendibile dal firmware, può tentare un attacco di rollback: riportare una parte della catena di avvio a una versione insicura, anche quando Windows dispone già dei file aggiornati.

BlackX riprende il metodo di BlackLotus per arrivare a installare proprie Machine Owner Keys (MOK), chiavi che consentono di autorizzare ulteriori applicazioni EFI: dopo aver superato il controllo iniziale, il malware cerca di rendere persistente l’esecuzione dei propri componenti senza dover sfruttare la vulnerabilità a ogni riavvio.

Come BlackX si installa nei computer compromessi

L’analisi di Kaspersky descrive una procedura di installazione piuttosto elaborata: gli aggressori distribuiscono un eseguibile chiamato inst.exe e un secondo file, privo di estensione, identificato come PVMDIJGKAX2 e crittografato. Quest’ultimo contiene i componenti necessari all’installazione.

Il programma deposita successivamente diversi componenti nelle partizioni di sistema e nella EFI System Partition (ESP), la partizione formattata FAT32 che ospita i file necessari all’avvio UEFI. Attraverso la vulnerabilità Baton Drop, BlackX manipola la catena di caricamento e prepara l’esecuzione del proprio codice nelle fasi precedenti all’inizializzazione completa di Windows.

Un bootkit che riesce a posizionarsi all’interno della partizione EFI può ottenere un controllo molto profondo sull’avvio senza essere, tecnicamente, un impianto residente nel firmware. Resta comunque una minaccia difficile da individuare con i normali strumenti di verifica dei processi Windows.

Superata la fase UEFI, BlackX introduce un driver malevolo nel kernel Windows: è il componente incaricato di interferire con le soluzioni di protezione, riducendo la capacità del sistema di osservare le attività successive.

Il driver individuato dai ricercatori è firmato con un certificato associato a un’organizzazione cinese: come sottolineato più volte, la presenza di una firma non dimostra l’affidabilità del codice. Indica soltanto che un determinato certificato ha partecipato al processo di firma, ferma restando la necessità di verificarne validità e attendibilità.

Perché Windows aggiornato non era realmente protetto

I ricercatori ritenevano, in un primo tempo, che le imprese colpite da BlackX avessero trascurato l’installazione delle patch. Le verifiche hanno dimostrato il contrario: i sistemi risultavano aggiornati.

La protezione rimaneva incompleta perché mancava la revoca del certificato Windows Production PCA 2011, utilizzato da Microsoft per firmare i precedenti componenti di avvio. L’azienda guidata da Satya Nadella ha infatti predisposto un processo di migrazione verso nuovi certificati 2023 e un aggiornamento dell’elenco UEFI DBX (Forbidden Signature Database), che permette al firmware di rifiutare componenti precedentemente attendibili.

Microsoft ha previsto procedure graduali, anche per evitare problemi ai computer con configurazioni dual boot, supporti di ripristino non aggiornati o firmware incompatibili. Alla data del rapporto Kaspersky, la fase di applicazione generalizzata della revoca non risultava ancora completata.

Il certificato PCA 2011 è inoltre scaduto il 19 ottobre 2026, ma la scadenza non equivale automaticamente alla sua presenza nella DBX. Secondo Kaspersky, i vecchi componenti vulnerabili possono ancora caricarsi se il firmware non dispone della revoca necessaria.

Come verificare la protezione e applicare le mitigazioni Microsoft

Per prima cosa è opportuno verificare che Secure Boot sia attivo, aprendo msinfo32 da Windows e controllando la voce Stato avvio protetto: la presenza dell’indicazione Attivato conferma però soltanto che la funzione è abilitata, non che il database delle revoche sia aggiornato.

La documentazione Microsoft KB5025885, collegata alle mitigazioni della vulnerabilità CVE-2023-24932 e alla protezione della catena di avvio, descrive la procedura per aggiornare i certificati UEFI, sostituire il Windows Boot Manager e applicare le revoche.

Gli amministratori possono verificare da PowerShell, con privilegi elevati, lo stato della migrazione attraverso il comando (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing").UEFICA2023Status. Il valore Updated indica che il Boot Manager aggiornato e i nuovi certificati hanno raggiunto lo stato previsto dalla procedura Microsoft; non dimostra, da solo, che anche la revoca sia attiva.

Per controllare la presenza del certificato revocato nel file DBX, Microsoft cita l’utilizzo del comando [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'.

Il risultato True conferma che la stringa cercata compare nel database di revoca. Un’ulteriore verifica consiste nel consultare il registro eventi Windows e cercare l’evento 1037, associato all’applicazione della revoca PCA 2011.

Per completare la procedura, Microsoft prevede anche l’impostazione della voce AvailableUpdates sotto HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot e l’esecuzione dell’attività pianificata \Microsoft\Windows\PI\Secure-Boot-Update. Non conviene però applicare indiscriminatamente le modifiche: prima bisogna aggiornare firmware e componenti di avvio, salvare la chiave di ripristino BitLocker e predisporre supporti compatibili. Una revoca anticipata può rendere inutilizzabili vecchi supporti o impedire l’avvio di determinate configurazioni.

In un altro nostro articolo abbiamo visto come verificare lo stato del PC rispetto alla configurazione dei nuovi certificati per Secure Boot.