До загрузки ОС: где прячутся уязвимости сервера
Безопасность серверной инфраструктуры обычно связывают с операционной системой, разграничением доступа, межсетевыми экранами и средствами защиты информации. Однако до того, как ОС получит управление оборудованием, сервер уже успевает выполнить множество операций. После включения питания запускается код прошивки, инициализируются аппаратные компоненты, а контроллер удаленного управления BMC начинает работу независимо от состояния основной системы.
Ошибки на этом уровне особенно опасны: привычные механизмы защиты ОС еще не работают и не всегда способны повлиять на происходящее в предзагрузочной среде. Компрометация встроенного ПО может сохраняться после переустановки системы и затрагивать сам процесс запуска платформы.
Три домена серверной платформы
Серверную платформу удобно рассматривать как сочетание трех связанных доменов. Первый — хост-система: процессоры, оперативная память, сетевые адаптеры, контроллеры и другие устройства, на которых запускаются ОС и приложения.
Второй домен отвечает за управление и мониторинг. Его ключевой компонент — Baseboard Management Controller, или BMC. По сути, это отдельный компьютер со своим процессором, памятью, прошивкой и интерфейсами. BMC собирает показания датчиков, управляет питанием и предоставляет удаленный доступ к консоли. Для этого ему не требуется работающая ОС хоста: контроллер может функционировать даже при выключенном или неисправном основном сервере.
Такая автономность удобна для администрирования, но расширяет последствия возможной атаки. Если BMC получает доступ к служебным интерфейсам или памяти хост-системы, его компрометация может затронуть не только сам контроллер, но и загрузку сервера.
Третий домен объединяет хранилища прошивок и аппаратные механизмы доверия. К нему относятся SPI-flash с образом UEFI, модули TPM, а также компоненты, отвечающие за порядок включения и проверку целостности встроенного ПО. Безопасность здесь определяется не только защитой отдельных компонентов, но и тем, как они взаимодействуют между собой.
Что происходит до запуска ОС
В современных x86-системах загрузка строится на архитектуре UEFI. Ее этапы разделены на несколько фаз. Сначала выполняется SEC: процессор начинает исполнять код, подготавливается временная область памяти, например Cache-as-RAM, и выполняются операции, связанные с микрокодом.
Затем наступает этап PEI, на котором инициализируются основные компоненты платформы, прежде всего оперативная память. В этой части могут использоваться технологии производителей процессоров — Firmware Support Package для Intel и AGESA для AMD.
После доступности оперативной памяти начинается DXE. Прошивка запускает драйверы UEFI, подключает дополнительные устройства и подготавливает службы, необходимые для дальнейшей загрузки. Далее фаза BDS выбирает сценарий запуска: загрузку ОС, сетевую загрузку, интерфейс настройки или UEFI Shell.
Наиболее критичны с точки зрения безопасности DXE и BDS. В этот момент система уже способна выполнять сложный код, но защиты ОС еще нет. Дополнительный риск связан с System Management Mode. Обработчики SMI работают в привилегированном режиме и используют изолированную область SMRAM. Ошибка в таком коде может нарушить границу изоляции и дать возможность воздействовать на всю платформу.
Почему Secure Boot не решает проблему полностью
Secure Boot проверяет цифровые подписи компонентов загрузочной цепочки и не позволяет запускать неподписанный или недоверенный EFI-код. Это снижает риск подмены загрузчика, но механизм отвечает только за определенную часть процесса. Он не проверяет весь код платформы и не гарантирует отсутствие уязвимостей в самой прошивке.
Показательный пример — уязвимость CVE-2026-20293, раскрытая Cisco в сентябре 2026 года и получившая оценку 7,1 по CVSS. Проблема находилась в реализации UEFI Shell на затронутых устройствах Cisco UCS. Даже при активном Secure Boot сохранялись команды, позволявшие изменять содержимое памяти. При наличии нужных прав или физического доступа к устройству атакующий мог повлиять на значения, связанные с проверками Secure Boot, и добиться выполнения неавторизованного кода. Для устранения проблемы Cisco ограничила доступность соответствующих команд.
Другой сценарий связан с уязвимостями CVE-2025-7026–7029, обнаруженными исследователями Binarly в модулях UEFI ряда материнских плат GIGABYTE. Недостаточная проверка указателей, регистров и входных данных в обработчиках SMI при определенных условиях могла привести к доступу к SMRAM и выполнению произвольного кода в режиме SMM. Эти проблемы относились к потребительским платам, а не к серверному оборудованию, но демонстрируют общий риск для платформ, использующих такие механизмы.
Другие точки атаки
Угроза может исходить не только от UEFI Shell или SMM. Если защита записи SPI-flash настроена неправильно, злоумышленник с необходимыми привилегиями способен изменить образ прошивки и внедрить посторонний код. В этом случае переустановка ОС или замена диска не устраняет причину компрометации.
Отдельный вектор связан с BMC. В зависимости от архитектуры платы и выданных полномочий атака на контроллер может позволить воздействовать на прошивку хост-системы. При физическом доступе к серверу возможна и прямая модификация SPI-flash внешним программатором — на уровне ОС такая операция не контролируется.
Наконец, риски могут находиться в закрытых компонентах производителей процессоров, включая микрокод и блоки ранней инициализации. Исправление подобных проблем не всегда зависит от производителя сервера. При этом само наличие интерфейса еще не означает возможность атаки: решающими остаются конкретная архитектура, конфигурация прошивки, аппаратные ограничения и права доступа.
Как строится цепочка доверия
Для защиты ранних этапов загрузки применяется концепция Root of Trust, или корня доверия. Она предполагает последовательную проверку компонентов, начиная с небольшого аппаратного или программного элемента, которому система доверяет изначально.
Возможный вариант — отдельная CPLD или FPGA с защищенным кодом. После подачи питания она удерживает BMC и хост-систему в сбросе, пока не завершатся проверки. Сначала подтверждаются целостность и подлинность прошивки BMC, затем проверяются области прошивки хост-системы, после чего разрешается запуск центрального процессора.
Дальше подключаются механизмы безопасности самого процессора: Intel Boot Guard для проверки начальных компонентов BIOS, а на платформах AMD — Platform Security Processor и Platform Secure Boot. На следующих этапах начинают работать средства UEFI, включая Secure Boot. Такая схема формирует последовательную цепь доверия от аппаратного корня до загрузчика ОС.
Но цифровая подпись подтверждает происхождение и целостность кода, а не отсутствие ошибок в его реализации. Подписанный драйвер может содержать уязвимость, как и корректно загруженная прошивка BMC. Поэтому защита сервера до запуска ОС требует анализа всей платформы: UEFI, SMM, BMC, SPI-flash, аппаратных ограничений и связей между ними.
