I ricercatori di sicurezza della società Binarly hanno identificato la possibilità di bypassare la modalità di verifica dell'avvio sicuro UEFI Secure Boot su oltre 800 prodotti rilasciati da aziende come Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo e Supermicro. Il problema ha ricevuto il nome in codice PKfail ed è legato all'uso di una chiave di piattaforma non attendibile (PK, Platform Key) nelle versioni del firmware, generata dalla società AMI (American Megatrends International) e fornita come campione di prova. Le versioni del firmware più vecchie che utilizzavano la chiave di test sono state rilasciate nel 2012, mentre le più recenti risalgono a giugno 2024. Secondo i ricercatori, oltre il 10% di tutti i firmware verificati è vulnerabile a questo problema.
Nelle impostazioni della chiave era specificato che essa non era attendibile e non doveva essere fornita nei propri prodotti. Era previsto che questa chiave di test fosse sostituita con una propria, ma i produttori non hanno prestato attenzione all'avviso e hanno utilizzato nel firmware finale una chiave comune generica inviata a tutti i partner e clienti di AMI.
La parte riservata della chiave di test di AMI, necessaria per creare firme digitali, è diventata pubblica dopo una fuga di informazioni da uno dei produttori di hardware, il cui dipendente ha erroneamente pubblicato in un repository pubblico su GitHub del codice contenente questa chiave. La chiave privata è stata pubblicata in un file crittografato, nella cui crittografia è stata utilizzata una semplice password di 4 caratteri, facilmente reperibile tramite attacco di forza bruta.
La chiave di piattaforma è utilizzata come radice di fiducia per la convalida del database delle chiavi per Secure Boot. L'accesso alla parte privata della chiave di piattaforma compromette l'intera catena di fiducia coinvolta nel controllo della validità dei componenti del sistema avviabile: conoscendo la chiave di piattaforma è possibile bypassare la protezione di Secure Boot e organizzare il caricamento di propri componenti mediante la manomissione 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 bootloader e componenti di terze parti UEFI, mentre 'dbx' include le firme revocate di noti componenti dannosi.
Per eseguire un attacco, è sufficiente generare nuove chiavi e certificati per KEK e db, dopo di che utilizzare la chiave di test della piattaforma accessibile pubblicamente per caricare nel firmware UEFI il certificato KEK creato. Caricando nel firmware il certificato KEK, è possibile utilizzare la chiave privata associata per caricare nel database db un nuovo certificato. Dopo il caricamento del 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 l'utility "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
