{"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\/novosti-interneta\/v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot","title":{"rendered":"In 806 modelli di schede madri \u00e8 stato identificato un codice di test che consente di bypassare UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Gli esperti di sicurezza di Binarly hanno scoperto la possibilit\u00e0 di bypassare la modalit\u00e0 di avvio sicuro UEFI Secure Boot su oltre 800 prodotti rilasciati da Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo e Supermicro. Il problema \u00e8 stato denominato PKfail ed \u00e8 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\u00f9 antichi che utilizzavano questa chiave di test sono stati rilasciati nel 2012, mentre i pi\u00f9 recenti risalgono a giugno 2024. Secondo gli esperti, pi\u00f9 del 10% di tutti i firmware verificati \u00e8 suscettibile a questo problema. <\/p>\n
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. <\/p>\n
La parte riservata della chiave AMI, necessaria per la creazione di firme digitali, \u00e8 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. <\/p>\n
La chiave della piattaforma \u00e8 utilizzata come radice di fiducia per attestare il database delle chiavi per Secure Boot. L'acquisizione della parte privata della chiave della piattaforma compromette l'intera catena di fiducia coinvolta nella verifica dell'autenticit\u00e0 dei componenti del sistema avviabile \u2014 conoscere la chiave della piattaforma consente di bypassare la protezione di Secure Boot e di sostituire i propri componenti durante l'avvio manipolando la chiave KEK (Key Exchange Key) e i database \u00abdb\u00bb (Signature Database) e \u00abdbx\u00bb (Forbidden Signature Database). KEK \u00e8 responsabile della creazione della catena di fiducia tra il firmware e il sistema operativo, \u00abdb\u00bb contiene certificati e firme per il bootloader e i componenti di terze parti UEFI, mentre \u00abdbx\u00bb 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, quindi utilizzare la chiave della piattaforma di test diventata pubblica per caricare nel firmware UEFI il certificato KEK creato. Dopo aver caricato nel firmware il certificato KEK, \u00e8 possibile utilizzare la chiave privata associata per caricare nel database db un nuovo certificato. Una volta caricato il certificato db, la chiave privata associata pu\u00f2 essere utilizzata per attestare i componenti EFI da avviare. 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 \u2014key db.key \u2014cert db.crt \u2014output rogue.efi.signed rogue.efi <\/p>\n
Per verificare la correttezza della chiave della piattaforma, \u00e8 sufficiente eseguire l'utilit\u00e0 \u00abefi-readvar -v PK\u00bb dal pacchetto efitools e assicurarsi che la chiave della piattaforma non sia un test: efi-readvar -v PK Variabile PK, lunghezza 862 PK: Lista 0, tipo X509 Firma 0, dimensione 834, proprietario 26dc4851-195f-4ae1-9a19-fbf883bbb35e Soggetto: CN=DO NOT TRUST \u2014 AMI Test PK Emittente: CN=DO NOT TRUST \u2014 AMI Test PK
![\"Riproduci](\"https:\/\/img.youtube.com\/vi\/CveWt3gFQTE\/hqdefault.jpg\")
\r\n