Badacze bezpieczeństwa z firmy Binarly odkryli możliwość obejścia weryfikowanej procedury rozruchu UEFI Secure Boot w ponad 800 produktach wydanych przez firmy Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo i Supermicro. Problem otrzymał kodową nazwę PKfail i jest związany z używaniem w firmware'ach niezaufanego klucza platformy (PK, Platform Key) wygenerowanego przez AMI (American Megatrends International) i dostarczonego jako wzór testowy. Najstarsze firmware'y, w których użyto klucza testowego, zostały wydane w 2012 roku, a najnowsze datowane są na czerwiec 2024 roku. Według badaczy, problem dotyczy ponad 10% wszystkich sprawdzonych firmware'ów.
W parametrach klucza wskazano, że jest on niezaufany i nie powinien być dostarczany w produktach. Przyjęto, że klucz testowy należy zastąpić własnym, ale producenci zignorowali to ostrzeżenie i użyli w finalnych firmware'ach typowego klucza publicznego, który był przekazywany wszystkim partnerom i klientom AMI.
Zamknięta część klucza testowego AMI, niezbędna do tworzenia podpisów cyfrowych, została ujawniona publicznie po wycieku informacji u jednego z producentów sprzętu, którego pracownik przypadkowo opublikował w publicznym repozytorium na GitHubie kod zawierający ten klucz. Zamknięty klucz został umieszczony w zaszyfrowanym pliku, w którym użyto prostego 4-znakowego hasła, które udało się łatwo zgadnąć metodą prób i błędów.
Klucz platformy jest używany jako korzeń zaufania do poświadczania baz danych z kluczami dla Secure Boot. Uzyskanie zamkniętej części klucza platformy prowadzi do kompromitacji całego łańcucha zaufania, który jest zaangażowany w weryfikację ważności komponentów systemu operacyjnego — znając klucz platformy, można obejść zabezpieczenia Secure Boot i organizować podmianę podczas ładowania własnych komponentów poprzez manipulację kluczem KEK (Key Exchange Key) oraz bazami danych «db» (Signature Database) i «dbx» (Forbidden Signature Database). KEK jest odpowiedzialny za tworzenie łańcucha zaufania między firmware'em a systemem operacyjnym, «db» zawiera certyfikaty i podpisy dla bootloadera i zewnętrznych komponentów UEFI, a «dbx» zawiera unieważnione podpisy znanych złośliwych komponentów.
Aby przeprowadzić atak, wystarczy wygenerować nowe klucze i certyfikaty dla KEK i db, a następnie wykorzystać publicznie dostępny klucz testowy platformy do załadowania do firmware UEFI certyfikatu KEK. Po załadowaniu certyfikatu KEK do firmware można użyć powiązanego z nim klucza prywatnego do załadowania nowego certyfikatu do bazy danych db. Po załadowaniu certyfikatu db powiązany z nim klucz prywatny może być stosowany do podpisywania ładowanych komponentów EFI. 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
Aby sprawdzić poprawność klucza platformy, wystarczy uruchomić narzędzie „efi-readvar -v PK” z pakietu efitools i upewnić się, że klucz platformy nie jest kluczem testowym: efi-readvar -v PK Zmienna PK, długość 862 PK: Lista 0, typ X509 Podpis 0, rozmiar 834, właściciel 26dc4851-195f-4ae1-9a19-fbf883bbb35e Temat: CN=DO NOT TRUST — AMI Test PK Wystawca: CN=DO NOT TRUST — AMI Test PK
Źródło: opennet.ru
