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