Обход Secure Boot через уязвимости в UEFI

Салют, боец! Сегодня мы погрузимся в самые тёмные уголки системы — туда, где живёт UEFI и его хвалёный Secure Boot. Ты узнаешь, что эта “непробиваемая” защита на самом деле имеет слабые места, и я покажу, как их находить и использовать для запуска своего кода. Забудь про теорию из учебников, здесь только хардкор, практика и рабочие инструменты.

Обход Secure Boot через уязвимости в UEFI

Secure Boot — это стандарт безопасности, созданный для того, чтобы при запуске компьютера загружалось только доверенное программное обеспечение, подписанное производителем (OEM). Идея проста: каждая компонента в цепи загрузки (прошивка, загрузчик ОС) проверяет криптографическую подпись следующей. Если подпись неверна или отсутствует — загрузка останавливается. Это мощный барьер против буткитов и другого низкоуровневого вредоносного ПО.

Но, как и любая крепость, Secure Boot имеет уязвимости. Атака на него — это не лобовой штурм, а скорее диверсия. Основная цель — найти легитимный, подписанный Microsoft или другим вендором загрузчик, в котором есть баг. Затем, уже имея права администратора в работающей системе, ты подменяешь оригинальный загрузчик на этот уязвимый, но всё ещё доверенный. Система его “съест”, так как подпись в порядке, а ты получаешь возможность проэксплуатировать уязвимость и выполнить произвольный код до старта основной ОС.

Такие атаки — не выдумка. Вот несколько нашумевших примеров:

• CVE-2022-34302 (New Horizon Datasys): Уязвимость в загрузчике, которая позволяла не только обойти Secure Boot, но и отключать другие механизмы безопасности, например, проверку через TPM.
• BlackLotus: Один из первых реально работающих буткитов, который использовал старые, но всё ещё подписанные драйверы для обхода защиты и закрепления в системе.
• CVE-2024-7344 и CVE-2025-3052: Свежие уязвимости, найденные в UEFI-приложениях от сторонних разработчиков. Эти приложения были подписаны доверенным сертификатом Microsoft, что открывало дорогу для атак на подавляющее большинство современных устройств.

Ключевая мысль: слабое звено — это огромный зоопарк сторонних драйверов и загрузчиков, которые получают цифровую подпись от Microsoft для совместимости. Именно в них чаще всего и находят дыры.

Настройка Chipsec для анализа прошивок

Для охоты на баги в UEFI нам понадобится серьёзный инструмент. Chipsec — это мощный фреймворк с открытым исходным кодом для анализа безопасности платформы: железа, прошивок (BIOS/UEFI) и других низкоуровневых компонентов 

Что умеет Chipsec?

• Читать и записывать данные в SPI-флеш, где хранится BIOS/UEFI.
• Анализировать конфигурацию защитных механизмов: блокировку записи BIOS, настройки SMM, параметры Secure Boot.
• Дампить прошивку для офлайн-анализа.
• Имеет набор готовых модулей для поиска известных уязвимостей.

Пошаговая установка и запуск

1. Клонируем репозиторий:

2. Установка зависимостей (для Linux):

3. Сборка драйвера и утилит:

4. Загрузка драйвера:
Это самый важный и опасный шаг. Chipsec для работы нужен прямой доступ к железу, который он получает через свой драйвер.

ВАЖНО! Использование Chipsec на рабочей машине — плохая идея. Его драйвер даёт приложениям прямой доступ к физической памяти и железу, что может привести к зависанию системы или даже её повреждению. В Windows для его работы придётся включать тестовый режим подписи драйверов (TestSigning), что отключает важный механизм защиты ядра. Используй его только на тестовом стенде, который не жалко.

Первый запуск и основные команды

Давай проверим, что всё работает. Запустим основной модуль для автоматического сканирования на известные уязвимости:

Эта команда прогонит все доступные модули и выдаст отчёт о конфигурации твоей системы. Обращай внимание на результаты с пометкой [FAIL] — это потенциальные проблемы.

Для анализа Secure Boot есть специальная группа модулей:

Практика: Дамп и анализ BIOS

Теория — это хорошо, но давай перейдём к делу. Наша цель — получить образ прошивки (дамп) и поковырять его в поисках интересного.

1. Создание дампа BIOS

С помощью Chipsec это делается одной командой. Она читает содержимое SPI-флеш памяти и сохраняет его в файл.

В результате ты получишь файл bios_dump.bin — это и есть полная копия твоей прошивки. Если где-то чтение не удалось (например, из-за защищённых регионов), эти области будут заполнены 0xFF.

2. Анализ дампа

Сырой бинарный дамп — это просто набор байтов. Чтобы превратить его в информацию, нужны правильные инструменты.

• UEFITool: Твой лучший друг для работы с прошивками. Эта утилита парсит структуру UEFI-образа (файловую систему FFS) и позволяет в удобном виде посмотреть все его компоненты: драйверы (DXE), PEI-модули, приложения. Открой в нём свой bios_dump.bin. Ты увидишь дерево всех файлов внутри прошивки.
• Поиск уязвимых компонентов: Внутри UEFITool ты можешь извлекать отдельные EFI-файлы. Ищи драйверы от сторонних производителей. Их легко опознать по названиям. Если ты нашёл подозрительный файл, например SomeVendorDriver.efi, можно поискать информацию о его уязвимостях в сети.
• Дифференциальный анализ: Если ты подозреваешь, что прошивка была модифицирована (например, буткитом), можно сравнить её с “чистым” дампом с такой же модели устройства. Для этого существуют скрипты вроде bios_diff.py. Они показывают, какие модули были изменены, добавлены или удалены.

Пример сценария атаки

Допустим, в процессе анализа ты нашёл в прошивке старый, но подписанный драйвер VulnerableStorage.efi, в котором есть уязвимость переполнения буфера при обработке имени файла.

Твой план действий:

1. Получить права администратора в целевой ОС.
2. Подготовить эксплойт: Создать вредоносный файл с очень длинным именем, который вызовет переполнение буфера в VulnerableStorage.efi и передаст управление твоему шелл-коду.
3. Подменить загрузчик: С помощью утилит для работы с переменными UEFI (например, efibootmgr в Linux) изменить порядок загрузки так, чтобы система сначала загружала не стандартный bootmgfw.efi (Windows) или grubx64.efi (Linux), а специальное UEFI-приложение, которое сначала загрузит уязвимый драйвер VulnerableStorage.efi, а затем передаст ему на обработку твой вредоносный файл.
4. Перезагрузка: После перезагрузки UEFI загрузит твоё приложение, оно подгрузит уязвимый драйвер, тот споткнётся на твоём файле, и… бинго! Твой код выполняется на самом раннем этапе загрузки, с максимальными привилегиями и до того, как антивирусы и ОС вообще проснутся.

Это высший пилотаж, требующий глубоких знаний. Но теперь ты знаешь, в каком направлении копать. Secure Boot — это мощная технология, но не панацея. Уязвимости были, есть и будут, а значит, всегда есть работа для тех, кто не боится заглянуть под капот. Удачи в исследованиях