CVE-2025-3052 — Updated!
Исследование CVE-2025-3052 — уязвимости прошивки Insyde, которая предоставляет примитив произвольной записи, способный изменять критически важные для безопасности указатели.
🐞 CVE-2025-3052: Повреждение памяти в IhisiParamBuffer
Этот репозиторий объединяет исследовательские материалы, связанные с CVE-2025-3052 — уязвимостью повреждения памяти в модуле UEFI, подписанном сторонним сертификатом Microsoft, которая позволяет атакующему повредить критичные для безопасности структуры прошивки, нейтрализовать проверки Secure Boot и выполнить произвольный неподписанный код до загрузки операционной системы. Он включает технический анализ первопричины и техники эксплуатации, реальные и учебные уязвимые бинарные файлы, а также сопроводительную документацию, призванную помочь исследователям понять, воспроизвести и поэкспериментировать с этим классом уязвимостей.
📑 Содержание
- Первоначальное обнаружение и официальные источники
- Уязвимые бинарные файлы (реальные / учебные)
- Обзор уязвимости (анализ, эксплуатация, PoC)
🧠 Первоначальное обнаружение и официальные источники
CVE-2025-3052 была изначально обнаружена и ответственно раскрыта исследовательской командой Binarly. Официальные источники и материалы сообщества:
- Блог Binarly Research (10 июня 2025 г.)
- Коллекция материалов сообщества
🐜 Уязвимые бинарные файлы
Этот репозиторий включает два уязвимых бинарных файла, предоставленных с разными целями для исследований и обучения.
🧨 Реальный уязвимый бинарный файл
Этот бинарный файл представляет уязвимость в том виде, в каком она существовала в реальных условиях.
- Оригинальное уязвимое UEFI-приложение, затронутое CVE-2025-3052.
- Предназначен для реального анализа и обратной разработки.
- Подписан сторонним UEFI-сертификатом Microsoft.
- Извлечён из публичных репозиториев вредоносного ПО:
🎓 Учебный уязвимый бинарный файл
- Полностью компилируемый исходный код упрощённого учебного UEFI-приложения.
- Воспроизводит ту же предпосылку уязвимости, что и реальный бинарный файл.
- Разработан, чтобы помочь начинающим:
- Постепенно перейти к анализу оригинального бинарного файла.
- Избежать сложной обратной разработки на ранних этапах.
- Понять механику уязвимости.
🧪 Обзор уязвимости (анализ, эксплуатация, PoC)
CVE-2025-3052 — это уязвимость обхода Secure Boot, затрагивающая UEFI-системы, вызванная небезопасной обработкой данных, получаемых из переменной NVRAM внутри подписанного UEFI-приложения. Уязвимость позволяет атакующему повредить критичные для безопасности структуры прошивки во время процесса загрузки, фактически нарушая цепочку доверия UEFI и позволяя выполнить неподписанный код до загрузки операционной системы.
Особую значимость этой уязвимости придаёт не только природа самой ошибки — примитив повреждения памяти, — но и контекст, в котором она существует: модуль UEFI, подписанный сторонним UEFI-сертификатом Microsoft, которому по умолчанию доверяет подавляющее большинство современных систем. В результате эксплуатация происходит на одном из самых ранних и наиболее привилегированных этапов выполнения платформы, до появления средств защиты на уровне ОС.
🔐 Secure Boot и сертификаты Microsoft
Secure Boot — это ключевая функция безопасности UEFI, предназначенная для обеспечения цепочки доверия платформы от прошивки до операционной системы. Её основная цель — предотвратить выполнение несанкционированных или вредоносных загрузочных компонентов, таких как буткиты, во время процесса загрузки.
На высоком уровне Secure Boot работает путём криптографической проверки UEFI-исполняемых файлов перед тем, как разрешить их выполнение. Эта проверка выполняется с использованием двух баз данных, поддерживаемых прошивкой:
- db: содержит доверенные хеши Authenticode и доверенные корневые сертификаты.
- dbx: содержит отозванные или явно недоверенные хеши и сертификаты.
UEFI-приложение может быть выполнено, если выполняется любое из условий:
- Его хеш Authenticode совпадает с записью в db, или
- Его цепочка сертификатов проверяется до доверенного корневого сертификата, присутствующего в db, и отсутствует в dbx.
По умолчанию большинство систем поставляются со следующими сертификатами, которым доверяют в db:
- Microsoft Corporation UEFI CA 2011 — используется для подписи сторонних UEFI-компонентов, включая Linux shim.
- Microsoft Windows Production PCA 2011 — используется для подписи загрузчика Windows.
- Один или несколько сертификатов, принадлежащих OEM.
Уязвимые модули, связанные с CVE-2025-3052, были подписаны с использованием сертификата Microsoft Corporation UEFI CA 2011. Поскольку этому сертификату широко доверяют у разных производителей и на разных платформах, любое подписанное им приложение может выполняться на большинстве UEFI-систем без взаимодействия с пользователем. Это широкое доверие значительно усиливает влияние уязвимости в таком модуле, поскольку фактически обходит предполагаемые гарантии защиты Secure Boot.
🔎 Обнаружение модуля и разведка
Уязвимый UEFI-модуль был первоначально обнаружен в ходе крупномасштабного анализа UEFI-бинарных файлов, загруженных в публичные репозитории вредоносного ПО, в первую очередь в VirusTotal. Хотя первая публичная загрузка модуля произошла в ноябре 2024 года, проверка его подписи Authenticode показала, что он был подписан ещё в октябре 2022 года, что указывает на то, что бинарный файл мог циркулировать в течение значительного времени до обнаружения.
Исходное имя файла, наблюдавшееся во время анализа, было Dtbios-efi64-71.22.efi. Изучение встроенных строк, метаданных сертификата и поведения файла убедительно указывало на то, что модуль был разработан компанией DT Research, Inc, производителем, специализирующимся на защищённых мобильных вычислительных устройствах.
Дальнейшая обратная разработка показала, что модуль представляет собой утилиту прошивки BIOS, предназначенную для чтения образа прошивки с диска и записи его в ROM системы. Хотя изначально он предназначался для оборудования DT Research, модуль не ограничен конкретной платформой и может выполняться на любой системе, доверяющей стороннему UEFI-сертификату Microsoft.
Критической подсказкой во время разведки стало наличие переменной NVRAM IhisiParamBuffer. Эта переменная тесно связана с реализациями прошивок на базе Insyde и ранее была задействована в других уязвимостях, раскрытых Binarly (например, BRLY-2022-023 и BRLY-2023-005). Её наличие сразу указывало на потенциальный класс проблем, связанных с NVRAM.
💥 Поиск и эксплуатация уязвимости
Первопричина CVE-2025-3052 заключается в небезопасном использовании данных, считанных из переменной NVRAM, без проверки. В частности:
- UEFI-приложение извлекает значение переменной NVRAM IhisiParamBuffer.
- Это значение рассматривается как доверенный указатель и сохраняется в глобальной переменной по адресу 0xf7a0.
- Затем код выполняет операцию записи в память по адресу global + 0x18, устанавливая этот адрес в ноль.
- Далее следуют дополнительные операции записи, все производные от одного и того же контролируемого атакующим значения NVRAM.
- Никакой проверки границ, валидации корректности или контроля доступа ни на одном этапе не применяется.
В результате атакующий, способный контролировать переменную IhisiParamBuffer, получает возможность влиять на то, где в памяти происходят эти записи. Хотя примитив записи несколько ограничен — обычно позволяя записывать ноль или небольшие константы по произвольному адресу, — он всё же достаточно мощный, чтобы повредить критичное состояние прошивки.
В proof of concept от Binarly атака нацелена на глобальную переменную gSecurity2, которая хранит указатель на Security2 Architectural Protocol (подробное объяснение этой конкретной техники эксплуатации см. в следующем репозитории "TheMalwareGuardian: Exploitation Technique SecureBoot Bypass gSecurity2 Corruption"). Этот протокол используется сервисом LoadImage для обеспечения политики Secure Boot, а значит, перезапись gSecurity2 нулевым указателем фактически отключает проверки Secure Boot во время выполнения. Что крайне важно, этот обход прозрачен для операционной системы: после загрузки Secure Boot по-прежнему отображается как включённый на уровне ОС, хотя он полностью нейтрализован на уровне прошивки.
Важный нюанс заключается в том, что на платформах на базе Insyde переменная IhisiParamBuffer обычно заблокирована как доступная только для чтения, что фактически предотвращает эксплуатацию на таких системах без дополнительной уязвимости. По иронии судьбы это означает, что производитель, чей IBV изначально внедрил уязвимый шаблон переменной, оказывается среди наименее подверженных риску, тогда как все остальные платформы остаются уязвимыми. В случаях, когда переменная заблокирована, для получения доступа на запись к переменной перед продолжением эксплуатации можно сцепить обход, такой как BRLY-2023-005. На системах, где переменная доступна для прямой записи, атака проста и высоконадёжна.
🎯 Сценарий атаки
Ниже описан сквозной сценарий атаки с использованием CVE-2025-3052 при условии наличия привилегированного атакующего с доступом на уровне ОС:
- Установка переменной NVRAM: Атакующий устанавливает переменную NVRAM IhisiParamBuffer из операционной системы в произвольный целевой адрес, указывая её на gSecurity2.
- Регистрация полезной нагрузки: Атакующий регистрирует уязвимый подписанный модуль в UEFI Boot Manager (или заменяет им существующий загрузчик ОС), а также дополнительно регистрирует второй неподписанный модуль, содержащий фактическую полезную нагрузку.
- Перезагрузка: После перезагрузки системы прошивка входит в фазу Boot Device Selection (BDS) и начинает выполнять зарегистрированные загрузочные записи.
- Выполнение: Уязвимый подписанный модуль запускается первым. Его ограниченный примитив записи используется для перезаписи gSecurity2 нулём, отключая обеспечение Secure Boot. После нейтрализации проверок прошивка переходит к загрузке и выполнению неподписанного модуля полезной нагрузки, предоставляя атакующему выполнение произвольного кода в конце фазы DXE, прежде чем операционная система получит возможность установить собственную защиту.
📦 Затронутые модули
Microsoft определила, что были затронуты 14 различных UEFI-модулей, и устранила проблему, добавив их хеши в Secure Boot dbx.
| Имя модуля | Хеш Authenticode SHA-256 |
|---|---|
| BiosFlashShell-efi64-80.02.efi | C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417BA1B5528E95 |
| BiosFlashShell-efi64-81.02.efi | CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6EBA29A369ADDF |
| Dtbios-efi64-70.17.efi | 9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC14893882D74618 |
| Dtbios-efi64-70.18.efi | 9B1F35052CFC5FB06DABE5E8F7B747F081DA28D722DB59ADE253B9E38A7A3C76 |
| Dtbios-efi64-70.19.efi | E3CE55E584371D3F2FBCA2241EF0711FF80876EBF71BAB07D8ECEE645A40DCFC |
| Dtbios-efi64-70.20.efi | EE093913ABBD34CB8B5EA31375179A8B55A298353C03AFE5055AA4E8E3F705EF |
| Dtbios-efi64-70.21.efi | B4E1880425F7857B741B921D04FD9276130927CF90A427C454B970E7A2F442F9 |
| Dtbios-efi64-70.22.efi | CDA0B4A59390B36E1B654850428CBB5B4C7B5E4349E87ACDE97FB543736FF1D4 |
| Dtbios-efi64-71.17.efi | C87EFD057497F90321D62A69B311912B8EF8A045FE9C5E6BD5C8C1A4E6F39629 |
| Dtbios-efi64-71.18.efi | 9E19DD645235341A555D6AC0665591453AE13918ECD37DF22DFBEE91EAA9A2DA |
| Dtbios-efi64-71.19.efi | 63F67824FDA998798964FF33B87441857DA92F3A8EE3E04166EEC3156E4E6B82 |
| Dtbios-efi64-71.20.efi | 0BC4F078388D41AB039F87AE84CF8D39302CCBDD70C4ADEE02263EBF6A2DD328 |
| Dtbios-efi64-71.21.efi | E2AEC271B9596A461EB6D54DB81785E4E4C615CFDA5F4504BCC0A329248A4D36 |
| Dtbios-efi64-71.22.efi | 6B4328EBCBE46ED9118FF2D4472DE329D70BA83016DF7A6F50F8AF92342160A1 |
🤝 Исследования и сотрудничество
Работаете над чем-то похожим? Исследуете UEFI, безопасность ядра, эксплуатацию или другую интересную тему в области безопасности? Если вам нужна помощь в разработке эксплойта, изучении техники или просто хотите обменяться идеями, не стесняйтесь обращаться. Я всегда открыт для обсуждения исследований, помощи, где могу, и сотрудничества по интересным проектам. Свяжитесь со мной в LinkedIn.