Анализ и эксплуатация CVE-2025-4275 (Hydr0ph0bia) — уязвимости цепочки доверия Secure Boot, при которой переменные прошивки используются для внедрения контролируемых злоумышленником сертификатов, которым доверяют последующие компоненты загрузки.
Этот репозиторий содержит исследовательские материалы, связанные с CVE-2025-4275 — уязвимостью обхода Secure Boot, затрагивающей UEFI-совместимую прошивку на базе Insyde H2O. В нём собраны технический анализ уязвимости, бинарные файлы, участвующие в проблеме, а также документация и инструменты, предназначенные для того, чтобы помочь исследователям лучше понять, изучить и поэкспериментировать с этой уязвимостью как в реальных, так и в образовательных контекстах.
CVE-2025-4275 была первоначально обнаружена и ответственно раскрыта Nikolaj Schlej, а координация осуществлялась через CERT/CC. Официальные источники и материалы сообщества:
CVE-2025-4275, получившая название Hydroph0bia (каламбур на тему Insyde H2O), — это уязвимость обхода Secure Boot, затрагивающая UEFI-совместимую прошивку, построенную на платформе Insyde H2O. Уязвимость проистекает из ошибки проектирования подсистемы обновления прошивки: сертификат подписи, который должен загружаться в энергозависимую переменную NVRAM доверенным драйвером, вместо этого может быть предварительно создан как энергонезависимая переменная атакующим, в результате чего прошивка доверяет произвольному внешнему коду так, как если бы он был подписан самой Insyde.
Особую опасность этой уязвимости придаёт сочетание её простоты и масштаба охвата. Для эксплуатации требуются лишь права локального администратора — достаточные для записи файлов в EFI System Partition и создания переменных NVRAM, — и она затрагивает любую систему с прошивкой Insyde H2O, собранной до 10 июня 2025 года. Атака не зависит от OEM, то есть применима повсеместно к Acer, Dell, Framework, Fujitsu, HP, Huawei, Lenovo и любому другому производителю, поставляющему прошивку на базе Insyde.
UEFI предоставляет абстрактный интерфейс к энергонезависимому хранилищу переменных, известному как NVRAM. Одна давняя особенность этого интерфейса заключается в том, что энергонезависимая переменная с заданным именем и GUID может сосуществовать с энергозависимой переменной с той же идентичностью и затенять её. Если код ожидает энергозависимую переменную (созданную во время выполнения доверенным драйвером), но энергонезависимая с тем же именем уже существует, вместо неё может быть использована энергонезависимая версия. Такое поведение, иногда называемое затенением переменных NVRAM, лежит в основе данной уязвимости.
Подсистема обновления прошивки Insyde H2O полагается на две переменные NVRAM для передачи сертификата подписи между драйверами:
В ожидаемом сценарии обе переменные создаются как энергозависимые драйвером BdsDxe в процессе обновления прошивки. Затем SecurityStubDxe использует их, чтобы убедиться, что isflash.bin подписан сертификатом Insyde, прежде чем разрешить его выполнение. Критическая ошибка заключается в том, что SecurityStubDxe не проверяет, являются ли эти переменные энергозависимыми или энергонезависимыми, прежде чем доверять их содержимому.
Первопричина CVE-2025-4275 заключается в том, что SecurityStubDxe использует обобщённую библиотечную функцию для чтения SecureFlashSetupMode и SecureFlashCertData вместо прямого вызова runtime-сервиса GetVariable. Это означает, что он не может отличить энергозависимую переменную, заданную доверенным BdsDxe, от энергонезависимой, предварительно созданной атакующим (подробное объяснение этой конкретной техники см. в следующем репозитории "TheMalwareGuardian: Exploitation Technique NVRAM Variable Shadowing").
В результате атакующий с правами локального администратора может:
При следующей загрузке SecurityStubDxe обнаружит обе переменные, воспримет их как легитимные и будет доверять любому UEFI-исполняемому файлу, подписанному сертификатом атакующего, фактически полностью обходя Secure Boot. Никакого взаимодействия на уровне прошивки, доступа к оборудованию или эксплуатации примитива повреждения памяти не требуется. Поверхностью атаки является просто интерфейс записи UEFI NVRAM, доступный из привилегированной сессии ОС.
Уязвимость была обнаружена в ходе проверки безопасности HUAWEI MateBook 14 2023, работающего на прошивке на базе Insyde H2O с включёнными Secure Boot, паролем прошивки и другими современными функциями безопасности. Несмотря на эти защиты, полная эксплуатация была достигнута с использованием только прав администратора на уровне ОС.
Начальный этап эксплуатации требует небольшого инструмента для Windows (SFCD), который:
После перезагрузки SecurityStubDxe считывает обе переменные и начинает доверять всему, что подписано сертификатом атакующего. Практической демонстрацией этого первого этапа является загрузка UEFI-драйвера CrScreenshotDxe, подписанного пользовательским сертификатом, который успешно делает снимок экрана BIOS Setup при включённом Secure Boot в качестве доказательства выполнения произвольного кода в среде прошивки.
Важный нюанс: переменная IhisiParamBuffer, присутствующая в CVE-2025-3052, часто заблокирована на платформах на базе Insyde, что затрудняет там прямую эксплуатацию. CVE-2025-4275 не требует, чтобы такая переменная была доступна для записи, и не зависит от какого-либо примитива повреждения памяти. Атака работает на любой системе Insyde H2O, где атакующий может писать в NVRAM, что является поведением по умолчанию на непатченной прошивке.
Ниже описана сквозная атака для начального этапа обхода Secure Boot в предположении привилегированного атакующего с доступом на уровне ОС:
Обход Secure Boot, достигнутый в части 1, открывает дверь к значительно более серьёзному второму этапу: полному захвату DXE-тома, достигаемому путём перехвата самого процесса обновления прошивки Insyde.
Подсистема обновления прошивки в Insyde H2O работает следующим образом: обновляющее приложение ОС размещает капсулу прошивки и подписанное приложение-обновлятор (isflash.bin) в EFI System Partition, затем устанавливает флаг SecureFlashTrigger=1 внутри переменной NVRAM SecureFlashInfo. При следующей загрузке прошивка обнаруживает триггер, отключает защиты от записи во флеш-память на этапе PEI и в конечном итоге вызывает LoadImage для isflash.bin после проверки его по сертификату Insyde — тот самый механизм сертификатов, который CVE-2025-4275 позволяет атакующему подменить.
Для эскалации от обхода Secure Boot к захвату DXE требуются три дополнительных технических шага:
Как только все три условия выполнены, прошивка перезагружается в режим обновления, загружает пользовательский isflash.bin атакующего (подписанный сертификатом атакующего, которому теперь доверяют из-за затенённой SecureFlashCertData) и выполняет его при незащищённой SPI-флеш-памяти. Из этой позиции атакующий может записать произвольное содержимое в DXE-том, устанавливая постоянные драйверы или модифицируя компоненты прошивки так, что это переживает переустановку ОС и большинство средств защиты.
Insyde выпустила исправление в рамках цикла патчей от 10 июня 2025 года. Исправление было проанализировано путём сравнения двух последовательных обновлений BIOS Dell (одного до патча, одного после) с использованием отчётов, сгенерированных UEFITool, и бинарного диффинга через Diaphora.
Изменения были сосредоточены в трёх драйверах:
Исправление эффективно при условии, что атакующий не может обойти VariablePolicy или LibSetSecureVariable. Однако реализация VariablePolicy по умолчанию в EDK2 внутренне использует глобальный флаг, структурно похожий на InsydeVariableLock, побеждённый в части 2. Физическое редактирование NVRAM с помощью аппаратного программатора SPI также полностью обошло бы исправление, хотя физические атаки традиционно выходят за рамки моделей угроз Secure Boot.
Рекомендованное исследователем средство исправления — полное удаление NVRAM из механизма передачи сертификата между BdsDxe и SecurityStubDxe — было опробовано Insyde, но вызвало регрессии и было отложено до будущего инженерного цикла.
Любой производитель, поставляющий прошивку на базе Insyde H2O, собранную до 10 июня 2025 года, потенциально затронут. Подтверждённый статус на момент раскрытия:
| Производитель | Статус |
|---|---|
| Dell | Исправлено — обновления BIOS выпущены вскоре после окончания эмбарго |
| Lenovo | Уязвимо — исправления анонсированы, поставка с 2025-07-30 |
| Framework | Уязвимо — оценка сроков поставки на момент раскрытия не предоставлена |
| Acer | Бюллетень или исправление на момент раскрытия не опубликованы |
| Fujitsu | Бюллетень или исправление на момент раскрытия не опубликованы |
| HP | Бюллетень или исправление на момент раскрытия не опубликованы |
| Huawei | Производитель исходного тестового устройства — статус исправления неизвестен |
Работаете над чем-то похожим? Исследуете UEFI, безопасность ядра, эксплуатацию или другую интересную тему в области безопасности? Если вам нужна помощь в разработке эксплойта, изучении техники или просто хотите обменяться идеями, не стесняйтесь обращаться. Я всегда открыт для обсуждения исследований, помощи, где могу, и сотрудничества по интересным проектам. Свяжитесь со мной в LinkedIn.
