На Red Team-проекте в прошлом году звучала такая задача: доказать persistence ниже уровня ОС на хосте с Windows 11 и включённым Secure Boot. SYSTEM получили через Kerberoasting, до рабочей станции добрались lateral movement'ом. Попытка подложить модифицированный загрузчик в EFI System Partition закончилась предсказуемо - Secure Boot отклонил неподписанный бинарь при перезагрузке. Тут возникает вопрос: отключить ли Secure Boot через BIOS? Можно, но оставляет следы в журнале прошивки - для Red Team это провал по OPSEC. Задача была другая: обойти верификацию загрузчика, сохранив видимость штатной работы. Ниже - три техники обхода Secure Boot, которые реально работают на пентесте, с конкретным attack path и разбором CVE-2024-7344.
Цепочка доверия загрузки и точки отказа
Secure Boot верифицирует каждое звено: прошивка UEFI проверяет загрузчик ОС, загрузчик ОС проверяет драйверы ядра. При включении UEFI Boot Manager сверяет загрузочное приложение -bootmgfw.efi для Windows, shimx64.efi или grubx64.efi для GNU\Linux - по двум базам данных:- db (Signature Database) - список доверенных сертификатов и PE Authenticode-хешей
- dbx (Forbidden Signatures Database) - чёрный список отозванных хешей и сертификатов
- Microsoft Windows Production PCA 2011 - подпись собственных загрузчиков Windows
- Microsoft Corporation UEFI CA 2011 - подпись стороннего ПО (Linux shim-загрузчики, утилиты восстановления, disk encryption)
Место обхода Secure Boot в kill chain
Атаки на UEFI-загрузчик - не initial access и не privilege escalation. По MITRE ATT&CK это Bootkit (T1542.003) и System Firmware (T1542.001) - persistence и stealth на финальных этапах цепочки.Что должно произойти до обхода Secure Boot:
- Initial access - первоначальное проникновение в сеть
- Privilege escalation - повышение до local admin (Windows) или root (GNU\Linux)
- Доступ к ESP - монтирование EFI System Partition (
mountvol S: /sна Windows, стандартныйmountна GNU\Linux)
- Код исполняется до старта ОС, до инициализации любого EDR-агента
- Persistence переживает полную переустановку ОС
- Kernel-level контроль с момента передачи управления ядру - можно загрузить C2-beacon до старта CrowdStrike Falcon, SentinelOne, Elastic EDR или Kaspersky EDR Expert
- Копирование файлов в ESP не оставляет логов в стандартных Windows Event Logs - для FAT32-раздела ESP нет аналога Sysmon FileCreate (вот это - настоящая слепая зона)
Техники обхода Secure Boot: выбор вектора
Выбор техники зависит от уровня доступа, целевой ОС и наличия Measured Boot с TPM attestation.
| Условие | Техника | Привилегии | Физ. доступ | Устойчивость к dbx-обновлению |
|---|---|---|---|---|
| Admin/root, ОС загружена | Подписанный уязвимый загрузчик (BYOVB) | Требуются | Нет | Нет - после ревокации бинарь блокируется |
| Root + GNU\Linux с shim | Подмена MOK-ключей | Требуются | Частично (подтверждение при перезагрузке) | Да - собственные ключи не в dbx |
| Физический доступ к плате | Модификация SPI-флеш | Не требуются | Да | Да - при отсутствии firmware write protection |
CVE-2024-7344: обход подписи загрузчика через уязвимый бинарь
Самая практичная техника обхода Secure Boot для пентестера с удалённым доступом и правами admin/root. Суть подхода «bring your own vulnerable bootloader» (BYOVB): атакующий доставляет на целевую систему легитимный, подписанный Microsoft UEFI-бинарь с известной уязвимостью и через неё исполняет неподписанный код. Через такой вектор можно развернуть полноценные UEFI-буткиты - BlackLotus или Bootkitty - даже при включённом Secure Boot.CVE-2024-7344, обнаруженная исследователем ESET Martin Smolár, затрагивает UEFI-приложение Reloader - компонент нескольких утилит восстановления: Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery, Sanfong EZ-back System, CES NeoImpact. По данным ESET, также затронуты WASAY eRecoveryRX и SignalComputer HDD King.
Оценка - CVSS 8.2 (HIGH), вектор CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H. Разберём что тут важно:
Работает если: целевая система использует Microsoft third-party UEFI-сертификат (большинство устройств) и dbx не содержит хеш уязвимого reloader.efi. Не работает если: Windows 11 Secured-core PC - на них доверие к third-party UEFI-сертификату отключено по умолчанию; системы с актуальными UEFI-ревокациями после января 2025.
Ограничение по времени: 14 января 2025 года Microsoft отозвала уязвимые бинари через обновление dbx в рамках Patch Tuesday. EPSS-оценка - 0.004 (0.4%), percentile 0.61: вероятность массовой эксплуатации невысока, но для таргетированных атак на системы с устаревшим dbx вектор рабочий. На пентесте первым шагом после fingerprinting будет проверка актуальности dbx на целевом хосте.
Атака через shim-загрузчик и MOK-ключи
На GNU\Linux-системах с shim-загрузчиком (Ubuntu, Fedora, RHEL) есть дополнительный уровень управления ключами - Machine Owner Key (MOK). Shim - подписанный Microsoft промежуточный загрузчик, который доверяет как стандартным ключам из db, так и собственным MOK-ключам владельца.Атакующий с правами root регистрирует собственный MOK-ключ через
mokutil --import custom_key.der, затем подписывает произвольный загрузчик утилитой sbsign. При следующей перезагрузке shim-менеджер запросит интерактивное подтверждение регистрации - это единственный шаг, требующий присутствия у экрана или KVM/IPMI-доступа.Работает если: root-привилегии на GNU\Linux с shim, возможность инициировать перезагрузку и пройти интерактивное подтверждение. Не работает если: нет интерактивного доступа при перезагрузке; инфраструктура с централизованным управлением MOK-набором.
Контекст применимости: внутренний пентест с KVM-доступом к GNU\Linux-серверам. На внешнем пентесте неприменима из-за интерактивного шага. Преимущество перед BYOVB: собственные MOK-ключи не попадают в dbx-обновления Microsoft - техника не протухает со временем.
Модификация SPI-флеш при физическом доступе
Для Red Team-сценария с физическим доступом к устройству (серверная, рабочая станция в офисе) обход Secure Boot возможен на уровне прошивки. SPI-флеш - микросхема на материнской плате, хранящая весь UEFI-образ, включая db/dbx и настройки Secure Boot.Через программатор CH341A (стоит около 500 рублей на маркетплейсах) и утилиту
flashrom можно считать полный дамп SPI-флеш, модифицировать переменные db/dbx - добавив свой ключ в доверенные или удалив dbx - и записать изменённый образ обратно.Работает если: legacy-серверы без Intel Boot Guard и AMD PSB; промышленное оборудование с UEFI без TPM; системы без аппаратной защиты SPI-записи. Не работает если: Intel с Boot Guard или AMD с Platform Secure Boot - аппаратная верификация Initial Boot Block отклонит модифицированный образ и устройство не загрузится.
Самый радикальный и рискованный метод: ошибка при записи может превратить устройство в кирпич. Я применяю его только на тестовых стендах или когда заказчик явно согласовал физический вектор и понимает последствия.
Разведка UEFI-конфигурации перед атакой
Fingerprinting UEFI-конфигурации определяет выбор техники: включён ли Secure Boot, какие сертификаты в db, актуален ли dbx, защищена ли SPI-запись.Требования к окружению
- ОС: GNU\Linux (полная поддержка Chipsec) или Windows (ограниченная, требует TestSigning mode)
- RAM: минимум 4 ГБ
- Инструменты: Chipsec (GitHub: chipsec/chipsec, активный проект), UEFITool (GitHub: LongSoft/UEFITool), efibootmgr
- Привилегии: root (GNU\Linux) или admin + TestSigning (Windows)
- Среда: тестовый стенд. Chipsec загружает драйвер ядра с прямым доступом к аппаратным ресурсам - на production-системе это риск зависания или повреждения
Bash:
# Анализ переменных Secure Boot: SecureBoot, SetupMode, db, dbx
sudo python3 chipsec_main.py -m common.secureboot.variables
# Результаты [FAIL] = потенциально эксплуатируемая конфигурация
# Проверка защиты записи SPI-флеш
sudo python3 chipsec_main.py -m common.bios_wpSecureBoot), режим работы (SetupMode, AuditMode), состояние db/dbx/KEK. Модуль common.bios_wp отвечает на вопрос про физическую атаку: [PASS] - запись SPI заблокирована аппаратно, [FAIL] - SPI-флеш открыта для модификации.Дамп образа прошивки и поиск уязвимых бинарей:
Bash:
# Дамп SPI-флеш в файл для офлайн-анализа
sudo python3 chipsec_util.py spi dump bios_dump.bin
# Результат: bios_dump.bin - полная копия прошивки
# Защищённые регионы заполняются 0xFFbios_dump.bin открывается в UEFITool - он разбирает образ на дерево UEFI-файлов. Искать стоит подписанные сторонние DXE-драйверы (кандидаты для BYOVB), встроенные утилиты восстановления, старые версии загрузчиков. Каждый .efi-файл экспортируется и проверяется - хеш сопоставляется с публичным dbx-списком UEFI Forum, чтобы понять, отозван бинарь или нет.Ограничения техник и слепые зоны защиты
| Техника | Работает | Не работает | Чем детектируется |
|---|---|---|---|
| BYOVB (CVE-2024-7344) | Системы с устаревшим dbx, без Measured Boot | Secured-core PC (Win 11), актуальные ревокации | dbx-ревокация; TPM Measured Boot; Firmware Scanner (Eclypsium) |
| MOK-ключи | GNU\Linux с shim, без централизованного MOK-управления | Без интерактивного доступа; политики с фиксированным MOK | mokutil --list-enrolled; аудит shim-логов |
| SPI-модификация | Legacy без Boot Guard/PSB; промышленные UEFI | Intel Boot Guard; AMD PSB; SPI write protection | Firmware integrity check при загрузке; физический осмотр |
Measured Boot с TPM - отдельная линия обороны, работающая параллельно с Secure Boot. TPM записывает хеши каждого компонента в цепочке загрузки в PCR-регистры. Даже если Secure Boot обойдён и загрузчик подменён, значения PCR изменятся. Системы с remote attestation (Microsoft Intune, корпоративные fleet management решения) обнаружат расхождение при следующем отчёте. На пентесте BYOVB-техника может дать persistence, но на системах с TPM attestation окно до обнаружения сужается до первого цикла проверки.
DISA STIG для Windows 10 и Windows 11 содержит требования к конфигурации Secure Boot и верификации firmware integrity. В зрелых инфраструктурах, где STIG-baseline применён, dbx обновляется централизованно, third-party UEFI-сертификат может быть отключён - пространство для манёвра минимально.
Главный gap в защите - временное окно между обнаружением уязвимого подписанного бинаря и его ревокацией через dbx. CVE-2024-7344 обнаружена в июле 2024, ревокация - январь 2025. Шесть месяцев, в течение которых подписанный бинарь был рабочим оружием. Martin Smolár из ESET называет это «хорошим результатом по сравнению с аналогичными случаями» - что само по себе говорит о типичных сроках в индустрии.
Большинство отчётов об UEFI Secure Boot уязвимостях заканчиваются выводом «обновляйте dbx». Корректно? Да. Полезно? Не особо. Реальная проблема - в архитектуре доверия: Microsoft подписывает сторонние UEFI-бинари через непрозрачный процесс ревью, и приложение с кастомным PE-загрузчиком, которое обходит
LoadImage/StartImage, проходит его без вопросов.На Red Team-проектах картина повторяется: команды защиты уверены, что Secure Boot - решённая задача, потому что галочка в BIOS стоит. Между «Secure Boot включён» и «цепочка загрузки верифицирована end-to-end» - пропасть. Без TPM attestation, без централизованного управления dbx, без мониторинга содержимого ESP - обход Secure Boot сводится к выбору правильного подписанного бинаря из публичного dbx-списка.
Подписанный уязвимый загрузчик, доставленный на ESP с правами admin, не вызовет ни одного алерта в SIEM до момента, когда remote attestation зафиксирует изменение PCR. А если attestation не настроен - не вызовет никогда.
Количество обнаруженных уязвимых подписанных UEFI-бинарей будет расти - исследователи из ESET и BINARLY целенаправленно этим занимаются. Для пентестеров это расширяет арсенал. Для защитников единственный рабочий ответ - TPM remote attestation и Secured-core конфигурация с отключением доверия к third-party UEFI-сертификату. Проверьте свой парк:
chipsec_main.py -m common.secureboot.variables покажет, стоит ли у вас галочка или реальная защита.
Последнее редактирование модератором:
