{"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\/da\/blog\/news\/v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot","title":{"rendered":"I 806 modeller af bundkort er der identificeret en testn\u00f8gle, der muligg\u00f8r omg\u00e5else af UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Sikkerhedsforskere fra Binarly har afsl\u00f8ret en mulighed for at omg\u00e5 UEFI Secure Boot's verificerede opstart p\u00e5 mere end 800 produkter fra Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo og Supermicro. Problemet har kodenavnet PKfail og er relateret til brugen af en usikker platformn\u00f8gle (PK, Platform Key), der blev genereret af AMI (American Megatrends International) og leveret som et testeksempel. De \u00e6ldste firmwares, der anvendte testn\u00f8glen, blev udgivet i 2012, mens de nyeste er dateret juni 2024. If\u00f8lge forskerne er over 10% af alle verificerede firmwares s\u00e5rbare over for problemet. <\/p>\n
I n\u00f8gleparametrene blev det angivet, at den ikke var p\u00e5lidelig, og at den ikke skulle leveres i deres produkter. Det var meningen, at denne testn\u00f8gle skulle erstattes med en egen, men producenterne ignorerede advarslen og brugte i de endelige firmwares en generisk f\u00e6llesn\u00f8gle, der blev sendt til alle AMIs partnere og kunder. <\/p>\n
Den lukkede del af AMIs testn\u00f8gle, der var n\u00f8dvendig for at skabe digitale underskrifter, blev offentligt tilg\u00e6ngelig efter en l\u00e6kage fra en hardwareproducent, hvis medarbejder fejlagtigt uploadede kode, der indeholdt denne n\u00f8gle, til et offentligt repository p\u00e5 GitHub. Den lukkede n\u00f8gle blev gemt i en krypteret fil, hvor en simpel 4-tegns adgangskode blev brugt til krypteringen, og denne n\u00f8gle var let at g\u00e6tte ved brute force. <\/p>\n
Platformn\u00f8glen bruges som rod for tillid til at attestere databaser med n\u00f8gler til Secure Boot. At f\u00e5 adgang til den hemmelige del af platformn\u00f8glen kompromitterer hele tillidsk\u00e6den involveret i valideringen af komponenter i det indl\u00e6ste system \u2014 ved at kende platformn\u00f8glen kan man omg\u00e5 beskyttelsen af Secure Boot og organisere indl\u00e6sningen af egne komponenter gennem manipulation af KEK-n\u00f8glen (Key Exchange Key) og databaserne \u00abdb\u00bb (Signature Database) og \u00abdbx\u00bb (Forbidden Signature Database). KEK er ansvarlig for oprettelse af tillid mellem firmware og operativsystem, \u00abdb\u00bb indeholder certifikater og signaturer til indl\u00e6seren og tredjeparts UEFI-komponenter, mens \u00abdbx\u00bb inkluderer tilbagekaldte signaturer af kendte skadelige komponenter. <\/p>\n
For at udf\u00f8re et angreb kr\u00e6ver det blot at generere nye n\u00f8gler og certifikater til KEK og db, hvorefter den offentligt tilg\u00e6ngelige testplatformn\u00f8gle kan bruges til indl\u00e6sning af det oprettede KEK-certifikat i UEFI-firmware. N\u00e5r KEK-certifikatet er indl\u00e6st i firmwaren, kan den tilknyttede hemmelige n\u00f8gle bruges til at indl\u00e6se det nye certifikat i db. Efter indl\u00e6sning af db-certifikatet kan den tilknyttede hemmelige n\u00f8gle anvendes til at attestere de indl\u00e6ste EFI-komponenter. openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj \u00ab\/CN=BRLY KEK\/\u00bb -out KEK.crt openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj \u00ab\/CN=BRLY db\/\u00bb -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
For at kontrollere korrektheden af platformn\u00f8glen er det tilstr\u00e6kkeligt at k\u00f8re v\u00e6rkt\u00f8jet \u00abefi-readvar -v PK\u00bb fra efitools-pakken og sikre sig, at platformn\u00f8glen ikke er en testn\u00f8gle: efi-readvar -v PK Variabel PK, l\u00e6ngde 862 PK: Liste 0, type X509 Signatur 0, st\u00f8rrelse 834, ejer 26dc4851-195f-4ae1-9a19-fbf883bbb35e Emne: CN=DO NOT TRUST \u2014 AMI Test PK Udsteder: CN=DO NOT TRUST \u2014 AMI Test PK
![\"Afspil](\"https:\/\/img.youtube.com\/vi\/CveWt3gFQTE\/hqdefault.jpg\")
\r\n