Специалисти по сигурността от компанията Binarly откриха възможност за заобикаляне на режима на верифицирано зареждане UEFI Secure Boot на повече от 800 продукта, произведени от компаниите Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo и Supermicro. Проблемът получи кодово име PKfail и е свързан с използването на ненадежден ключ на платформата (PK, Platform Key), генериран от AMI (American Megatrends International) и предоставен като тестов образец. Най-старите фърмуери, в които е използван тестовия ключ, са пуснати през 2012 г., а най-новите са от юни 2024 г. Според изследователите, проблемът засяга повече от 10% от всички проверени фърмуери.
В параметрите на ключа е посочено, че той не е надежден и не трябва да се предоставя в техните продукти. Предполагало се е, че този тестов ключ следва да бъде заменен с собствен, но производителите не обърнали внимание на предупреждението и използвали в окончателните фърмуери типичен общ ключ, изпращан на всички партньори и клиенти на AMI.
Частта от тестовия ключ на AMI, необходима за създаването на цифрови подписи, стана публично достъпна след изтичане на информация от един от производителите на оборудване, служител на който по погрешка е публикувал в публично хранилище на GitHub код, съдържащ този ключ. Закритият ключ е публикуван в криптиран файл, при криптирането на който е използван прост 4-символен парол, който е бил лесно подбран чрез метода на опити.
Ключът на платформата се използва като корен на доверието за удостоверяване на базата данни с ключове за Secure Boot. Получаването на закритата част на ключа на платформата води до компрометиране на цялата верига на доверието, участвала в проверката на валидността на компонентите на зарежданата система — познавайки ключа на платформата, може да се заобиколи защитата на Secure Boot и да се осъществи подмяна при зареждане на собствени компоненти чрез манипулация на ключа KEK (Key Exchange Key) и базите данни „db“ (Signature Database) и „dbx“ (Forbidden Signature Database). KEK отговаря за създаването на верига на доверието между фърмуера и операционната система, „db“ съдържа сертификати и подписи за загрузчика и външни компоненти на UEFI, а „dbx“ включва отозвани подписи на известни злонамерени компоненти.
За да се извърши атака, е достатъчно да се генерират нови ключове и сертификати за KEK и db, след което да се използва публично достъпният тестов ключ на платформата за зареждане в UEFI фърмуера на създадения KEK сертификат. След зареждане на KEK сертификат във фърмуера, може да се използва свързаният с него частен ключ за зареждане в БД db на новия сертификат. След зареждане на сертификата db, свързаният с него частен ключ може да се използва за заверяване на заредените 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
За да проверите коректността на ключа на платформата, е достатъчно да стартирате утилитата "efi-readvar -v PK" от пакета efitools и да се уверите, че ключът на платформата не е тестов: efi-readvar -v PK Променлива PK, дължина 862 PK: Списък 0, тип X509 Подпис 0, размер 834, собственик 26dc4851-195f-4ae1-9a19-fbf883bbb35e Съобщение: CN=DO NOT TRUST — AMI Test PK Издател: CN=DO NOT TRUST — AMI Test PK
Източник: opennet.ru
