themalwareguardian/cve-2022-34303Демонстрирует обход Secure Boot через CVE-2022-34303 с использованием подписанной CryptoPro UEFI Shell, применяя команду mm для обнуления gSecurity2 и загрузки неподписанных UEFI-приложений.
CryptoPro Secure Disk UEFI Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - обход Secure Boot через подписанный UEFI Shell и повреждение gSecurity2.
Этот репозиторий демонстрирует технику BYOVUA (Bring Your Own Vulnerable UEFI Application) путём эксплуатации CVE-2022-34303 - уязвимости обхода Secure Boot в среде загрузки CryptoPro Secure Disk UEFI.
В данном случае компонентом, которому доверяет Secure Boot, является кастомный shim, подписанный Microsoft UEFI Third Party Certificate Authority. После запуска этот shim загружает UEFI Shell в качестве второй стадии, что открывает доступ к команде mm (memory modify) и, следовательно, предоставляет возможности произвольного чтения и записи памяти на этапе загрузки до запуска ОС.
Этот примитив затем может быть использован для поиска и обнуления глобального указателя gSecurity2 в ядре DXE. В результате последующая проверка UEFI-образов отключается, что позволяет загружать неподписанные UEFI-приложения, буткиты, несмотря на включённый Secure Boot.
BYOVUA - это UEFI-эквивалент техники BYOVD (Bring Your Own Vulnerable Driver), используемой на уровне ядра. Вместо того чтобы принести подписанный драйвер ядра с уязвимостью, атакующий приносит подписанное UEFI-приложение - в данном случае полноценный UEFI Shell - содержащее функциональность, способную подорвать Secure Boot.
Поскольку приложение - в данном случае кастомный shim, который загружает UEFI Shell в качестве второй стадии - подписано сертификатом, которому доверяет Microsoft, оно принимается Secure Boot без вопросов, что делает его доверенным на любой системе, включающей этот сертификат в свою базу данных Secure Boot (db) - то есть практически на любом UEFI-совместимом ПК, выпущенном за последнее десятилетие. После запуска его встроенные команды предоставляют атакующему прямой доступ к оборудованию и памяти, работающий до загрузки операционной системы, в среде, где современные средства защиты (ASLR, DEP, защиты ядра) попросту отсутствуют.
Shell_Full.efi - это UEFI Shell, распространяемый в составе CryptoPro Secure Disk, продукта для предзагрузочной аутентификации и шифрования диска.
| Свойство | Значение |
|---|---|
| Файл | Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell) |
| Производитель | CryptoPro Secure Disk |
| CVE | CVE-2022-34303 |
| Подпись | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Обнаружение | Eclypsium (Mickey Shkatov, Jesse Michael) - август 2022 |
| Презентация | DEF CON 30 - "One Bootloader to Load Them All" |
| Отзыв | Добавлено в DBX через Microsoft KB5012170 (август 2022) |
Уязвимость - это не баг, а ошибка проектирования. UEFI Shell - это легитимные диагностические инструменты, которые никогда не предназначались для работы в средах Secure Boot. Однако, подписывая их сертификатом, которому доверяет Microsoft, и распространяя их в составе коммерческих продуктов, производители непреднамеренно создали подписанный обход Secure Boot.
Основная проблема: подписанный бинарник, которому доверяет Secure Boot, предоставляет неограниченные возможности чтения/записи памяти через свои встроенные команды. Это сочетание разрушает всю модель доверия Secure Boot.
Команда mm (memory modify) - это стандартная встроенная команда UEFI Shell, обеспечивающая прямой доступ на чтение и запись к системной памяти. Она описана в UEFI Shell Specification (раздел 5.3).```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Параметр | Описание |
|-----------|-------------|
| `Address` | Целевой адрес памяти |
| `Value` | Значение для записи (опустите для режима только чтения) |
| `-w` | Ширина: 1, 2, 4 или 8 байт |
| `-MEM` | Доступ к системной памяти |
| `-MMIO` | Отображённый в память ввод-вывод (MMIO) |
| `-IO` | Доступ к портам ввода-вывода |
| `-n` | Неинтерактивный режим (без запроса следующего адреса) |
---
<div id='gsecurity2'/>
### ***gSecurity2 и архитектурный протокол безопасности***
Проверка образов Secure Boot в UEFI обеспечивается через [архитектурные протоколы безопасности](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols), определённые в спецификации UEFI Platform Initialization (PI).
Ядро DXE (DxeMain) поддерживает глобальный указатель [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), который указывает на структуру `EFI_SECURITY2_ARCH_PROTOCOL`. Этот протокол содержит единственный указатель на функцию — `FileAuthenticationState` — которая вызывается `LoadImage()` каждый раз при загрузке образа UEFI:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
При вызове LoadImage() ядро DXE проверяет:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
Установив `gSecurity2 = NULL`, проверка `if` завершается неудачей, и `FileAuthenticationState` никогда не вызывается. Проверка образа полностью пропускается — **Secure Boot остаётся «включённым», но больше не применяется**. Неподписанные UEFI-приложения после этого могут загружаться свободно.
Для глубокого технического понимания этой техники, включая специально созданное UEFI-приложение, которое автоматически находит и патчит gSecurity2, см. сопутствующий проект: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---
<div id='BYOVD'/>
### ***Параллель с ядерным BYOVD***