До загрузки ОС: где прячутся уязвимости сервера

Всем привет! На HardFest 2026 я рассказывал о безопасности серверов до загрузки ОС. В этой статье разберем, как устроена предзагрузочная среда, какие уязвимости встречаются в UEFI и BMC и что может сделать производитель оборудования, чтобы снизить риски их эксплуатации.

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

Сразу после включения питания начинается инициализация аппаратных компонентов, процессор выполняет код прошивки, а контроллер BMC обеспечивает управление платформой. Все это происходит до того, как операционная система получает контроль над оборудованием. При этом ошибки во встроенном ПО могут привести к последствиям, с которыми привычные средства защиты ОС уже не справятся.

Что находится между аппаратным обеспечением и операционной системой

Для начала посмотрим на устройство серверной платформы. В рамках нашего подхода к разработке ее удобно разделить на три основных домена, каждый из которых выполняет собственные задачи и имеет свои особенности с точки зрения безопасности.

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

Второй домен отвечает за управление и мониторинг. Его центральный компонент, Baseboard Management Controller (BMC), фактически является отдельным компьютером внутри сервера. У него есть собственный процессор, память, встроенное ПО и интерфейсы взаимодействия с оборудованием.

BMC собирает показания датчиков, контролирует состояние системы, позволяет удаленно управлять питанием и получать доступ к консоли сервера. Причем для выполнения многих из этих функций ему не требуется работающая операционная система хоста. Администратор может взаимодействовать с BMC даже тогда, когда основной сервер выключен или не способен загрузиться.

Такая автономность полезна при эксплуатации, но требует особого внимания к безопасности. Контроллер имеет доступ к ряду аппаратных компонентов и служебных интерфейсов, поэтому его компрометация потенциально дает злоумышленнику возможности, выходящие за рамки обычного доступа к ОС.

Наконец, третий домен объединяет компоненты хранения прошивок и аппаратные механизмы доверия. Сюда можно отнести SPI-flash, в которой находится образ UEFI, модули TPM, а также компоненты, управляющие последовательностью включения и проверками целостности встроенного ПО.

На практике эти домены тесно связаны друг с другом. Для мониторинга, управления и обмена служебной информацией используется множество аппаратных и программных интерфейсов. Причем их количество и назначение зависят от архитектуры конкретной платформы.

Для разработчика прошивки это означает, что недостаточно рассматривать безопасность каждого компонента по отдельности. Нужно учитывать и способы их взаимодействия. Например, если BMC имеет аппаратный доступ к памяти, в которой хранится прошивка хост-системы, необходимо предусмотреть ограничения на операции с этой памятью. Иначе уязвимость в контроллере управления может затронуть уже не только сам BMC, но и процесс загрузки основного сервера.

Что происходит с сервером до загрузки ОС

Теперь проследим, как сервер проходит путь от подачи питания до запуска операционной системы. В современных x86-системах для этого используется UEFI. Его нередко продолжают называть BIOS, хотя технически это разные поколения системного встроенного ПО. В отличие от Legacy BIOS, современная архитектура UEFI более подробно стандартизирована, а процесс инициализации платформы разделен на несколько последовательных фаз.

Все начинается с SEC. На этом этапе процессор только приступает к выполнению кода, а полноценная оперативная память еще недоступна. Система подготавливает временную область для хранения данных, в частности может использоваться процессорный кэш в режиме Cache-as-RAM. На ранних этапах запуска также выполняются необходимые операции, связанные с микрокодом процессора.

После этого управление переходит к PEI (Pre-EFI Initialization). Здесь начинается инициализация основных компонентов платформы, прежде всего оперативной памяти. В зависимости от архитектуры используются компоненты, предоставляемые производителями процессоров. Для Intel это, в частности, Firmware Support Package (FSP), для AMD — AGESA.

Когда оперативная память становится доступна, начинается фаза DXE (Driver Execution Environment). На этом этапе запускаются драйверы UEFI, инициализируются дополнительные устройства и необходимые системные службы. Прошивка получает возможность взаимодействовать с большей частью аппаратного обеспечения, подготавливает загрузочное окружение и ряд механизмов безопасности.

Следующая фаза, BDS (Boot Device Selection), отвечает за выбор дальнейшего сценария. В зависимости от конфигурации сервер может запустить загрузчик ОС, выполнить сетевую загрузку, открыть интерфейс настройки или перейти в командную оболочку UEFI Shell. После выбора загрузчика управление передается следующему компоненту загрузочной цепочки.

Особый интерес с точки зрения безопасности представляют DXE и BDS. К этому моменту система уже способна выполнять достаточно сложный программный код, но привычные механизмы защиты операционной системы еще не работают. Поэтому ошибка в драйвере или служебном компоненте прошивки может оказаться значительно опаснее, чем кажется на первый взгляд.

Есть и еще одна особенность. Часть низкоуровневого кода продолжает выполнять свои функции после передачи управления ОС. Хороший пример здесь — System Management Mode (SMM).

SMM представляет собой привилегированный режим процессора, предназначенный для выполнения определенных системных операций. Обработчики системных прерываний SMI работают с изолированной областью памяти SMRAM, которая недоступна обычному программному обеспечению.

Пока все работает корректно, такая изоляция позволяет выполнять служебные функции независимо от операционной системы. Однако уязвимости в обработчиках SMI могут нарушить эту границу. А поскольку код SMM выполняется с высокими привилегиями, последствия его компрометации способны затронуть всю платформу.

Именно поэтому при анализе защищенности сервера важно смотреть не только на загрузчик и настройки Secure Boot, но и на реализацию других компонентов UEFI.

Почему Secure Boot не гарантирует безопасную загрузку

Secure Boot предназначен для проверки подлинности компонентов загрузочной цепочки. Он использует цифровые подписи и настроенную политику доверия, чтобы препятствовать выполнению неподписанного или недоверенного EFI-кода.

Механизм действительно позволяет снизить риск запуска вредоносных загрузчиков. Однако его возможности ограничены областью, за которую он отвечает. Secure Boot не проверяет абсолютно весь код серверной платформы и не гарантирует, что в компонентах самой прошивки отсутствуют уязвимости.

Причем проблема может заключаться не в механизме проверки подписей, а в другом компоненте, который способен повлиять на его работу.

Cisco UCS: обход Secure Boot через UEFI Shell

В сентябре 2026 года Cisco раскрыла уязвимость CVE-2026-20293, получившую оценку 7,1 по CVSS.

Проблема была обнаружена в реализации UEFI Shell на затронутых устройствах Cisco UCS. Эта командная оболочка предназначена для диагностики и выполнения служебных операций в предзагрузочной среде. В частности, она может предоставлять инструменты для работы с памятью и конфигурацией системы.

Исследователи установили, что даже при включенном Secure Boot оставались доступны команды, позволяющие изменять содержимое памяти. При наличии соответствующего доступа злоумышленник мог вмешаться в значения, связанные с проверками Secure Boot, и добиться выполнения неавторизованного кода.

Для эксплуатации требовались определенные условия: действующие учетные данные с доступом к соответствующему функционалу либо физический доступ к устройству.

Интересно здесь то, что атакующему не требовалось взламывать криптографический алгоритм или подделывать цифровую подпись. Достаточно было воспользоваться возможностями другого компонента UEFI, которому предоставили слишком широкие полномочия.

Cisco выпустила исправления, ограничивающие доступность соответствующих команд при активном Secure Boot.

GIGABYTE: уязвимости в обработчиках SMM

Другой пример связан с уязвимостями CVE-2025-7026–7029, информация о которых появилась летом 2025 года.

Исследователи Binarly обнаружили проблемы в модулях UEFI, используемых на ряде материнских плат GIGABYTE. Ошибки заключались в недостаточной проверке указателей, регистров и данных, передаваемых обработчикам SMI.

При определенных условиях атакующий с необходимыми привилегиями мог получить доступ к области SMRAM и возможность выполнения произвольного кода в режиме SMM.

Это уже принципиально другой сценарий, чем в случае Cisco. Здесь атакующий воздействует на низкоуровневый режим процессора, работающий вне обычной модели защиты операционной системы. При успешной эксплуатации такие уязвимости потенциально позволяют вмешиваться в работу других защитных механизмов платформы.

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

Эти два примера демонстрируют разные способы компрометации предзагрузочной среды. В первом случае использовались избыточные возможности командной оболочки UEFI, во втором — ошибки в высокопривилегированном системном коде.

И это лишь часть возможных сценариев.

Какие еще компоненты могут стать точкой входа

Когда наша команда начала систематизировать известные способы атак на встроенное ПО, стало понятно, что потенциальные проблемы не ограничиваются UEFI Shell и SMM.

Одно из направлений связано с SPI-flash, в которой хранится прошивка. Если защита записи настроена некорректно, злоумышленник с необходимыми привилегиями может изменить содержимое памяти и внедрить посторонний код. В таком случае переустановка операционной системы или замена системного диска не обязательно устранят компрометацию, поскольку вредоносный компонент находится непосредственно в прошивке.

Другой возможный путь проходит через BMC. Мы уже говорили, что контроллер управления взаимодействует со многими компонентами серверной платы. На платформах, где ему предоставлены соответствующие полномочия, атака на BMC может позволить воздействовать на прошивку хост-системы.

Отдельно стоит учитывать физический доступ к оборудованию. Например, при отсутствии достаточных аппаратных ограничений содержимое SPI-flash можно изменить с помощью внешнего программатора. Защита на уровне операционной системы в этом случае не имеет значения, поскольку взаимодействие происходит непосредственно с микросхемой памяти.

Наконец, существует категория рисков, связанная с закрытыми компонентами производителей процессоров. Ошибки могут обнаруживаться в микрокоде или программных блоках ранней инициализации платформы. Сложность таких случаев заключается в том, что производитель сервера не всегда способен самостоятельно исправить проблемный компонент.

Конечно, наличие того или иного интерфейса еще не означает, что через него можно атаковать сервер. Возможность эксплуатации зависит от архитектуры платы, конфигурации прошивки, аппаратных ограничений и прав доступа. Но именно эти особенности необходимо учитывать при разработке механизмов защиты.

Как выстраивается цепочка доверия

Один из подходов к защите ранних этапов запуска основан на концепции Root of Trust (RoT), или корня доверия.

Ее смысл заключается в последовательной проверке компонентов, участвующих в загрузке сервера. При этом отправной точкой становится небольшой аппаратный или программный компонент, которому система может доверять.

В одной из возможных реализаций такую роль выполняет отдельная CPLD или FPGA с защищенным кодом. При подаче питания этот компонент начинает работу раньше основных вычислительных узлов и удерживает BMC и хост-систему в состоянии сброса, пока не будут выполнены предусмотренные проверки.

Сначала может проверяться целостность и подлинность прошивки BMC. Если проверка проходит успешно, контроллеру разрешается продолжить загрузку. Затем аналогичная процедура выполняется для соответствующих областей прошивки хост-системы, после чего разрешается запуск центрального процессора.

Далее в процесс включаются механизмы, предусмотренные архитектурой самого процессора. В случае Intel это, в частности, Boot Guard, который используется для проверки начальных компонентов BIOS. На платформах AMD соответствующие функции реализуются с участием Platform Security Processor (PSP) и механизмов Platform Secure Boot.

На последующих этапах начинают работать средства UEFI, включая Secure Boot.

Таким образом, доверие к последующему компоненту опирается на результаты проверок, проведенных раньше. Однако и у этой архитектуры есть свои ограничения.

Цифровая подпись позволяет проверить происхождение и целостность кода, но сама по себе ничего не говорит об отсутствии ошибок в его реализации. Подписанный драйвер по-прежнему может содержать уязвимость, а корректно загруженная прошивка BMC не исключает проблем в ее сетевых службах.

Поэтому при проектировании защищенной платформы необходимо предусматривать не только предотвращение несанкционированных изменений, но и обнаружение нарушений, а также возможность восстановления прошивки.

Такой подход описан в рекомендациях NIST SP 800-193, где выделяются три взаимосвязанные задачи: Protect, Detect и Recover.

Что делать с кодом, который мы не разрабатываем

Вернемся к ранним этапам инициализации сервера. При работе с x86-платформами значительная часть необходимой функциональности поставляется непосредственно производителями процессоров.

Речь идет прежде всего о микрокоде, Intel FSP и AMD AGESA. Эти компоненты обеспечивают работу с процессором, памятью и другими аппаратными узлами, но их внутренняя реализация в значительной степени закрыта для производителя серверного оборудования.

Это создает определенную зависимость. Если уязвимость обнаруживается внутри такого компонента, мы обычно не можем просто открыть исходный код и внести исправление. Необходимо получить новую версию от Intel или AMD, интегрировать ее в собственную сборку UEFI и проверить работу на конкретной серверной платформе.

При этом обновление не всегда проходит гладко.

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

Поэтому мы разделяем две зоны ответственности. За исправление ошибки внутри закрытого компонента отвечает его разработчик. А вот правильная интеграция обновления, настройка параметров и проверка совместимости уже находятся на стороне производителя сервера.

Хороший пример сложности работы с микрокодом представляет уязвимость CVE-2024-36347, связанная с исследованием EntrySign. Исследователи обнаружили недостатки проверки подписи микрокода в процессорах AMD, которые при наличии необходимых привилегий могли позволить загрузку неподписанного производителем микрокода.

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

Подобные случаи хорошо показывают, почему сопровождение UEFI не заканчивается после выпуска сервера. Даже если собственный код производителя не содержит обнаруженной уязвимости, ему все равно необходимо интегрировать исправления сторонних компонентов и обеспечить их корректную работу.

Как мы подходим к разработке UEFI в OpenYard

С развитием серверных платформ объем работы со встроенным ПО постоянно увеличивается. Новые поколения процессоров требуют адаптации ранней инициализации, поддержки новых аппаратных компонентов и проверки их взаимодействия.

При этом далеко не весь код приходится разрабатывать заново.

В OpenYard мы разделяем компоненты UEFI по степени их зависимости от аппаратной платформы. Наиболее существенные изменения обычно приходятся на SEC и PEI, поскольку именно здесь используются специфичные для поколения процессора средства инициализации.

Значительную часть собственного кода DXE и BDS, напротив, удается переносить между проектами. Разумеется, отдельные функции, драйверы и настройки приходится адаптировать, но общая архитектура остается достаточно стабильной.

За последние годы мы структурировали работу с UEFI таким образом, чтобы сократить объем повторной разработки. Если раньше переход между поколениями серверных платформ мог занимать около года, то сейчас в отдельных проектах адаптация занимает порядка полутора-двух месяцев.

Сокращение сроков важно не только с точки зрения вывода нового оборудования. Единые подходы к разработке упрощают сопровождение прошивок, проверку изменений и перенос исправлений между платформами.

Отдельное направление нашей работы связано с дополнительным контролем загрузочного окружения.

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

Вопрос об этом возник и после моего выступления на HardFest. Один из участников спросил, можно ли перенести часть функций аппаратных средств доверенной загрузки непосредственно в UEFI.

Мы действительно работаем в этом направлении. В частности, используем эвристические алгоритмы для проверки подлинности загрузочных компонентов. Если система обнаруживает признаки подмены, загрузка блокируется, а информация о событии передается администратору через BMC.

По своему назначению такие проверки близки к отдельным функциям средств доверенной загрузки, но реализуются средствами встроенного ПО. При этом речь не идет о полном воспроизведении возможностей аппаратных модулей или замене всех существующих механизмов защиты.

Для нас принципиально важно, что дополнительные проверки выполняются на стороне самой серверной платформы, еще до передачи управления операционной системе. Это позволяет контролировать определенные нарушения непосредственно в процессе запуска оборудования.

Конечно, подобные механизмы тоже требуют сопровождения и развития. По мере появления новых способов атак приходится анализировать их применимость к нашим платформам и при необходимости дорабатывать встроенное ПО.

Вместо заключения

Развитие UEFI сделало архитектуру серверных платформ значительно более гибкой. Появились стандартизированные интерфейсы, расширенные возможности взаимодействия с оборудованием и инструменты для управления процессом загрузки. Вместе с ними увеличилось и количество компонентов, безопасность которых приходится учитывать.

При этом задача производителя сервера не ограничивается разработкой собственной прошивки. Значительная часть работы связана с интеграцией стороннего кода, проверкой обновлений и сопровождением оборудования на протяжении всего срока эксплуатации.

Именно здесь особенно важен системный подход. Механизмы защиты должны учитывать особенности аппаратной платформы, работу встроенного ПО и возможные способы воздействия на загрузочный процесс. А их эффективность необходимо поддерживать по мере появления новых уязвимостей.

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