Secure Boot — не препятствие для вируса LoJax

Несанкционированная модификация кода BIOS, за­пи­сан­но­го в по­сто­ян­ное за­по­ми­на­ю­щее уст­рой­ст­во, ста­ла оче­вид­ной с по­яв­ле­ни­ем ви­ру­са CIH. Око­ло двад­ца­ти лет на­зад воз­дей­ст­вие зло­вред­но­го соф­та но­си­ло толь­ко де­струк­тив­ный ха­рак­тер: ре­зуль­та­том ра­бо­ты ви­ру­са бы­ло раз­ру­ше­ние со­дер­жи­мо­го Flash ROM и, как след­ст­вие, — пол­ный вы­вод из строя ап­па­рат­ной плат­фор­мы. Тон­кие «хи­рур­ги­че­ские» сце­на­рии вне­д­ре­ния по­сто­рон­не­го ко­да, со­хра­ня­ю­щие ба­зо­вую ра­бо­то­спо­соб­ность ата­ку­е­мой сис­те­мы, упи­ра­лись в уни­фи­ка­цию вну­т­рен­ней струк­ту­ры Le­ga­cy 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-map­ped I/O и конфигурационного PCI-пространства представлены в виде IOCTL-запросов. Выполнив эти транзакции в оп­ре­де­лен­ной по­сле­до­ва­тель­но­сти, можно реализовать сценарии чтения и записи содержимого SPI ROM, что и было сде­ла­но.