Sigurnosni istraživači iz Binarlyja identificirali su mogućnost zaobilaženja UEFI Secure Boot provjerenog načina pokretanja na više od 800 proizvoda koje proizvode Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo i Supermicro. Problem je kodnog naziva PKfail i povezan je s upotrebom nepouzdanog ključa platforme (PK, Platform Key) u firmveru, koji je generirao AMI (American Megatrends International) i koji je isporučen kao testni primjer. Najstariji firmware koji je koristio testni ključ objavljen je 2012., a najnoviji je iz lipnja 2024. Prema istraživačima, više od 10% svih testiranih firmware-a zahvaćeno je problemom.
Parametri ključa pokazuju da nije pouzdan i da se ne bi trebao nalaziti u njihovim proizvodima. Pretpostavljalo se da bi ovaj testni ključ trebao biti zamijenjen vlastitim, ali proizvođači nisu obratili pozornost na upozorenje i koristili su standardni zajednički ključ u konačnom firmveru, poslan svim AMI partnerima i klijentima.
Privatni dio testnog ključa AMI-ja, neophodan za izradu digitalnih potpisa, postao je javno dostupan nakon curenja informacija od strane jednog od proizvođača opreme, čiji je zaposlenik greškom objavio kod s tim ključem u javnom repozitoriju na GitHubu. Privatni ključ bio je smješten u šifriranu datoteku, koja je bila šifrirana pomoću jednostavne lozinke od 4 znaka, koja se lako pronašla brutalnom silom.
Ključ platforme koristi se kao korijen povjerenja za certificiranje baze podataka s ključevima za sigurno pokretanje. Dobivanje privatnog dijela ključa platforme dovodi do kompromitacije cijelog lanca povjerenja uključenog u provjeru valjanosti komponenti učitanog sustava - poznavajući ključ platforme, možete zaobići Secure Boot zaštitu i organizirati zamjenu prilikom učitavanja vlastitog komponente kroz manipulaciju bazama podataka KEK (Key Exchange Key) i db (Signature Database) i “dbx” (Forbidden Signature Database). KEK je odgovoran za stvaranje lanca povjerenja između firmware-a i operativnog sustava, "db" sadrži certifikate i potpise za bootloader i UEFI komponente trećih strana, a "dbx" uključuje opozvane potpise poznatih zlonamjernih komponenti.
Za izvođenje napada dovoljno je generirati nove ključeve i certifikate za KEK i db, a zatim pomoću javno dostupnog ključa test platforme učitati kreirani KEK certifikat u UEFI firmware. Nakon što ste KEK certifikat učitali u firmware, možete koristiti privatni ključ povezan s njim za učitavanje novog certifikata u db bazu podataka. Nakon što se db certifikat učita, pridruženi privatni ključ može se koristiti za provjeru autentičnosti učitanih EFI komponenti. 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 —ključ db.ključ —cert db.crt —izlaz rogue.efi.signed rogue.efi
Da biste provjerili ispravnost ključa platforme, samo pokrenite uslužni program “efi-readvar -v PK” iz paketa efitools i provjerite da ključ platforme nije testni: efi-readvar -v PK Variable PK, duljina 862 PK : Popis 0, tip X509 Potpis 0, veličina 834, vlasnik 26dc4851-195f-4ae1-9a19-fbf883bbb35e Predmet: CN=NE VJERUJTE — AMI Test PK Izdavatelj: CN=NE VJERUJTE — AMI Test PK
Izvor: opennet.ru
