Несанкционированная модификация кода BIOS, записанного в постоянное запоминающее устройство, стала очевидной с появлением вируса CIH. Около двадцати лет назад воздействие зловредного софта носило только деструктивный характер: результатом работы вируса было разрушение содержимого Flash ROM и, как следствие, — полный вывод из строя аппаратной платформы. Тонкие «хирургические» сценарии внедрения постороннего кода, сохраняющие базовую работоспособность атакуемой системы, упирались в унификацию внутренней структуры Legacy BIOS. Решение такой задачи представлялось весьма трудоемким и требовало учета индивидуальных особенностей каждой платформы.
Пришедший на смену Legacy BIOS интерфейс UEFI, само название которого предполагает унификацию и расширяемость firmware, кардинально изменил подходы к разработке не только полезного, но и вредоносного кода и, конечно, методов защиты. Вернее, ключевую роль в рассматриваемом контексте играет не сама спецификация UEFI, определяющая интерфейс firmware и ОС, а стандарт, называемый UEFI Platform Initialization Specification, декларирующий внутреннюю организацию firmware, взаимодействие и формат хранения его модулей.
Secure Boot: пост «номер один»
Старт любой вычислительной системы от аппаратного сброса до загрузки ОС, можно представить как последовательность запуска программных модулей, выполняющих инициализацию различных аппаратных ресурсов.

Этот факт — в основе Secure Boot. Любой модуль, передающий управление по цепочке доверия (chain of trust), обязан проверить валидность того, кому он передает управление. В частности, на одном из этапов выполнения POST стартовый код UEFI верифицирует целостность загрузчика операционной системы, а также, что немаловажно, UEFI-драйверов, хранящихся в ПЗУ плат расширения. Как нетрудно заметить, достоверность UEFI платформы на данном этапе загрузки принимается как аксиома. Несоблюдение этого условия, в частности, модификация содержимого SPI ROM вредоносным приложением, выполненным в сеансе легально загруженной ОС, разрушает всю концепцию такой защиты — Secure Boot в этом случае становится легкой добычей злоумышленника.
Классификация защитных механизмов
Механизмы аппаратного противодействия злонамеренной «перешивке» UEFI можно разделить на:
- реализованные в составе микросхем SPI ROM;
- реализованные в составе системной логики.
Гибкость и динамическое реконфигурирование в реализации каждого из этих механизмов далеко не всегда идут на пользу безопасности. Если для ее инициализации требуется настроить десятки регистров, то вступает в действие человеческий фактор — всегда существует риск, что разработчики программного обеспечения UEFI по недосмотру что-то неправильно сделают. В отличие от «жесткой логики», за которую в ответе только разработчики аппаратного обеспечения.
Увы, ситуация при которой функциональность реализована аппаратно, но при этом не инициализирована (или неверно инициализирована) программно, встречается довольно часто, а потому оценка безопасности платформы исключительно на основании модели системной логики и микросхемы SPI, без учета особенностей UEFI, является опасным заблуждением. С учетом сказанного, своевременное обновление прошивки и контроль установок CMOS Setup, приобретают особую важность.
Атака в сеансе ОС
Как известно, регистры контроллера SPI, управляющие чтением и записью содержимого UEFI ROM, расположены в пространстве memory-mapped I/O и относятся к защищенным системным ресурсам. Право доступа к ним имеет только привилегированный код ОС и драйверов уровня ядра. В свою очередь, авторы одного из вредоносных сценариев для преодоления классических механизмов защиты воспользовались драйвером RwDrv.sys, входящим в состав известной информационно-диагностической утилиты RWEverything.

Заметим, что в отличие от программного обеспечения, запускаемого в сеансе ОС, UEFI-приложение, получает управление в режиме привилегий Kernel Mode. В этом плане решение задачи доступа к системным ресурсам значительно проще и сводится к непосредственному обращению к адресному пространству. В целях обеспечения совместимости и портируемости правилом хорошего тона является использование специальных UEFI API, в частности EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL вместо непосредственного обращения к memory-mapped ресурсам (например, инструкцией MOV с операндом в пространстве MMIO). Но и здесь в типовом случае нет проблем, связанных с привилегиями в защищенном режиме работы процессора. Хотя и в этом варианте вопросы обхода аппаратной защиты SPI ROM и механизмов противодействия атаке, реализованных средствами System Management Mode остаются актуальными.
Именно в силу того, что Secure Boot перекрывает возможность запуска незарегистрированного UEFI-приложения, авторы рассмотренного сценария воспользовались runtime-контекстом операционной системы для внедрения вредоносного кода в UEFI-прошивку платформы. Это позволило им выполнять чтение и запись содержимого UEFI ROM, действуя в статусе «законопослушного» приложения, снабженного подписанным драйвером. Диалог приложения и драйвера осуществлялся на основе стандартного механизма Input-Output Control.
Практикуя цивилизованные подходы к разработке вредоносного кода, транзакции, адресующие ресурсы memory-mapped I/O и конфигурационного PCI-пространства представлены в виде IOCTL-запросов. Выполнив эти транзакции в определенной последовательности, можно реализовать сценарии чтения и записи содержимого SPI ROM, что и было сделано.