Статья Обход защиты BIOS: отключение Secure Boot на залоченных прошивках

На red team-проекте мне достался корпоративный Lenovo ThinkPad с полностью залоченным BIOS - Supervisor Password, заблокированный порядок загрузки, Secure Boot в режиме enforced. Задача конкретная: загрузить свою ОС с USB и закрепиться на эндпоинте так, чтобы переустановка Windows не помогла. За три часа работы с программатором CH341A и анализом дампа прошивки через UEFITool удалось сбросить пароль и обнаружить в прошивке подписанный Microsoft DXE-драйвер, позволяющий загрузку произвольного кода. Ниже - разбор конкретных техник обхода защиты BIOS и Secure Boot, которые работают на реальном железе, с ограничениями каждого метода.

Место в цепочке атаки: зачем ломать прошивку​

Компрометация UEFI-прошивки - не самоцель, а решение двух задач в kill chain: persistence ниже уровня ОС и stealth от программных средств защиты.

По классификации MITRE ATT&CK атаки на прошивку покрывают несколько техник:

• T1542.001 System Firmware (Persistence, Defense Evasion) - модификация системной прошивки для закрепления
• T1542.003 Bootkit (Persistence, Defense Evasion) - внедрение кода в процесс загрузки
• T1495 Firmware Corruption (Impact) - повреждение прошивки для вывода системы из строя
• T1562.001 Disable or Modify Tools (Defense Evasion) - отключение защитных механизмов через модификацию pre-boot среды
• T1553.006 Code Signing Policy Modification (Defense Evasion) - изменение политик подписи кода, включая модификацию db/dbx

Типичный сценарий: физический доступ к эндпоинту → обход BIOS lock → отключение Secure Boot → загрузка с внешнего носителя → установка bootkit → возврат настроек BIOS. Штатная ОС загружается нормально, EDR работает, пользователь ничего не замечает - но payload выполняется до старта Windows и любого защитного ПО. Предшествующий этап - получение физического доступа (проникновение, social engineering, доступ к серверной). Следующий - lateral movement через скомпрометированный эндпоинт.

Цепочка доверия UEFI Secure Boot: что именно ломаем​

Secure Boot опирается на иерархию криптографических ключей в NVRAM:

• Platform Key (PK) - корень доверия, принадлежит OEM (Lenovo, Dell, HP). Контролирует доступ к KEK.
• Key Exchange Key (KEK) - ключи для верификации изменений в db и dbx.
• Signature Database (db) - whitelist: сертификаты и хеши разрешённых бинарей.
• Revocation List (dbx) - blacklist: хеши отозванных или уязвимых бинарей.

При загрузке UEFI Boot Manager проверяет каждый компонент (загрузчик, драйвер, ядро) по db и dbx. Бинарь с валидной подписью из db и отсутствующий в dbx - запускается. Иначе - Security Violation.

На подавляющем большинстве устройств в db стоят два сертификата Microsoft:

• Microsoft Windows Production PCA 2011 - для собственных загрузчиков Microsoft
• Microsoft Corporation UEFI CA 2011 - для подписи стороннего UEFI-ПО (Linux shim, утилиты восстановления, дисковое шифрование)

Второй сертификат и создаёт основную поверхность атаки: любой разработчик может отправить свой UEFI-бинарь на подпись Microsoft через Windows Hardware Dev Center. Если в подписанном бинаре окажется уязвимость - Secure Boot его пропустит. Как отметили исследователи ESET, непрозрачность процесса ревью со стороны Microsoft порождает системную проблему: «очевидно небезопасные» бинари получают подпись и попадают в доверенную среду.

Программные векторы обхода Secure Boot​

CVE-2024-7344: кастомный PE-загрузчик обходит цепочку доверия​

Согласно исследованию ESET (опубликовано 16 января 2025), CVE-2024-7344 затрагивает UEFI-приложение Howyar Reloader, подписанное сертификатом Microsoft Corporation UEFI CA 2011.

CVSS: 8.2 (HIGH), вектор CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H. CWE-347 - Improper Verification of Cryptographic Signature.

Суть проста до неприличия: приложение использует кастомный PE-загрузчик вместо стандартных UEFI-функций LoadImage и StartImage. Из-за этого оно тянет любой UEFI-бинарь - включая неподписанный - из файла с жёстко заданным именем cloak.dat, полностью игнорируя состояние Secure Boot. То есть Microsoft подписал бинарь, который в явном виде обходит механизм, ради которого Secure Boot и существует.

Затронутые продукты (по данным NVD): Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery, Sanfong EZ-back System, CES NeoImpact. По данным ESET, уязвимы также Wasay eRecoveryRX и SignalComputer HDD King, однако они отсутствуют в перечне NVD и требуют независимой верификации.

Вектор эксплуатации: атакующий с правами локального администратора (PR:H в CVSS-векторе) размещает уязвимое, но подписанное приложение на EFI System Partition вместе с вредоносным cloak.dat. Secure Boot валидирует подпись бинаря, тот загружает произвольный код из cloak.dat. И вот что красиво: для эксплуатации не нужно, чтобы на целевой машине стоял уязвимый софт - атакующий приносит свою копию подписанного бинаря. Классическая атака BYOVB (Bring Your Own Vulnerable Bootloader).

По данным MSRC, уязвимые бинари отозваны обновлением от 14 января 2025 (KB5050048, KB5050004, KB5049993). Microsoft в MSRC advisory от 14.01.2025 оценивает impact как Important (Security Feature Bypass, CVSS base=6.7 - ниже NVD-оценки 8.2, поскольку MSRC оценивает обход защитной функции Windows, а NVD - воздействие через уязвимое UEFI-приложение).

Согласно CISA Vulnrichment, SSVC Decision - Track: эксплуатация в дикой природе не зафиксирована (exploitation: none), автоматизация невозможна (automatable: no), но технический импакт - total. Вероятность эксплуатации по EPSS - 0.39% в течение 30 дней (60-й перцентиль, выше медианы среди всех CVE), что указывает на умеренный, но реальный риск.

Работает если: Secure Boot включён, но dbx не содержит хеш уязвимого бинаря (обновление от января 2025 не установлено); атакующий имеет права записи на ESP.

Не работает если: dbx обновлён; Windows 11 Secured-core PC с отключённым доверием к third-party UEFI CA; Intel Boot Guard активен и верифицирует firmware до запуска UEFI Boot Manager.

CVE-2020-10713 (BootHole): переполнение буфера в GRUB2​

CVSS: 8.2 (HIGH), вектор CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H. CWE-120 - Buffer Copy without Checking Size of Input.

BootHole - классический buffer overflow в парсере конфигурационного файла grub.cfg загрузчика GRUB2 (до версии 2.06). Secure Boot верифицирует подпись бинаря GRUB2, но не верифицирует содержимое grub.cfg. Атакующий с root-доступом модифицирует конфигурационный файл, чтобы вызвать переполнение при следующей загрузке. Согласно NVD, вектор не ограничен локальным root - атакующий также может подменить конфигурацию через PXE-boot сеть или использовать удалённый root-доступ к сетевой системе. Переполнение происходит после верификации загрузчика, но до загрузки ядра - результат: arbitrary code execution в доверенном контексте.

Затронутые системы (по данным NVD): GNU GRUB2, Debian Linux, openSUSE Leap, VMware Photon OS. По данным MSRC (релиз 18.08.2020), затронуты CBL-Mariner grub2 до версии 2.06~rc1. EPSS - 0.37% (59-й перцентиль).

Архитектурная проблема, которую демонстрирует BootHole: подпись валидирует целостность исполняемого кода, но не валидирует данные, которые этот код обрабатывает. Подписали бинарь - молодцы. А что он дальше парсит - не ваше дело. Логика, достойная отдельной записи в учебнике.

Работает если: на системе стоит GRUB2 < 2.06, dbx не обновлён, атакующий имеет root-доступ (локальный или удалённый) либо возможность подменить PXE-boot конфигурацию. Не работает если: GRUB2 обновлён до 2.06+; система без GRUB2 (чистый Windows без dual boot); хеш уязвимого GRUB2 в dbx.

SMM Exploitation: атака из Ring -2​

System Management Mode (SMM) - привилегированный режим исполнения x86-процессоров, «Ring -2». Код в SMM выполняется в отдельном адресном пространстве (SMRAM), невидимом для ОС и гипервизора. Запускается через System Management Interrupts (SMI).

Если атакующий находит уязвимость в SMI-обработчике (buffer overflow, Confused Deputy - невалидация указателей из непривилегированного контекста), он получает исполнение кода в SMM. Из этого контекста можно:

• Модифицировать переменные db/dbx/KEK/PK в NVRAM - прямой обход Secure Boot (T1553.006)
• Полностью отключить защиту Secure Boot
• Перезаписать SPI-флеш с прошивкой (T1601.001 Patch System Image)

Обнаружить SMM-эксплуатацию стандартными средствами нельзя - код исполняется прозрачно для ядра ОС. Детектирование требует аппаратного мониторинга (Intel Boot Guard) или специализированных проверок целостности через внешний TPM.

Работает если: SMRAM не заблокирована (CHIPSEC модуль common.smm возвращает [FAILED]), в прошивке есть уязвимый SMI-обработчик. Не работает если: SMM Lock корректно настроен, Memory Range Register (SMRR) активен.

Кризис dbx: почему отзыв не решает проблему​

Механизм dbx - главная линия обороны против BYOVB. На практике он разваливается по трём причинам:

1. Размер NVRAM ограничен. dbx с тысячами хешей может тупо не поместиться в доступное пространство SPI-флеша.
2. Риск «окирпичивания». Агрессивное обновление dbx блокирует единственный рабочий загрузчик на диске - система перестаёт загружаться. Администраторы это знают и обновления откладывают.
3. Окно уязвимости. Между обнаружением CVE и развёртыванием dbx-обновления на всех устройствах проходят месяцы.

Атакующий эксплуатирует это окно, доставляя старый, уязвимый, но всё ещё «доверенный» загрузчик, чей хеш не успел попасть в dbx целевой системы.

Обход защиты BIOS при физическом доступе​

Снятие и модификация дампа SPI-флеша​

Требования к окружению:

• Программатор: CH341A (~500 руб.) или Dediprog SF600 (~$300 для профессионального использования)
• Прищепка SOIC-8 / SOIC-16 для подключения к микросхеме без выпаивания
• ПК с Linux (Ubuntu 22.04+), 4 ГБ RAM минимум
• flashrom (apt install flashrom), UEFITool NE Alpha 68 (последний релиз: 2024, GitHub, активный проект)
• Для анализа DXE-модулей: Ghidra 11.x (бесплатный) или IDA Pro

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

BIOS Password Bypass без программатора​

На ряде платформ пароль BIOS можно обойти без пайки - снятие CMOS-батарейки, master-пароли на основе Service Tag (на части моделей Dell), аппаратный сброс через замыкание определённых контактов. Универсального метода не существует - на каждый вендор и модель свой подход. Для red team дамп SPI-флеша остаётся самым надёжным вариантом, не зависящим от вендор-специфичных бэкдоров.

Аудит прошивки с CHIPSEC​

Требования к окружению:

• ОС: Linux (Ubuntu 22.04 / Fedora 38+) или Windows 10/11 с включённым TestSigning
• Python 3.8+, build-essential, python3-dev, nasm, libpci-dev
• 4+ ГБ RAM, root-доступ
• Запускать только на тестовом стенде - CHIPSEC загружает kernel-level драйвер с прямым доступом к аппаратным ресурсам. На продуктивном сервере это может закончиться BSOD, и объяснять причину заказчику будет неловко.

CHIPSEC (последний релиз: 2024, ~2.5k звёзд на GitHub, активно поддерживается Intel) - фреймворк для аудита безопасности платформы на уровне firmware.

Преимущества	Ограничения	Когда использовать	Когда не использовать
Десятки проверок прошивки из коробки	Требует kernel-level драйвер	Аудит конфигурации, grey box пентест	На продуктивных серверах с SLA
Open-source, поддержка Intel	Риск BSOD / kernel panic	Проверка перед развёртыванием	Remote-only пентест без агента
PASS/FAIL по каждой проверке	Не все модули на ARM	Forensics: анализ дампов прошивки	На устройствах клиента без согласования

Ключевые модули для обхода защиты BIOS:

• common.secureboot.variables - проверяет защиту переменных Secure Boot от модификации из ОС
• common.spi_lock - SPI-флеш write protection; [FAILED] = прошивку можно перезаписать программно без физического доступа
• common.bios_wp - Write Protection для BIOS-региона
• common.smm - защита SMRAM; [FAILED] = SMM-эксплуатация возможна

# Проверка защиты переменных Secure Boot
sudo python3 chipsec_main.py -m common.secureboot.variables
# Проверка SPI write protection
sudo python3 chipsec_main.py -m common.spi_lock
# Дамп SPI-флеша (альтернатива аппаратному программатору)
sudo python3 chipsec_util.py spi dump bios_dump.bin

Если common.spi_lock возвращает [FAILED], прошивку можно перезаписать программно - это путь к установке UEFI rootkit без вскрытия корпуса. На корпоративных устройствах, не прошедших firmware hardening, такое встречается регулярно. На одном аудите из десяти ноутбуков в организации семь вернули [FAILED] по spi_lock - и это были не самые дешёвые машины.

Выбор вектора атаки на прошивку​

Условие	Вектор	Инструмент	Предусловия
Физический доступ, нет Boot Guard	Дамп и модификация SPI	CH341A + flashrom + UEFITool	Доступ к материнской плате
Root/admin в ОС, dbx устаревший	BYOVB через CVE-2024-7344	Копия подписанного бинаря + payload	Права записи на ESP
Root в Linux с GRUB2 < 2.06	BootHole (CVE-2020-10713)	Модифицированный grub.cfg	GRUB2 как загрузчик
SPI write protection отключена	Программная перезапись прошивки	CHIPSEC	Root/admin в ОС
SMRAM не заблокирована	SMM exploitation	Кастомный SMI exploit	Root/admin, уязвимый SMI handler

Grey box сценарий (выданы low-priv credentials): сначала privilege escalation до admin/root (T1068), затем проверка состояния dbx: mokutil --sb-state в Linux или Confirm-SecureBootUEFI в PowerShell. Если dbx устаревший - BYOVB. Параллельно: sudo python3 chipsec_main.py -m common.spi_lock - если SPI не залочен, доступна программная перезапись прошивки. Если всё залочено и обновлено - нужен физический доступ или SMM-вектор.

Что фиксирует защита при атаке на прошивку​

Что детектируется:

• Запись на EFI System Partition - любой EDR с мониторингом файловой системы зафиксирует появление .efi-файлов в /boot/efi/ или \EFI\Boot\. CrowdStrike Falcon и SentinelOne регистрируют файловые операции на ESP.
• Изменение переменных Secure Boot - SetVariable() для PK/KEK/db/dbx логируется в UEFI event log. Windows фиксирует это через Event ID 1032.
• Нарушение Measured Boot - при загрузке хеши компонентов записываются в PCR-регистры TPM. Remote Attestation выявит расхождение с baseline.

Что НЕ видит программная защита:

• Аппаратная модификация SPI-флеша через внешний программатор - происходит при выключенной системе, EDR бессилен. Машина выключена, программатор подключён к чипу напрямую - какой тут EDR?
• SMM-level операции - код в Ring -2 невидим для ОС, гипервизора и любого software-based мониторинга.

Вендор-специфика: Kaspersky EDR Expert включает UEFI Scanner для проверки целостности прошивки при загрузке. Microsoft Defender for Endpoint поддерживает UEFI Scanner на Windows 10/11 с UEFI. CrowdStrike Falcon мониторит файловые операции на ESP, но firmware integrity monitoring не входит в стандартную конфигурацию. Ни одно из этих решений не обнаружит модификацию через внешний программатор - для этого нужен Intel Boot Guard или аппаратный Root of Trust.

Чеклист защиты прошивки​

1. Активировать Secure Boot в режиме Enforce (не Setup Mode) на всех эндпоинтах.
2. Установить актуальные обновления dbx - применять UEFI revocations из Microsoft Patch Tuesday.
3. Включить Intel Boot Guard (или AMD Platform Secure Boot) - root of trust перемещается в аппаратные фьюзы CPU.
4. Проверить SPI write protection: модуль CHIPSEC common.spi_lock должен возвращать [PASSED].
5. Настроить BIOS Supervisor Password минимум 12 символов; убедиться, что пароль хранится в защищённой NVRAM.
6. Включить Measured Boot и Remote Attestation через TPM 2.0 на критичных серверах.
7. Мониторить запись на ESP - правило в EDR/SIEM на создание/модификацию файлов в /boot/efi/ и \EFI\Boot\.
8. Отключить CSM (Compatibility Support Mode) - он полностью обходит цепочку доверия UEFI.
9. На Windows 11 использовать Secured-core PC, где third-party UEFI CA по умолчанию не доверена.
10. Применить физическую защиту SPI-флеша - anti-tamper наклейки или заливка компаундом на критичных устройствах.

Обход защиты BIOS и Secure Boot - одна из тех тем, где декларируемая и реальная безопасность расходятся сильнее всего. Каждый год всплывают CVE уровня CVE-2024-7344, где подписанный Microsoft бинарь содержит настолько очевидный архитектурный дефект - кастомный PE-загрузчик вместо стандартных LoadImage/StartImage - что вопрос «а что именно проверяет Microsoft при подписании стороннего UEFI-кода?» перестаёт быть риторическим. По данным ESET, это далеко не первый случай обнаружения «очевидно небезопасных» подписанных бинарей, и сколько ещё таких скрыто - никто не знает. На аудитах прошивок корпоративных ноутбуков SPI write protection нередко не настроена, а dbx не обновлялся с момента покупки устройства. Secure Boot при этом формально включён и создаёт иллюзию защиты. Реальная безопасность pre-boot среды начинается не с галочки в BIOS Setup, а с Intel Boot Guard + актуальный dbx + мониторинг ESP + физическая защита. Без любого из этих компонентов Secure Boot - замок на двери без стен. Проверьте свои эндпоинты через CHIPSEC - common.spi_lock и common.secureboot.variables. Если увидите [FAILED] - у вас та же проблема, что и у большинства.