PKfail è la vergognosa vulnerabilità di Secure Boot che compromette milioni di dispositivi

PKfail è la vergognosa vulnerabilità di Secure Boot che compromette milioni di dispositivi

Il sistema di protezione del BIOS/UEFI che evita l'esecuzione di codice non affidabile è completamente aggirabile su oltre 900 modelli di dispositivi, per via di una gestione oscena delle chiavi crittografiche

di pubblicata il , alle 14:07 nel canale Sicurezza
 

La società di sicurezza Binarly ha rivelato che Secure Boot, il meccanismo di sicurezza per prevenire l'esecuzione di codice non attendibile durante l'avvio di sistema, non può essere più ritenuto affidabile su oltre 200 modelli di dispositivi venduti, tra gli altri, da Acer, Dell, Gigabyte, Intel e Supermicro a causa di una chiave crittografica alla base del meccanismo che è stata compromessa nel 2022.

Un piccolo passo indietro: Secure Boot è una soluzione adottata nel 2012 da una coalizione di produttori hardware e software per la protezione da una particolare minaccia alla sicurezza dei sistemi, ovvero forme di malware in grado di colpire il BIOS. Dal momento che quest'ultimo è responsabile dell'avvio e del caricamento del sistema operativo, un eventuale malware a livello BIOS avrebbe la possibilità di passare inosservato al rilevamento e alla rimozione, potendo caricarsi prima dell'avvio del sistema operativo stesso e delle suite di sicurezza, mantenendo quindi persistenza e risultando estremamente difficile da debellare.

Secure Boot, la protezione del BIOS/UEFI da rootkit

I malware in grado di aggredire il BIOS erano stati dimostrati nel 2007 con un proof-of-concept da parte di un ricercatore cinese, ma solo nel 2011 la minaccia è divenuta concreta con la scoperta di Mebromi, il primo rootkit BIOS noto per essere stato utilizzato, come si dice in questi casi, "in the wild". La comparsa di Mebromi ha spinto il settore a cercare una soluzione, concretizzatasi in seguito in Secure Boot e integrata direttamente in UEFI, il successore del BIOS. Si tratta di un meccanismo basato sulla crittografia a chiave pubblica pensato per bloccare il caricamento di qualsiasi codice che non fosse firmato con una firma digitale approvata in precedenza. Secure Boot è considerato ancor oggi dai principali attori nel panorama della sicurezza (tra cui realtà come Microsoft e la National Security Agency statunitense), come un tassello fondamentale per la protezione dei dispositivi in quegli ambienti critici come possono essere le reti aziendali e i sistemi di controllo industriale.

Sono quattro gli elementi chiave del funzionamento di Secure Boot:

  1. Platform Key (PK): fornisce l'ancoraggio root-of-trust in forma di chiave crittografica incorporata nel firmware di sistema, stabilendo di fatto la fiducia tra l'hardware e il firmware che viene eseguito su di essa
  2. Key Exchange Key (KEK): stabilisce la fiducia tra il sistema operativo e il firmware della piattaforma
  3. Signature Database (DB): contiene firme e certificati attendibili per componenti UEFI di terze parti e boot loader approvati dal produttore dell'hardware
  4. Forbidden Signature Database (DBX): contiene firme e certificati per revocare componenti di avvio precedentemente ritenuti attendibili, in modo che non possano più essere eseguiti durante l'avvio.

Come accennato in apertura, il problema rilevato dai ricercatori di Binarly riguarda una chiave crittografica alla base di Secure Boot che è stata compromessa nel corso del 2022: nel mese di dicembre di quell'anno è stata pubblicata in un repository GitHub la chiave di piattaforma (PK) relativa ai dispositivi dei vendor sopra citati. Non è chiaro chi e perché abbia fatto ciò, e non è chiaro nemmeno in quale momento il repository è stato rimosso. Al suo interno comunque era presente un file crittografato protetto da password, contenente appunto la parte privata della PK. La password è risultata essere però di soli quattro caratteri, rendendo spaventosamente semplice per chiunque trovare un modo per decifrarla e recuperare il contenuto del file. Il fatto che la chiave fosse divenuta di pubblico dominio è passato relativamente inosservato fino a gennaio 2023, quando è stata casualmente trovata dai ricercatori di Binarly durante le indagini seguite ad un incidente di sicurezza.

Una scansione condotta dai ricercatori ha rilevato che vi sono 215 modelli di dispositivi che utilizzano la chiave compromessa. Ma tutto ciò è solamente la punta di un iceberg, in quanto le analisi di Binarly hanno l'esistenza di altre 21 PK utilizzate e condivise da ulteriori centinaia di modelli di dispositivi prodotti da altre realtà come Fujitsu, HP, Lenovo, MSI, Gigabyte, solo per citarne alcune. In totale si contano oltre 900 modelli di dispositivi interessati, che corrispondono a milioni di sistemi in circolazione. Un elenco, ancora probabilmente non completo, si trova su Github: da una rapida occhiata si possono notare sistemi server, portatili, schede madri, desktop all-in-one...insomma, c'è davvero di tutto.

PKfail: Secure Boot aggirabile a causa di una pessima gestione delle chiavi crittografiche

Le chiavi sono state create in origine da AMI, uno dei tre principali fornitori di kit per sviluppo che i produttori di dispositivi usano per la personalizzazione del firmare UEFI, così che possa funzionare sulle loro specifiche configurazioni hardware. Si tratta di chiavi che contengono stringhe come "DO NOT SHIP" o "DO NOT TRUST", che indicano chiaramente come non fossero state originariamente create per l'uso nei sistemi di produzione. AMI però le ha fornite a clienti e partner per operazioni di test e, per ragioni al momento non chiare (forse solo semplice pigrizia?) le chiavi sono state inserite nei dispositivi da parte di moltissimi produttori, non solo quelli citati più sopra.

E' chiaro che quanto accaduto rappresenta la negazione più totale di quelle che dovrebbero essere le "best practice" per la gestione delle chiavi crittografiche di Secure Boot, che dovrebbero essere univoche per ogni linea di prodotto, o almeno per ogni produttore, e che dovrebbero essere ruotate con cadenza periodica. Quanto scoperto da Binarly, invece, sono chiavi condivise per oltre dieci anni tra numerosi produttori e tra i loro dispositivi: il primo firmware vulnerabile risulta infatti risalire a maggio 2012, mentre l'ultimo è stato rilasciato a giugno 2024. Insomma, si tratta di chiavi che sono un vero e proprio "segreto di Pulcinella". Non è un caso che Binarly abbia dato al problema il nome di "PKfail", a rimarcare la vergognosa gestione delle chiavi crittografiche.

Un efficace parallelismo che aiuta a comprendere la situazione è stato elaborato dal fondatore e CEO di Binarly, Alex Matrosov: "Immaginate che tutte le persone in un condominio abbiano la stessa serratura e chiave della porta d'ingresso. Se qualcuno perde la chiave, potrebbe essere un problema per l'intero edificio. Ma cosa succederebbe se le cose andassero anche peggio e altri edifici avessero la stessa serratura e le stesse chiavi?". E' esattamente quello che è successo: Binarly ha individuato chiavi identiche sia su prodotti client che su prodotti server, e almeno una delle chiavi compromesse è stata utilizzata in dispositivi commercializzati da tre diversi produttori.

La conoscenza della parte privata di una PK, assieme ai permessi di amministratore, può consentire quindi di aggirare completamente le protezioni Secure Boot sui dispositivi dove è stata utilizzata una delle chiavi "non più segrete". La possibilità di aggirare Secure Boot significa la possibilità, per un attaccante, di eseguire malware o, in genere, qualsiai tipo di codice non attendibile durante l'avvio del sistema, sui dispositivi interessati dal problema. Come detto è necessario disporre dei permessi di amministratore, ma sapere come recuperarli è probabilmente l'"A-B-C" per qualsiasi criminale informatico con un poco di esperienza.

Per risolvere il problema sono necessarie due azioni. La prima, da parte dei produttori, è quella di sostituire le chiavi crittografiche compromesse con nuove chiavi generate in modo sicuro. La seconda, da parte di utenti e amministratori di sistema e che dipende dalla precedente, è quella di aggiornare i firmware e applicare le patch di sicurezza che risolvono la vulnerabilità PKfail. Binarly ha condiviso alcuni strumenti che consentono di verificare quali sistemi possano essere vulnerabili: li trovate al sito https://pk.fail.

11 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
sbaffo26 Luglio 2024, 14:21 #1
Più sono "secure" o "trusted" meno lo sono in realtà.
Certo che cascano le @@, la sicurezza informatica mondiale è in mano ad una manica di cialtroni.
Il problema che non è solo uno e due, ma tutti la catena coinvolta, praticamente metà o più dei maggiori produttori.

Sarà colpa della Ue anche qui?
marcram26 Luglio 2024, 16:34 #2
Il Bios/Uefi è una di quelle str****te di software chiusi, che ti installano una volta e te li tieni così fino alla morte del dispositivo, con mancanze, falle, difetti mai corretti.
E il problema è sempre quello: la gente se ne frega di ciò, gli va bene lo stesso, e quelli a cui interessa invece si attaccano, perché tanto i grossi produttori vendono lo stesso, anche senza di loro...

E' per questo che, eventi come quello di Crowdstrike, fanno solo che bene alla società, e mettono in luce mancanze invisibili ai più...
blackshard26 Luglio 2024, 17:05 #3
Originariamente inviato da: marcram
Il Bios/Uefi è una di quelle str****te di software chiusi, che ti installano una volta e te li tieni così fino alla morte del dispositivo, con mancanze, falle, difetti mai corretti.
E il problema è sempre quello: la gente se ne frega di ciò, gli va bene lo stesso, e quelli a cui interessa invece si attaccano, perché tanto i grossi produttori vendono lo stesso, anche senza di loro...

E' per questo che, eventi come quello di Crowdstrike, fanno solo che bene alla società, e mettono in luce mancanze invisibili ai più...


Direi che bene o male sono d'accordo. Secure boot poi è una bella balla inventata da Microsoft che, per togliere di mezzo i loader che piratavano i loro software, ha tirato fuori dal cilindro questa bella sozzata.
io78bis26 Luglio 2024, 18:03 #4
Originariamente inviato da: marcram
Il ..


Originariamente inviato da: blackshard
Direi che bene o male sono d'accordo. Secure boot poi è una bella balla inventata da Microsoft che, per togliere di mezzo i loader che piratavano i loro software, ha tirato fuori dal cilindro questa bella sozzata.


Qui non si tratta di una progettazione o architettura errata ma di superficialità nel rispettare una delle regole base di sicurezza informatica.
marcram26 Luglio 2024, 18:29 #5
Originariamente inviato da: io78bis
Qui non si tratta di una progettazione o architettura errata ma di superficialità nel rispettare una delle regole base di sicurezza informatica.

Che si risolverebbe in un attimo con l'aggiornamento del Bios e la rimozione della chiave tra quelle fidate.
MA, essendo il Bios un software distribuito esclusivamente dal produttore dell'hardware, bisogna aspettare un gesto benevolo dallo stesso.
Quindi sì, è un problema di architettura mal concepita.
Opteranium26 Luglio 2024, 18:56 #6
insomma, ci siamo dati un gran da fare negli ultimi 15 anni per far mettere a tutti la porta blindata in casa (secure boot) salvo poi scoprire che la chiave è la stessa per tutte le porte e liberamente copiabile dal ferramenta
destroyer8527 Luglio 2024, 15:52 #7
È una vulnerabilità piuttosto grave, ma credo che basterà modificare il registro delle chiavi revocate come successe per la vulnerabilità BootHole di Grub.
https://uefi.org/revocationlistfile
Lo riscrivo perché magari vi è sfuggito, prima di UEFI non c'erano problemi di sicurezza perchè il BIOS non aveva nessuna sicurezza. Chiunque con i privilegi di amministratore poteva sostituire il bootloader con un rootkit e nessuno si accorgeva di niente.
Grazie a questa vulnerabilità uno (sempre con i privilegi di amministratore) potrebbe firmare il bootloader, o addirittura un nuovo BIOS credo, con le chiavi "sfuggite" e nessuno si accorgerebbe di niente.
Gringo [ITF]27 Luglio 2024, 19:22 #8
Chiunque con i privilegi di amministratore poteva sostituire il bootloader con un rootkit e nessuno si accorgeva di niente.

Si ma prima l'utente con diritti di aministrazione, (IL PC ME LO SONO PAGATO, E I MIEI SOLDI NON HANNO DRM, CHE TI OBBLIGA A SPENDERLI DA ME) poteva anche riflesharsi autonomamente il bios e risistemarsi tutto da solo se ne aveva le capacità, ora per farlo bisogna avere le dritte giuste che però i malintenzionati hanno sicuramente prima di te.
massi4791127 Luglio 2024, 22:50 #9
Originariamente inviato da: Gringo [ITF]
Si ma prima l'utente con diritti di aministrazione, (IL PC ME LO SONO PAGATO, E I MIEI SOLDI NON HANNO DRM, CHE TI OBBLIGA A SPENDERLI DA ME) poteva anche riflesharsi autonomamente il bios e risistemarsi tutto da solo se ne aveva le capacità, ora per farlo bisogna avere le dritte giuste che però i malintenzionati hanno sicuramente prima di te.


Accorgersi del malware e riflesharsi autonomamente il BIOS? Ma tu stai ragionando con la mentalità dell'1% della popolazione, mentre i dispositivi devono essere pensati per il 99% delle persone. I computer sono mezzi, mica dobbiamo vivere per loro.
Come per le auto: certo, c'è quello che passa i weekend a sistemarsi l'auto in garage come passione, ma per il 99% è un mezzo che deve semplificare la vita, mica complicarla.
Anche io quando avevo 20 anni perdevo molto tempo sui PC, overclocking ecc. adesso che sono sposato con due figlie, a malapena ho tempo per entrare saltuariamente sui siti di news di informatica, quindi voglio un prodotto pronto e sicuro (e gestito bene, come dovrebbe essere secure boot ma la cialtroneria non ha limiti).
destroyer8528 Luglio 2024, 13:32 #10
Un'altra cosa non di poco conto, possibile che in AMI non se ne siano mai accorti? In 10 anni nessuno ha mai mandato un'immagine ad AMI per chiedergli "va bene fatto così il firmware o c'è qualche errore?"

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^