Boot guard что это

Доверенная загрузка Шрёдингера. Intel Boot Guard

Предлагаем вновь спуститься на низкий уровень и поговорить о безопасности прошивок x86-совместимых компьютерных платформ. В этот раз главным ингредиентом исследования является Intel Boot Guard (не путать с Intel BIOS Guard!) – аппаратно-поддержанная технология доверенной загрузки BIOS, которую вендор компьютерной системы может перманентно включить или выключить на этапе производства. Ну а рецепт исследования нам уже знаком: тонко нарезать реверс-инжинирингом имплементацию данной технологии, описать её архитектуру, наполнив недокументированными деталями, приправить по вкусу векторами атак и перемешать. Подбавим огня рассказом о том, как годами клонируемая ошибка на производстве нескольких вендоров позволяет потенциальному злоумышленнику использовать эту технологию для создания в системе неудаляемого (даже программатором) скрытого руткита.

Кстати, в основе статьи – доклады «На страже руткитов: Intel BootGuard» с конференции ZeroNights 2016 и 29-й встречи DefCon Russia (обе презентации здесь).

Прошивка компьютерной платформы с архитектурой Intel 64

Для начала ответим на вопрос: что является прошивкой современной компьютерной платформы с архитектурой Intel 64? Разумеется, UEFI BIOS. Но такой ответ будет не точным. Давайте взгянем на рисунок, где изображен десктопный (лэптопный) вариант этой архитектуры.

Основой является связка:

Так вот, совокупность вышеперечисленных прошивок и является прошивкой компьютерной платформы (system firmware), которая хранится на общей SPI флэш-памяти. Чтобы пользователи этой памяти не путались, где чьё лежит, содержимое этой памяти разбито на следующие регионы (как показано на рисунке):

Разграничением доступа к регионам (в соответствии с заданными разрешениями) занимается мастер шины SPI – встроенный в чипсет SPI-контроллер, через который и осуществляется обращение к этой памяти. Если разрешения установлены в рекомендуемые (из соображений безопасности) компанией Intel значения, то каждый пользователь SPI флэш-памяти имеет полный доступ (чтение/запись) только к своему региону. А остальные — либо доступны только для чтения, либо недоступны. Известный факт: на многих системах CPU имеет полный доступ к UEFI BIOS и GbE, доступ на чтение только к флэш-дескрипторам, а к региону Intel ME доступа нет вообще. Почему на многих, а не на всех? Что рекомендуемо, то необязательно. Подробнее расскажем далее в статье.

Механизмы защиты прошивки компьютерной платформы от модификации

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

Так, прошивка Intel ME подписана для контроля целостности и подлинности, и проверяется ME-контроллером при каждой её загрузке в память ME UMA. Этот процесс верификации уже рассматривался нами в одной из статей, посвящённой подсистеме Intel ME.

А прошивка ACPI EC, как правило, проверяется только на целостность. Однако, ввиду того, что этот бинарь включён в состав UEFI BIOS, на него почти всегда распространяются те же механизмы защиты, что использует UEFI BIOS. О них и поговорим.

Эти механизмы можно разделить на две категории.

Защита от записи в регион UEFI BIOS

Важно отметить, что на конкретной системе (зависит от вендора) могут быть применены не все вышеперечисленные механизмы защиты, могут быть вообще не применены, а могут быть уязвимо реализованы. Подробнее об этих механизмах и о ситуации с их реализацией можно почитать в этой статье. Интересующимся рекомендуем ознакомиться со всем циклом статей по безопасности UEFI BIOS от CodeRush.

Верификация подлинности UEFI BIOS

Когда мы говорим о технологиях доверенной загрузки, первое, что приходит на ум, — Secure Boot. Однако, архитектурно он предназначен для проверки подлинности внешних, по отношению к UEFI BIOS, компонентов (драйверов, загрузчиков и т.д.), а не самой прошивки.

Поэтому компания Intel в SoC-ах с микроархитектурой Bay Trail (2012 год) реализовала аппаратный неотключаемый Secure Boot (Verified Boot), не имеющий ничего общего с вышеупомянутой технологией Secure Boot. Позже (2013 год) этот механизм был усовершенствован и под именем Intel Boot Guard выпущен для десктопов с микроархитектурой Haswell.

Перед описанием Intel Boot Guard разберёмся со средами исполнения в архитектуре Intel 64, которые, по совместительству, являются корнями доверия для этой технологии доверенной загрузки.

Intel CPU

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

Intel ME

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

Несмотря на скрытность, Intel ME тоже является корнем доверия, поскольку имеет:

Intel Boot Guard 1.x

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

Итак, Intel Boot Guard (BG) – аппаратно-поддержанная технология верификации подлинности UEFI BIOS. Судя по её небольшому описанию в книге [Platform Embedded Security Technology Revealed, глава Boot with Integrity, or Not Boot], работает она как цепочка доверенной загрузки. И первое звено в ней — загрузочный код (микрокод) внутри CPU, который запускается по событию RESET (не путать с RESET-вектором в BIOS!). CPU находит на SPI флэш-памяти разработанный и подписанный компанией Intel кодовый модуль (Intel BG startup ACM), загружает к себе в кэш, верифицирует (выше уже было отмечено, что CPU имеет хеш публичного ключа, которым проверяется подпись ACM) и запускает.

Этот кодовый модуль отвечает за верификацию небольшой стартовой части UEFI BIOS — Initial Boot Block (IBB), который, в свою очередь, содержит функциональность для верификации основной части UEFI BIOS. Таким образом, Intel BG позволяет убедиться в подлинности BIOS перед загрузкой ОС (которая может выполняться под наблюдением технологии Secure Boot).

Технология Intel BG предусматривает два режима работы (причём один другому не мешает, т.е. оба режима могут быть включены на системе, а могут быть оба выключены).

Measured Boot

В режиме Measured Boot (MB) каждый загрузочный компонент (начиная с CPU boot ROM) «измеряет» следующий, используя возможности TPM (Trusted Platform Module). Для тех, кто не в курсе, поясним.

У TPM есть PCR-ы (Platform Configuration Registers), в которые записывается результат операции хеширования по формуле:

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

Таким образом, в режиме MB в некоторый момент времени PCR-ы отражают уникальный (в пределах возможностей операции хеширования) идентификатор кода или данных, которые «измерялись». Значения PCR могут быть использованы при операции шифрования некоторых данных (TPM_Seal). После этого, их дешифровка (TPM_Unseal) возможна будет только в случае, если значения PCR в результате загрузки не изменились (т.е. ни один «измеряемый» компонент не был модифицирован).

Verified Boot

Самым страшным для любителей модифицировать UEFI BIOS является режим Verified Boot (VB), при котором каждый загрузочный компонент криптографически проверяет целостность и подлинность следующего. А в случае ошибки верификации, происходит (одно из):

Помимо конфигурации, вендор генерирует два ключа RSA 2048 и создаёт две структуры данных (изображено на рисунке):

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

На самом деле компания Intel таким образом предоставляет вендору возможность использовать разные ключи IBB для разных линеек своих продуктов и один – в качестве корневого. Если утечёт приватная часть ключа IBB (которым подписывается второй манифест), инцидент затронет только одну линейку продуктов и только до тех пор, пока вендор не сгенерирует новую пару и не включит пересчитанные манифесты в следующем обновлении BIOS.

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

Конфигурация Intel Boot Guard

Теперь остановимся подробнее на конфигурации Intel BG и процессе её создания. Если взглянуть на соответствующую вкладку в GUI утилиты Flash Image Tool из комплекта Intel System Tool Kit (STK), можно заметить, что конфигурация Intel BG включает хеш публичной части корневого ключа вендора, пару непонятных значений и т.н. профиль Intel BG.

Структура этого профиля:

Вообще, конфигурация Intel BG – сущность очень гибкая. Рассмотрим, например, флаг Force_Boot_Guard_ACM. Когда он снят, в случае, если модуль BG startup ACM на SPI флэш-памяти не будет найден, никакой доверенной загрузки не будет. Будет недоверенная.

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

Оставлять такие вещи на усмотрение вендоров…

GUI утилиты предусматривает следующие «готовые» профили:

Как уже было сказано, конфигурация Intel BG должна быть раз и навсегда записана вендором системы во фьюзы чипсета (FPF-ы) – небольшое (по непроверенным сведениям, всего 256 байт) аппаратное хранилище информации внутри чипсета, которое может быть запрограммировано вне производственных мощностей компании Intel (поэтому, именно Field Programmable Fuses).

Оно отлично подходит для хранения конфигурации, поскольку:

Анализ имплементации Intel Boot Guard

С целью анализа реализации этой технологии на конкретном примере мы проверили следующие системы на предмет наличия следов технологии Intel BG:

Под «поддержкой» понимается наличие Intel BG startup ACM модуля, упомянутых выше манифестов и соответствующего кода в BIOS, т.е. имплементации для анализа.

В качестве примера, возьмём скаченный с оф. сайта вендора образ SPI флэш-памяти для Gigabyte GA-H170-D3H (версия F4).

Intel CPU boot ROM

В первую очередь, поговорим о действиях процессора в случае, если технология Intel BG включена.

Образцов дешифрованного микрокода найти не удалось, поэтому то, как описываемые далее действия реализованы (в микрокоде или аппаратно) – вопрос открытый. Тем не менее, то, что современные процессоры Intel «умеют» производить эти действия – факт.

После выхода из состояния RESET процессор (в адресное пространство которого уже смаплено содержимое флэш-памяти) находит таблицу FIT (Firmware Interface Table). Найти её просто, указатель на неё записан по адресу FFFF FFC0h.

В рассматриваемом примере, по этому адресу лежит значение FFD6 9500h. Обратившись по этому адресу, процессор видит таблицу FIT, содержимое которой разбито на записи. Первая запись – заголовок следующей структуры:

По неизвестной причине чексумма далеко не всегда в этих таблицах посчитана (поле оставлено нулевым).

Остальные записи указывают на различные бинари, которые необходимо пропарсить/исполнить ещё до исполнения BIOS, т.е. до перехода на legacy RESET-вектор (FFFF FFF0h). Структура каждой такой записи такова:

Поле EntryType говорит о типе блока, на который указывает эта запись. Нам известно несколько типов:

Процессор загружает этот бинарь к себе в кэш, верифицирует и запускает.

Intel BG startup ACM

В результате анализа работы этого ACM стало ясно, что он делает следующее:

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

Для верификации публичного ключа OEM Root Key, напомним, используется SHA256 хеш из фьюзов, который на этот момент уже получен от Intel ME.

Перейдём ко второму манифесту. Он состоит из трёх структур:

В первой – какие-то константы:

Во второй находится SHA256 хеш IBB и число дескрипторов, которые описывают содержимое IBB (т.е. то, от чего считается хеш):

Дескрипторы IBB следуют за этой структурой, один за другим. Их содержимое имеет следующий формат:

Всё просто: каждый дескриптор содержит адрес/размер куска IBB. Таким образом, конкатенация блоков, на которые указывают эти дескрипторы (в порядке расположения самих дескрипторов) и является IBB. И, как правило, IBB — это совокупность всех модулей фаз SEC и PEI.

Второй манифест завершает структура, содержащая публичный ключ IBB (верифицируется SHA256 хеш-ем из первого манифеста) и подпись этого манифеста:

Итак, ещё до начала исполнения UEFI BIOS процессор запустит ACM, который проверит подлинность содержимого разделов с кодом фаз SEC и PEI. Далее, процессор выходит из ACM, переходит по RESET-вектору и начинает исполнять BIOS.

Верифицированный PEI раздел должен содержать модуль, который проверит оставшуюся часть BIOS (DXE код). Этот модуль разрабатывает уже IBV (Independent BIOS Vendor) или сам вендор системы. Т.к. оказавшихся в нашем распоряжении и имеющих поддержку Intel BG оказались только системы Lenovo и Gigabyte, рассмотрим код, извлечённых именно из этих систем.

UEFI BIOS модуль LenovoVerifiedBootPei

В случае с Lenovo, это оказался модуль LenovoVerifiedBootPei , разработанный компанией Lenovo.

Его работа заключается в поиске (по GUID) хеш-таблицы для DXE и верификации DXE.

UEFI BIOS модуль BootGuardPei

В случае с Gigabyte, это оказался модуль BootGuardPei , разработанный компанией AMI, следовательно, присутствующий в любом AMI BIOS с поддержкой Intel BG.

Его алгоритм работы несколько иной, однако, сводится к тому же:

Хеш таблица <389CC6F2-1EA8-467B-AB8A-78E769AE2A15>, которую он ищет, имеет следующий формат:

Intel Boot Guard 2.x

Кратко расскажем ещё об одной реализации Intel Boot Guard, которая была найдена в более новой системе на основе Intel SoC с микроархитектурой Apollo Lake — ASRock J4205-IT.

Хотя эта версия будет применяться лишь в SoC-ах (новые системы с процессорной микроархитектурой Kaby Lake продолжают использовать Intel Boot Guard 1.x), она представляет большой интерес в изучении нового варианта архитектуры для платформ на Intel SoC, в которой произошли ощутимые изменения, например:

Содержимое нового региона IFWI представляет собой набор следующих модулей:

В ходе анализа прошивки TXE стало очевидно, что после RESET-а TXE держит процессор в этом состоянии до тех пор, пока не подготовит базовое содержимое адресного пространства для CPU (FIT, ACM, RESET-вектор …). Причём TXE размещает эти данные у себя в SRAM, после чего временно предоставляет процессору туда доступ и «отпускает» его из RESET-а.

На страже руткитов

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

После проверки с помощью утилиты MEinfo (из Intel STK) мы увидели, что manufacturing mode на этих системах не закрыт, следовательно, фьюзы чипсета (FPF-ы) оставлены в неопределённом состоянии. Да, Intel BG в таких случаях ни включён, ни выключен.

Речь идёт о следующих системах (касаемо Intel BG и того, что будет изложено далее в статье, мы будем говорить о системах с процессорной микроархитектурой Haswell и выше):

Адекватная реакция последовала только от Lenovo, которые признали проблему и выпустили патч.

Gigabyte вроде и приняли информацию об уязвимости, но никак не прокомментировали.

Общение с MSI вовсе застопорилось на нашей просьбе прислать свой открытый PGP-ключ (чтобы отправить им security advisory в зашифрованном виде). Они заявили, что «являются производителем оборудования, и PGP-ключи не производят».

Но ближе к делу. Поскольку фьюзы оставлены в незаданном состоянии, пользователь (или злоумышленник) может их запрограммировать самостоятельно (самое сложное — найти Intel STK). Для этого требуется выполнить следующие действия.

1. Загрузиться в ОС Windows (вообще, описываемые далее действия можно сделать и из под Linux, если разработать аналог Intel STK под нужную ОС). Используя утилиту MEinfo, убедиться в том, что фьюзы на данной системе не запрограммированы.

2. Считать содержимое флэш-памяти при помощи Flash Programming Tool.

3. Открыть считанный образ при помощи любого средства для редактирования UEFI BIOS, внести необходимые изменения (внедрить руткит, например), создать/отредактировать имеющиеся структуры KEYM и IBBM в ME регионе.

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

4. При помощи Flash Image Tool собрать новый образ прошивки (задав конфигурацию Intel BG).

5. Записать новый образ на флэш-память при помощи Flash Programming Tool, убедиться при помощи MEinfo, что ME регион теперь содержит конфигурацию Intel BG.

6. При помощи Flash Programming Tool закрыть режим manufacturing mode.

7. Система перезазгрузится, после чего при помощи MEinfo можно убедиться в том, что FPF-ы теперь запрограммированы.

Эти действия навсегда включат Intel BG на данной системе. Отменить действие будет нельзя, что означает:

Хотя возможности подсистемы Intel ISH ещё не изучены, она представляется интересным вектором атаки на Intel ME.

Выводы

Mitigations

Вендорам, которые намеренно оставляют manufacturing mode открытым, следует его обязательно закрывать. Пока что закрывают только глаза и новые Kaby Lake системы это показывают.

Источник

Intel Boot Guard на пальцах

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

История и предпосылки создания

Процесс загрузки компьютера представляет собой цепочку событий, в которой управление исполнительной аппаратурой передается от звена к звену, начиная с нажатия пользователем кнопки включения и заканчивая работой приложения. Проблема заключается в том, что каждое из этих звеньев может быть взломано злоумышленником. Причем чем более раний компонент подвергается атаке, тем большую свободу действий получает правонарушитель. Известны случаи атак, при которых злоумышленник заменял BIOS или Boot loader на собственные, уязвимые и по сути превращал компьютер в «кирпич» (именно поэтому такой тип атак называется Bricking). В попытках защитить процесс загрузки компьютера были созданы многие программные средства проверки целостностности. Однако любая программа может быть успешно заменена правонарушителем, поэтому на нее невозможно полагаться на сто процентов. Отсюда и возникла необходимость создания более надежной, аппаратной технологии обеспечения целостности загрузки.

В качестве своего варианта обеспечения аппаратной защиты загрузки компьютера Intel в 2013 году встроила в новую микроархитектуру Haswell технологию Boot Guard. В процесс загрузки был добавлен аппаратный модуль аутентифицированного кода (ACM, Authenticated code module), а производителям оборудования пришлось расширить BIOS, добавив в него начальный блок загрузки (IBB, Initial boot block). С тех пор цепочка загрузки компьютера включает в себя ACM, с помощью которого проверяется IBB, после чего управление передается BIOS и так далее.

Схема процесса загрузки компьютера с Intel Boot Guard

Режимы работы

Важной составляющей технологии Boot Guard является настройка ее работы. Производитель оборудования должен выбрать, какой режим работы активирован и какие действия стоит предпринимать в случае ошибки в ACM или IBB. Вся этак информация содержится в политиках загрузки, которые «зашиты» в аппаратуре.

Режимы работы Boot Guard можно классифицировать по корню доверия:

Измеренная загрузка (Measured boot) полагается на дополнительное устройство, встраиваемое производителем оборудования. Одним из возможных вариантов устройства является TPM (Trusted platform module) — криптопроцессор, в который предустановлены генератор случайных чисел, генератор ключей RSA, устройство хеширования и устройство RSA.

Проверенная загрузка (Verified boot) полагается на программируемые предохранители, которые являются частью аппаратуры компьютера. По своей сути, программируемый предохранитель — это ячейка, которая может находиться в двух состояниях: сожжена или не сожжена. Будучи сожженной, ячейка не может вернуться в исходное состояние. Таким образом можно кодировать информацию.

Измеренная загрузка

В памяти криптопроцессора TPM хранится эталон хеша начального блока загрузки (IBB), с помощью которого и производится проверка подлинности IBB. Алгоритм работы Boot Guard в режиме измеренной загрузки следующий:

Начальный блок загрузки записывается в память криптопроцессора TPM

Устройство хеширования криптопроцессора загружает записанный в памяти IBB

Устройство хеширования вычисляет хеш IBB

Хеш IBB записывается в память криптопроцессора

Производится сравнение между текущим хешем IBB и его эталоном

В случае совпадения состема помечается как надежная, иначе — как ненадежная

TPM в ходе работы Boot Guard в режиме измеренной загрузки

Проверенная загрузка

Схема работы Boot Guard в режиме измеренной загрузки выглядит несколько сложнее, поскольку помимо начального блока загрузки (IBB) и программируемых предохранителей в нее входят две дополнительные структуры: манифест IBB (IBBM) и манифест ключа. Манифест IBB включает в себя номер версии безопасности, хеш IBB, открытый ключ RSA, подпись RSA номера версии и хеша IBB. Манифест ключа включает в себя номер версии безопасности, хеш открытого ключа RSA манифеста IBB, открытый ключ RSA производителя оборудования, подпись RSA номера версии и хеша открытого ключа RSA манифеста IBB. В программируемых предохранителях записаны хеш открытого ключа RSA производителя и номера версий безопасности манифестов. Все вычисления и сравнения выполняются с помощью модуля аутентифицированного кода (ACM). Алгоритм работы Boot Guard в режиме проверенной загрузки следующий:

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

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

Вычисляется хеш открытого ключа RSA производителя и производится сравнение с соответствующим значением из программируемых предохранителей. В случае несовпадения проверка завершается в соответствии с политиками загрузки.

Проверяется подпись RSA в манифесте ключа. В случае несоответствия проверка завершается в соответствии с политиками загрузки.

Вычисляется хеш открытого ключа RSA манифеста IBB и производится сравнение с соответствующим значением из манифеста ключа. В случае несовпадения проверка завершается в соответствии с политиками загрузки.

Проверяется подпись RSA в манифесте IBB. В случае несоответствия проверка завершается в соответствии с политиками загрузки.

Вычисляется хеш IBB и производится сравнение с соответствующим значением из IBBM. В случае несовпадения проверка завершается в соответствии с политиками загрузки.

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

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

Схема работы Boot Guard в режиме проверенной загрузки

Заключение

В заключение хотелось бы добавить, что не смотря на всю прелесть и надежность Boot Guard, важно понимать, что настройка этой технологии доверена производителю оборудования. В 2017 году были обнаружены шесть моделей материнских плат, в которых Boot Guard была настроена некорректно и позволяла обойти проверку целостности BIOS. Берегите свои компьютеры и выбирайте надежного производителя оборудования!

При написании статьи была использована литература:

Ruan X. Platform Embedded Security Technology Revealed — Apress, Berkeley, CA, 2014. — С. 263 — ISBN 978-1-4302-6572-6

Источник