Una firma valida ha smesso di significare codice sicuro

Secure Boot ha fatto esattamente ciò per cui era stato costruito, e questo era il problema. Il 14 luglio la società di sicurezza ESET ha pubblicato una ricerca, guidata da Martin Smolar, che mostra undici bootloader firmati da Microsoft, tutti alla versione 0.9 o inferiore, che una macchina esegue senza esitazioni perché la firma è autentica. Il codice dietro quella firma ha un decennio ed è difettoso, ma Secure Boot controlla il firmatario, non la sicurezza di ciò che è stato firmato.

Il risultato è un attaccante in grado di eseguire codice non verificato all'avvio su quasi ogni computer UEFI. ESET ha segnalato la scoperta al centro di coordinamento CERT/CC a febbraio, e Microsoft ha aggiunto tutti e undici i file alla propria lista di revoca il 9 giugno. La distanza tra una firma attendibile e un codice affidabile è tutta la storia, e la patch da sola non la colma.

Come funziona l'aggiramento

L'attaccante non forza nulla; fornisce qualcosa di cui già ci si fida. La maggior parte dei sistemi UEFI porta il certificato di terze parti di Microsoft, il Microsoft Corporation UEFI CA 2011, nel proprio elenco di firmatari consentiti. Un attaccante copia uno dei vecchi bootloader firmati sulla partizione di sistema EFI, la piccola area di avvio del disco, e il firmware lo accetta perché la firma risale a quel certificato attendibile. Non servono permessi di amministratore, solo la possibilità di scrivere quel file.

Da lì, tre vecchie falle fanno il lavoro. I bootloader si fidano di codice GRUB 2 obsoleto con un difetto del 2015 che esegue moduli non verificati; le versioni sotto la 0.9 non hanno la lista di revoca che bloccherebbe i certificati noti come dannosi; e quelle precedenti alla 15.3 ignorano SBAT, il meccanismo più recente pensato per ritirare i binari vulnerabili. Registrata come CVE-2026-8863 e CVE-2026-10797, la catena si chiude con il codice dell'attaccante in esecuzione prima del caricamento del sistema operativo, il posto ideale per nascondersi.

Perché la patch è la parte facile

Una revoca protegge solo la macchina che l'ha davvero ricevuta. La correzione di Microsoft del 9 giugno aggiunge gli undici file a dbx, la lista di esclusione del firmware, e sulle flotte Windows gestite quell'aggiornamento viaggia sui canali normali. Il problema è che molte organizzazioni trattengono di proposito le modifiche alla lista del firmware, perché una voce dbx errata può lasciare un dispositivo incapace di avviarsi, e quel rischio è più alto su hardware datato o in dual boot. La revoca esiste; se sia arrivata alle vostre macchine è un'altra questione.

Il problema più profondo è il conteggio. Il registro pubblico di revisione dei bootloader è iniziato solo nel 2017, e non esiste un elenco comparabile di ciò che è stato firmato prima, quindi nessuno può affermare con certezza quanti vecchi bootloader ancora attendibili siano in circolazione. Undici è il numero che ESET ha potuto nominare, non il numero che esiste. Un controllo che dipende dal conoscere ogni firmatario attendibile è debole proprio dove finisce l'inventario.

Cosa verificare davvero questa settimana

Trattatelo come un'attività di igiene delle revoche, non come una singola patch. Verificate che l'aggiornamento dbx del 9 giugno sia stato davvero applicato su tutto il parco invece di darlo per scontato; ESET indica strumenti di audit e controlli PowerShell che riportano lo stato di revoca attuale. Estendete il controllo oltre Windows, perché i server Linux e gli apparati ricevono la stessa correzione tramite il Linux Vendor Firmware Service, e i portatili in dual boot sono il classico punto cieco.

Per gli operatori europei il quadro è ormai tanto normativo quanto tecnico. Con NIS2, l'integrità della catena di avvio rientra nelle misure di sicurezza che un soggetto essenziale deve poter dimostrare, e un bootkit nel firmware è esattamente il tipo di persistenza su cui un'autorità chiederà conto dopo un incidente. L'azione del titolare è facile da enunciare e facile da saltare: verificate di cosa si fida ancora il vostro firmware e dimostrate che il blocco è arrivato.

Da leggere ora: 570 patch Windows in un giorno, due già sfruttate  |  Un bug Cisco di 18 anni ha ora 3 giorni di tempo