{"id":118325,"date":"2024-07-26T15:43:00","date_gmt":"2024-07-26T13:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot"},"modified":"2024-07-26T15:43:00","modified_gmt":"2024-07-26T13:43:00","slug":"v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot","title":{"rendered":"In 806 modelli di schede madri \u00e8 stato trovato una chiave di test che consente di aggirare UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
I ricercatori di sicurezza della societ\u00e0 Binarly hanno identificato la possibilit\u00e0 di bypassare la modalit\u00e0 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 \u00e8 legato all'uso di una chiave di piattaforma non attendibile (PK, Platform Key) nelle versioni del firmware, generata dalla societ\u00e0 AMI (American Megatrends International) e fornita come campione di prova. Le versioni del firmware pi\u00f9 vecchie che utilizzavano la chiave di test sono state rilasciate nel 2012, mentre le pi\u00f9 recenti risalgono a giugno 2024. Secondo i ricercatori, oltre il 10% di tutti i firmware verificati \u00e8 vulnerabile a questo problema. <\/p>\n
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. <\/p>\n
La parte riservata della chiave di test di AMI, necessaria per creare firme digitali, \u00e8 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 \u00e8 stata pubblicata in un file crittografato, nella cui crittografia \u00e8 stata utilizzata una semplice password di 4 caratteri, facilmente reperibile tramite attacco di forza bruta. <\/p>\n
La chiave della piattaforma viene utilizzata come radice di fiducia per la verifica delle database chiave per il Secure Boot. L'ottenimento della parte privata della chiave della piattaforma compromette l'intera catena di fiducia coinvolta nella validazione dei componenti del sistema avviato: conoscendo la chiave della piattaforma, \u00e8 possibile eludere la protezione del Secure Boot e organizzare la sostituzione durante l'avvio dei propri componenti tramite la manipolazione della chiave KEK (Key Exchange Key) e delle database \"db\" (Signature Database) e \"dbx\" (Forbidden Signature Database). La KEK \u00e8 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 le firme revocate di noti componenti dannosi. <\/p>\n
Per eseguire un attacco, \u00e8 sufficiente generare nuove chiavi e certificati per KEK e db, dopodich\u00e9 utilizzare la chiave della piattaforma di test resa pubblica per caricare il certificato KEK creato nel firmware UEFI. Dopo aver caricato il certificato KEK nel firmware, \u00e8 possibile utilizzare la chiave privata ad esso associata per caricare un nuovo certificato nel database db. Dopo il caricamento del certificato db, la chiave privata ad esso associata pu\u00f2 essere utilizzata per la verifica dei 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 <\/p>\n
Per verificare la correttezza della chiave della piattaforma, \u00e8 sufficiente eseguire l'utilit\u00e0 \"efi-readvar -v PK\" dal pacchetto efitools e assicurarsi che la chiave della piattaforma non sia quella di 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 \u2014 AMI Test PK Emittente: CN=NON FIDARTI \u2014 AMI Test PK
![\"Guarda](\"https:\/\/img.youtube.com\/vi\/CveWt3gFQTE\/hqdefault.jpg\")
\r\n