Статья Харденинг UEFI и защита firmware: BIOS-пароли, Secure Boot, TPM и Intel Boot Guard — что реально работает

В марте 2023-го ESET зафиксировала первое развёртывание BlackLotus в реальных атаках. UEFI-буткит, который продавали на криминальных форумах примерно за $5 000 (по данным ESET и KrebsOnSecurity), обходил Secure Boot на Windows 11 с актуальным OS-патчем, но устаревшим dbx - через CVE-2022-21894 (CVSS 4.4, CWE-863 - некорректная авторизация при проверке загружаемого образа). Microsoft отозвала уязвимые загрузчики через dbx только в мае 2023 (KB5025885). EPSS - 0.3364, 97-й перцентиль: Top 3% по прогнозу вероятности эксплуатации в ближайшие 30 дней.

Firmware-атаки давно перестали быть привилегией спецслужб. SPI-программатор стоит полторы тысячи рублей. BlackLotus продаётся как MaaS. Акутальный вопрос для SOC и Blue Team: какие из четырёх механизмов защиты firmware (BIOS-пароли, Secure Boot, TPM, Intel Boot Guard) - реально останавливают атакующего с известными техниками эксплуатации, а какие просто иллюзия?

Каждый механизм закрывает определённые тактики по MITRE ATT&CK: от подмены системной прошивки - System Firmware (T1542.001, persistence/stealth) и установки буткитов - Bootkit (T1542.003) до компрометации цепочки поставок - Compromise Hardware Supply Chain (T1195.003, initial access) и злоупотребления подписанным кодом - Code Signing (T1553.002, defense-impairment). Ни один из четырёх не покрывает все этапы kill chain в одиночку.

BIOS-пароль: защита BIOS или security theater​

BIOS-пароль - первое, что упоминают при разговоре о защите предзагрузочной среды. И первое, что обходится на аудитах.

Пароль хранится в CMOS (NVRAM) на материнской плате. Три способа сброса:

1. Вытащить батарейку CMOS на 30 секунд
2. Замкнуть перемычку Clear CMOS
3. Прочитать и перезаписать содержимое SPI-флэша программатором CH341A как делают в настоящее время.

Программатор стоит порядка 1200 рублей на маркетплейсах, SOIC-клипса для подключения к чипу без пайки - ещё 300.

В сценарии Evil Maid (T1200, Hardware Additions) атакующий с физическим доступом обходит BIOS-пароль за 5–10 минут. В серверных средах с BMC/IPMI пароль вообще не барьер: удалённый доступ через BMC позволяет менять настройки BIOS программно, минуя пароль полностью.

Что BIOS-пароль реально защищает: не более, чем просто случайное изменение настроек загрузки сотрудником без технической подготовки.

Detection: BIOS-пароль не генерирует событий в OS-level SIEM. Мониторить нечего. Единственный вариант - периодический аудит конфигурации BIOS через CHIPSEC или проприетарные инструменты вендора материнской платы.

Secure Boot: настройка, обходы и реальная защита от буткитов​

Secure Boot - основной механизм UEFI для защиты от буткитов (T1542.003). Принцип: криптографическая верификация каждого компонента загрузочной цепочки по базе доверенных сертификатов (db) и списку отозванных хэшей (dbx). По документам - надёжная цепочка доверенной загрузки. На практике за последние пять лет - три класса уязвимостей, которые эту цепочку ломают регулярно.

Интерпретация: нужен локальный доступ и высокие привилегии, но сама атака тривиальна, взаимодействие пользователя не требуется. Влияние на целостность - высокое.

Механизм эксплуатации: атакующий подгружает легитимный, но уязвимый загрузчик Windows - тот, что вышел до исправления. Поскольку Microsoft на момент обнаружения BlackLotus не отозвала старые загрузчики через dbx, Secure Boot принимал их как доверенные. Через такой загрузчик BlackLotus устанавливает UEFI-модуль в EFI System Partition, переживающий переустановку ОС, и отключает Windows Defender, HVCI и BitLocker.

По данным ESET, BlackLotus - первый публично документированный UEFI-буткит, обходящий Secure Boot на актуальной Windows 11 и распространявшийся как MaaS на криминальных форумах. Эксплуатация in the wild подтверждена с 1 марта 2023 года - это уже более 1100 дней активной эксплуатации.

Detection для SOC: мониторинг актуальности dbx. Если в парке dbx не содержит хэши отозванных загрузчиков, ваша система уязвима. На Windows: Confirm-SecureBootUEFI в PowerShell покажет, включён ли Secure Boot, но не покажет актуальность dbx. Для верификации dbx - Get-SecureBootPolicy или ручная сверка хэшей. Корреляционное правило: KB5012170 и последующие обновления dbx не применены > 90 дней = высокий приоритет.

CVE-2024-7344: обход через уязвимое UEFI-приложение Reloader​

NVD CVSS 8.2 (HIGH) / MSRC CVSS 6.7 (Important) - расхождение в оценке между источниками; MSRC 6.7 относится к Windows Server 2012/2012 R2 (KB5050048/5050004/5049993), для современных ОС руководствоваться NVD CVSS 8.2. Основной момент - Scope: Changed (S:C): уязвимость в приложении, подписанном сертификатом Microsoft Corporation UEFI CA 2011, позволяет выполнить произвольный код в контексте UEFI.

Корневая причина - CWE-347 (Improper Verification of Cryptographic Signature): приложение использует кастомный PE-загрузчик вместо стандартных UEFI-функций LoadImage и StartImage. Этот загрузчик не проверяет подписи и загружает произвольный UEFI-бинарник из файла cloak.dat - даже неподписанный. Красота...

Согласно исследованию ESET (январь 2025), уязвимое UEFI-приложение - Howyar Reloader (32/64-bit). По данным NVD, затронуты: Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery, Sanfong EZ-back System, CS-Grp NeoImpact. В отчёте ESET также упоминаются WASAY eRecoveryRX и SignalComputer HDD King, но они отсутствуют в NVD affected list и требуют дополнительной верификации. Атакующему не нужно ждать, пока жертва установит один из этих продуктов: достаточно принести свою копию уязвимого бинарника на любую систему с Microsoft third-party UEFI certificate в db. На Windows 11 Secured-core PC этот сертификат по умолчанию не доверен.

Microsoft отозвала уязвимые бинарники в Patch Tuesday 14 января 2025 года.

Detection для SOC: файл cloak.dat в EFI System Partition - прямой IoC. Мониторинг изменений в ESP (/boot/efi/ в Linux, mountvol + Sysmon Event ID 11 на Windows для путей \EFI\). Если организация не использует перечисленные продукты восстановления, но их бинарники обнаружены на хосте - это инцидент.

PKfail: заводские тестовые ключи в продакшене​

В июле 2024 года Binarly обнаружила: около 900 моделей устройств от различных OEM (Acer, Dell, HP, Lenovo, Supermicro и др.), использующих BIOS-код от IBV (AMI, Insyde, Phoenix), поставлялись с тестовыми ключами Secure Boot Platform Key (PK). Эти ключи генерируются при разработке - производитель обязан заменить их перед выпуском. В ряде случаев приватный ключ оказался публично доступен. Как такое возможно, чтобы тестовый ключ, который должен был умереть в лаборатории, уехал в продакшен на сотнях моделей?!

Если приватный PK доступен атакующему, он подписывает произвольный загрузчик - Secure Boot примет его как доверенный. Ремедиация: обновление firmware с заменой тестового ключа. Но только если производитель выпустил обновление. А по данным IBM X-Force, среднее время между публикацией CVE и устранением в организации - 29 месяцев, это более 2 лет! Для firmware-патчей эта цифра реалистично ещё выше.

Отдельный кейс - LogoFAIL: класс уязвимостей в библиотеках парсинга изображений UEFI, обнаруженный Binarly в декабре 2023 года. Атакующий с доступом к EFI System Partition размещает вредоносный файл логотипа, который эксплуатирует парсер до проверки Secure Boot. LogoFAIL обходит Secure Boot полностью - код выполняется до этапа верификации. Картинка с логотипом ломает цепочку доверия. Иронично.

Detection для SOC: аудит Platform Key через chipsec_util uefi var-list или UEFITool. Тестовые ключи содержат характерные строки (DO NOT SHIP, DO NOT TRUST). Binarly предоставляет инструмент pk.fail для проверки конкретных устройств. Нетривиальные файлы изображений в ESP - потенциальный IoC для LogoFAIL.

TPM безопасность и измеренная загрузка: что реально защищает чип​

TPM (Trusted Platform Module) и Measured Boot используют принципиально иной подход: не запрещают загрузку неподписанного кода, а фиксируют, что именно загружалось. Каждый компонент загрузочной цепочки хэшируется и записывается в PCR-регистры (Platform Configuration Registers) TPM. Если загрузчик или ядро изменены - значения PCR изменятся.

На практике TPM эффективен в двух сценариях:

BitLocker с TPM-привязкой. Ключ шифрования диска запечатывается в TPM с привязкой к PCR 0, 2, 4, 7.
Эти специфические PCR-реакции представляют следующие компоненты в процессе загрузки системы: 0 - Исполняемые файлы основного системного ПО (BIOS/UEFI), 2 - Расширенный или подключаемый исполняемый код, 4 - Начальная последовательность загрузки, 7 - Конфигурация безопасной загрузки и сертификаты.
Если загрузочная цепочка изменена, TPM не отдаёт ключ - диск не расшифровывается. Против Evil Maid (T1200) это серьёзный барьер.

Remote attestation. Сервер аттестации запрашивает у хоста подписанный TPM отчёт с PCR-значениями и сравнивает с baseline. Отклонение = алерт. Это единственный способ обнаружить скомпрометированный firmware удалённо, без физического доступа к машине.

Ограничения TPM, о которых обычно молчат:

• TPM не предотвращает загрузку - только фиксирует. Без remote attestation или BitLocker-привязки PCR-значения никто не проверяет, и измеренная загрузка бесполезна. Фактически - дорогая железка, которая считает хэши в пустоту.
• TPM не защищает от атак в SMM (Ring -2): SMM-код выполняется с привилегиями выше гипервизора и может манипулировать данными до записи в PCR.
• TPM 1.2 vs TPM 2.0: только TPM 2.0 поддерживает SHA-256 PCR-банки. TPM 1.2 - SHA-1 only, legacy.
• Cold boot: при физическом доступе атакующий может извлечь ключи из RAM до очистки.

# Проверка версии TPM и снятие PCR-значений
tpm2_getcap properties-fixed | grep -E "TPM2_PT_FAMILY|TPM2_PT_REVISION"
tpm2_pcrread sha256
# Анализ Event Log для поиска аномалий в загрузочной цепочке
tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements  # требует root, смонтированного securityfs и ядра с CONFIG_TCG_TPM; если файл отсутствует: mount | grep securityfs && dmesg | grep -i tpm

Detection для SOC: при наличии remote attestation - baseline PCR + alert на отклонение. Без attestation - периодический сбор PCR-значений через агент и сравнение с эталоном. Изменение PCR-0 или PCR-7 без зафиксированного обновления firmware = потенциальная компрометация.

Intel Boot Guard: аппаратный корень доверенной загрузки​

Intel Boot Guard - единственный из четырёх механизмов, дающий аппаратный корень доверия. OEM при производстве прошивает хэш своего публичного ключа в однократно программируемые fuses процессора. При каждом старте CPU проверяет подпись Initial Boot Block (IBB) в SPI-флэше. Такой подход, критичен на столько, на сколько это вообще возомжно: несовпадение - система не загрузится. Точка.

Два режима: Verified Boot - CPU проверяет подпись IBB и блокирует загрузку неподписанного firmware (жёсткий контроль). Measured Boot - CPU записывает хэш IBB в TPM PCR-0, но не блокирует загрузку (требует remote attestation для реакции). На практике Verified Boot - тот случай, когда атакующий с SPI-программатором может перезаписать весь SPI-флэш, но CPU откажется загружать IBB с чужой подписью. Это аппаратно закрывает T1542.001 (System Firmware). Программатор за полторы тысячи рублей тут бесполезен.

Ограничения:

• Конфигурация Boot Guard - ответственность OEM. Если производитель не активировал Boot Guard или прошил слабый ключ, пользователь не может это исправить - fuses(предохранители) одноразовые. Пережжённые fuses не перешьёшь.
• Boot Guard защищает только IBB (начальная фаза SEC/PEI). Последующие фазы (DXE, BDS) должны быть защищены Secure Boot.
• Supply chain атака до OEM-фьюзинга (T1195.003) обходит Boot Guard: если вредоносный firmware подписан ключом OEM - всё, игра окончена на старте.
• Поддержка зависит от поколения CPU: полноценно - Coffee Lake и новее.

# Проверка SPI flash write protection через CHIPSEC
python chipsec_main.py -m common.bios_wp
# Анализ FIT-таблицы для верификации Boot Guard
python chipsec_util.py spi dump rom.bin

Дамп rom.bin анализируется через UEFITool: FIT-таблица должна содержать записи типа 0x0B (Key Manifest) и 0x0C (Boot Policy Manifest). Их отсутствие означает, что Boot Guard не сконфигурирован на устройстве.

Сравнение механизмов харденинга UEFI и защиты firmware​

Механизм	Защищает от	Не защищает от	Стоимость обхода	Требует	Detection
BIOS-пароль	Случайное изменение настроек	SPI-программатор, BMC/IPMI	~1500 руб. (CH341A + клипса)	Ничего	Невозможен на уровне ОС
Secure Boot	Неподписанные загрузчики, буткиты без CVE	PKfail, CVE-2024-7344, LogoFAIL, устаревший dbx	Vendor advisory + исследование ESET (бесплатно); BlackLotus-буткит - ~$5000 (по данным ESET/KrebsOnSecurity)	Корректные ключи, обновление dbx	Мониторинг dbx, EFI-переменных, файлов ESP
TPM / Measured Boot	Незаметная подмена загрузчика (при attestation)	SMM-атаки (Ring -2), cold boot	Высокая (SMM-эксплойт)	TPM 2.0, remote attestation	PCR baseline + алерт на отклонение
Intel Boot Guard (Verified)	Модификация IBB в SPI	Supply chain до фьюзинга, DXE-фаза	Крайне высокая (аппаратная)	CPU Coffee Lake+, OEM-конфигурация	Проверка IBB через CHIPSEC

Ни один механизм в изоляции не закрывает всю цепочку. Рабочая комбинация: Intel Boot Guard (IBB) → Secure Boot с актуальным dbx (bootloader, kernel) → TPM с remote attestation (обнаружение). BIOS-пароль - дополнительный слой от случайных изменений, не компенсирующий отсутствие остальных.

Detection-чеклист: мониторинг firmware-атак в SOC​

Firmware-атаки не генерируют типичных алертов в SIEM. Ниже - конкретные точки мониторинга.

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

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

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

1. SPI Flash write protection - CHIPSEC common.bios_wp пройден. CHIPSEC common.bios_wp проверяет BLE=1 и SMM_BWP=1. Безопасная конфигурация: BLE=1 И SMM_BWP=1. Только BLE=1 без SMM_BWP уязвим к Speed Racer race condition (Kallenberg/Wojtczuk 2014). BLE=0 - SPI flash не защищён от записи
2. Intel Boot Guard активен - FIT-таблица в дампе SPI содержит KM (0x0B) и BPM (0x0C)
3. Firmware включены в VM-процесс - цикл обновлений не реже раз в квартал
4. ESP мониторинг настроен - Sysmon Event ID 11 для путей \EFI\ (Windows), inotifywait /boot/efi/ (Linux)
5. PCR baseline снят и хранится - отклонение PCR-0 / PCR-7 без тикета на обновление = инцидент

Правила корреляции для SIEM:

• Появление файлов cloak.dat или нетипичных .efi-бинарников в ESP -> высокий приоритет (IoC для CVE-2024-7344)
• Windows Event ID 1796 (изменение состояния Secure Boot) без change request -> расследование
• Отклонение PCR от baseline без зафиксированного обновления firmware -> расследование
• Отсутствие dbx-обновлений > 90 дней на хосте с активным Secure Boot -> средний приоритет, эскалация

Для субъектов КИИ: firmware-компрометация подпадает под ФЗ-187, инциденты подлежат уведомлению через ГосСОПКА (НКЦКИ) в сроки 3–24 часа в зависимости от категории значимости объекта.

На реальных аудитах firmware-уровень проверяют единицы - даже в организациях с развитым SOC. По данным IBM X-Force, среднее время между публикацией CVE и устранением - 29 месяцев. Для firmware-патчей в корпоративных средах эта цифра ещё выше: у большинства организаций вообще нет процесса обновления BIOS/UEFI как части vulnerability management. EDR и XDR работают в Ring 0, firmware живёт в Ring -2 - между ними пропасть, в которую проваливается весь detection.

Из четырёх механизмов только Intel Boot Guard в режиме Verified Boot останавливал на реальных проектах. Secure Boot без актуального dbx и без аудита Platform Key - формальность, которая рассыпается при первом же CVE с опубликованными деталями. TPM без remote attestation - дорогая железка, не генерирующая ни одного алерта. BIOS-пароль - ну, CH341A и SOIC-клипса укладываются в полторы тысячи рублей.

Сдвиг произойдёт, когда firmware integrity станет частью стандартного SOC-мониторинга наравне с EDR-телеметрией - а не будет проверяться раз в год при compliance-аудите. На codeby.net есть тред по firmware forensics и baseline-подходам для корпоративных парков - если строите detection ниже Ring 0, стоит сверить подходы с коллегами, которые уже набили шишки на промышленных масштабах.