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

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

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

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

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

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

• Процессора (CPU, Central Processing Unit), в который, помимо основных ядер, встроено графическое ядро (не во всех моделях) и внедрён контроллер памяти (IMC, Integrated Memory Controller);
• Чипсета (PCH, Platform Controller Hub), содержащего различные контроллеры для взаимодействия с периферийными устройствами и управления подсистемами. Среди них — небезызвестная Intel Management Engine (ME), у которой тоже есть прошивка (Intel ME firmware).

Ноутбуки, помимо вышеперечисленного, предполагают наличие встроенного контроллера (ACPI EC, Advanced Control and Power Interface Embedded Controller), который отвечает за работоспособность подсистемы питания, тачпада, клавиатуры, Fn-клавиш (яркость экрана, громкость звука, подсветка клавиатуры и т.п.) и прочего. И у него тоже есть своя прошивка.

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

• UEFI BIOS;
• прошивка ACPI EC (отдельный регион появился с процессорной микроархитектуры Skylake (2015 год), но in-the-wild мы пока не видели примеров его использования, так что прошивка встроенного контроллера по-прежнему входит в состав UEFI BIOS);
• прошивка Intel ME;
• конфигурация (MAC-адрес и т.д.) встроенного сетевого адаптера GbE (Gigabit Ethernet);
• флэш-дескрипторы (Flash Descriptors) – главный регион флэш-памяти, который содержит указатели на остальные регионы, а также разрешения на доступ к ним.

Разграничением доступа к регионам (в соответствии с заданными разрешениями) занимается мастер шины 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

1. Физическая защита содержимого SPI флэш-памяти write-protect джампером;
2. Защита проекции региона UEFI BIOS в адресном пространстве CPU с помощью PRx регистров чипсета;
3. Блокировка попыток записи в регион UEFI BIOS генерацией и обработкой соответствующего прерывания SMI путём выставления битов BIOS_WE/BLE и SMM_BWP в регистрах чипсета;
4. Более продвинутый вариант такой защиты – Intel BIOS Guard (PFAT).

В дополнение к этим механизмам, вендоры могут разрабатывать и применять собственные меры безопасности (например, подписывание капсул с обновлениями 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. Почему он же он является корнем доверия? Оказывается, таковым его делает обладание следующими элементами:

• Microcode ROM — энергонезависимая, неперезаписываемая память для хранения микрокода. Считается, что микрокодом является имплементация системы команд процессора на простейших инструкциях. В микрокоде тоже случаются баги. Так что в BIOS можно найти бинари с обновлениями микрокода (накладываются во время загрузки, т.к. ROM нельзя перезаписать). Содержимое этих бинарей зашифровано, что значительно усложняет анализ (поэтому, конкретное содержание микрокода известно только тем, кто его разрабатывает), и подписано, для контроля целостности и подлинности;
• AES ключ для дешифровки содержимого обновлений микрокода;
• хеш публичного ключа RSA, которым проверяется подпись обновлений микрокода;
• хеш публичного ключа RSA, которым проверяется подпись разработанных компанией Intel кодовых модулей ACM (Authenticated Code Module), которые CPU может запускать до начала исполнения BIOS (привет микрокоду) или во время его работы, при возникновении некоторых событий.

Intel ME

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

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

• ME ROM — энергонезависимую, неперезаписываемую память (способа обновления не предусмотрено), содержащую стартовый код, а также SHA256 хеш публичного ключа RSA, которым проверяется подпись прошивки Intel ME;
• AES ключ для хранения секретной информации;
• доступ к интегрированному в чипсет набору фьюзов (FPFs, Field Programmable Fuses) для перманентного хранения некоторой информации, в том числе, и заданной вендором компьютерной системы.

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), при котором каждый загрузочный компонент криптографически проверяет целостность и подлинность следующего. А в случае ошибки верификации, происходит (одно из):

• выключение по таймауту от 1 мин до 30 мин (чтобы пользователь успел понять, по какой причине у него компьютер не грузится, и, по возможности, попытался бы восстановить BIOS);
• немедленное выключение (чтобы пользователь ничего не успел понять и, тем более, сделать);
• продолжение работы с невозмутимым видом (тот случай когда не до безопасности, ведь есть дела поважнее).

Выбор действия зависит от заданной конфигурации Intel BG (а именно, от т.н. enforcement policy), которая вендором компьютерной платформы перманентно записывается в специально предназначенное хранилище – фьюзы чипсета (FPF-ы). Подробнее на этом моменте остановимся позже.

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

1. Манифест корневого ключа вендора (KEYM, OEM Root Key Manifest), в который кладёт SVN (Security Version Number) этого манифеста, SHA256 хеш публичного ключа следующего манифеста, публичный ключ RSA (т.е. публичную часть корневого ключа вендора) для проверки подписи этого манифеста и саму подпись;
2. Манифест IBB (IBBM, Initial Boot Block Manifest), в который кладёт SVN этого манифеста, SHA256 хеш IBB, публичный ключ для проверки подписи этого манифеста и саму подпись.

SHA256 хеш публичного ключа OEM Root Key перманентно записывается во фьюзы чипсета (FPF-ы), как и конфигурация Intel BG. Если конфигурация Intel BG предусматривает включение этой технологии, то с этого момента на данной системе обновлять BIOS (т.е. иметь возможность пересчитывать эти манифесты) может только обладатель приватной части OEM Root Key, т.е. вендор.

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

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

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

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

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

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

typedef struct BG_PROFILE
{
	unsigned long Force_Boot_Guard_ACM : 1;
	unsigned long Verified_Boot : 1;
	unsigned long Measured_Boot : 1;
	unsigned long Protect_BIOS_Environment : 1;
	unsigned long Enforcement_Policy : 2; // 00b – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

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

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

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

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

Номер
Режим
Описание

0
No_FVME
технология Intel BG выключена

1
VE
включён режим VB, выключение по таймауту

2
VME
включены оба режима (VB и MB), выключение по таймауту

3
VM
включены оба режима, без выключения системы

4
FVE
включён режим VB, немедленное выключение

5
FVME
включены оба режима, немедленное выключение

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

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

• имеет one-time-programmable область для хранения данных (как раз туда, куда записывается конфигурация Intel BG);
• читать и программировать его может только Intel ME.

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

1. С помощью утилиты Flash Image Tool (из Intel STK) создаёт образ прошивки с заданной конфигурацией Intel BG в виде переменных внутри региона Intel ME (т.н. временное зеркало для FPF-ов);
2. С помощью утилиты Flash Programming Tool (из Intel STK) записывает этот образ на SPI флэш-память системы и закрывает т.н. manufacturing mode (при этом, производится отправка соответствующей команды в Intel ME).

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

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

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

Система
Примечание

Gigabyte GA-H170-D3H
Skylake, есть поддержка

Gigabyte GA-Q170-D3H
Skylake, есть поддержка

Gigabyte GA-B150-HD3
Skylake, есть поддержка

MSI H170A Gaming Pro
Skylake, нет поддержки

Lenovo ThinkPad 460
Skylake, есть поддержка, технология включена

Lenovo Yoga 2 Pro
Haswell, нет поддержки

Lenovo U330p
Haswell, нет поддержки

Под «поддержкой» понимается наличие 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, содержимое которой разбито на записи. Первая запись – заголовок следующей структуры:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // including FIT header entry
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

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

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

typedef struct FIT_ENTRY
{
	unsigned long  BaseAddress;
	unsigned long  : 32;
	unsigned long  Size;
	unsigned short Version;     // 1.0
	unsigned char  EntryType;
	unsigned char  Checksum;
};

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

enum FIT_ENTRY_TYPES
{
	FIT_HEADER = 0,
	MICROCODE_UPDATE,
	BG_ACM,
	BIOS_INIT = 7,
	TPM_POLICY,
	BIOS_POLICY,
	TXT_POLICY,
	BG_KEYM,
	BG_IBBM
};

Теперь очевидно, что одна из записей указывает на местоположение бинаря Intel BG startup ACM. Структура заголовка этого бинаря типична для разрабываемых компанией Intel кодовых модулей (ACM-ы, обновления микрокода, кодовые разделы Intel ME, …).

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // in dwords
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // in BCD format
	unsigned long  TotalSize;      // in dwords
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // in dwords
	unsigned long  ScratchSize;    // in dwords
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

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

Intel BG startup ACM

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

• получает от Intel ME конфигурацию Intel BG, записанную во фьюзы чипсета (FPF-ы);
• находит манифесты KEYM и IBBM, верифицирует их.

Для нахождения этих манифестов ACM тоже пользуется таблицей FIT, в которой отведено два типа записей для указания на данные структуры (см. FIT_ENTRY_TYPES выше).

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

typedef struct KEY_MANIFEST
{
	char           Tag[8];          // ‘__KEYM__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned char  : 8;             // 1
	unsigned short : 16;            // 0Bh
	unsigned short : 16;            // 20h == hash size?
	unsigned char  IbbmKeyHash[32]; // SHA256 of an IBBM public key
	BG_RSA_ENTRY   OemRootKey;
};

typedef struct BG_RSA_ENTRY
{
	unsigned char  : 8;             // 10h
	unsigned short : 16;            // 1
	unsigned char  : 8;             // 10h
	unsigned short RsaPubKeySize;   // 800h
	unsigned long  RsaPubExp;
	unsigned char  RsaPubKey[256];
	unsigned short : 16;            // 14
	unsigned char  : 8;             // 10h
	unsigned short RsaSigSize;      // 800h
	unsigned short : 16;            // 0Bh
	unsigned char  RsaSig[256];
};

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

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

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Boot policies
	IBBS Ibbs;         // IBB description
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM signature
};

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

typedef struct ACBP
{
	char           Tag[8];          // ‘__ACBP__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 1
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned short : 16;            // x & F0h = 0
	unsigned short : 16;            // 0 < x <= 400h
};

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

typedef struct IBBS
{
	char           Tag[8];            // ‘__IBBS__’
	unsigned char  : 8;               // 10h
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // x <= 0Fh
	unsigned long  : 32;              // x & FFFFFFF8h = 0
	unsigned long  Unknown[20];
	unsigned short : 16;              // 0Bh
	unsigned short : 16;              // 20h == hash size ?
	unsigned char  IbbHash[32];       // SHA256 of an IBB
	unsigned char  NumIbbDescriptors;
};

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

typedef struct IBB_DESCRIPTOR
{
	unsigned long  : 32;
	unsigned long  BaseAddress;
	unsigned long  Size;
};

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

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

typedef struct PMSG
{
	char           Tag[8];            // ‘__PMSG__’
	unsigned char  : 8;               // 10h
	BG_RSA_ENTRY   IbbKey;
};

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

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

UEFI BIOS модуль LenovoVerifiedBootPei

В случае с Lenovo, это оказался модуль LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, разработанный компанией Lenovo.

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

if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	if (!VerifyDxe())
		return EFI_SECURITY_VIOLATION;
}

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

typedef struct HASH_TABLE
{
	char          Tag[8];            // ‘$HASHTBL’
	unsigned long NumDxeDescriptors;
	DXE_DESCRIPTORS[];
};

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long Offset;
	unsigned long Size;
};

UEFI BIOS модуль BootGuardPei

В случае с Gigabyte, это оказался модуль BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, разработанный компанией AMI, следовательно, присутствующий в любом AMI BIOS с поддержкой Intel BG.

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

int bootMode = EFI_PEI_SERVICES->GetBootMode();

if (bootMode != BOOT_ON_S3_RESUME &&
    bootMode != BOOT_ON_FLASH_UPDATE &&
    bootMode != BOOT_IN_RECOVERY_MODE)
{
	HOB* h = CreateHob();
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	WriteHob(&h, VerifyDxe());
	return h;
}

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

typedef HASH_TABLE DXE_DESCRIPTORS[];

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long BaseAddress;
	unsigned long Size;
};

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, в которой произошли ощутимые изменения, например:

• регионы BIOS и Intel ME (вернее Intel TXE, согласно терминологии для Intel SoC) теперь являются одним регионом IFWI;
• хоть на платформе был включён Intel BG, таких структур, как FIT, KEYM, IBBM не было найдено во флэш-памяти;
• помимо TXE и ISH ядер (x86), в чипсет добавили третье ядро (снова ARC, кстати) – PMC (Power Management Controller), связанный с обеспечением работоспособности подсистемы питания и мониторингом производительности.

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

Смещение
Имя
Описание

0000 2000h
SMIP
некая конфигурация платформы, подписано вендором

0000 6000h
RBEP
кодовый раздел прошивки Intel TXE, x86, подписано Intel

0001 0000h
PMCP
кодовый раздел прошивки Intel PMC, ARC, подписано Intel

0002 0000h
FTPR
кодовый раздел прошивки Intel TXE, x86, подписано Intel

0007 B000h
UCOD
обновления микрокода для CPU, подписано Intel

0008 0000h
IBBP
UEFI BIOS, фазы SEC/PEI, x86, подписано вендором

0021 8000h
ISHC
кодовый раздел прошивки Intel ISH, x86, подписано вендором

0025 8000h
NFTP
кодовый раздел прошивки Intel TXE, x86, подписано Intel

0036 1000h
IUNP
неизвестно

0038 1000h
OBBP
UEFI BIOS, фаза DXE, x86, не подписано

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

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

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

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

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

• вся продукция Gigabyte;
• вся продукция MSI;
• 21 модель ноутбуков Lenovo и 4 модели серверов Lenovo.

Разумеется, мы сообщили о находке этим вендорам, а также компании Intel.

Адекватная реакция последовала только от 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 на данной системе. Отменить действие будет нельзя, что означает:

• обновлять UEFI BIOS на данной системе сможет только обладатель приватной части корневого ключа (т.е. тот, кто включил Intel BG);
• если вернуть этой системе оригинальную прошивку, например, с помощью программатора, она даже не включится (следствие enforcement policy в случае ошибки верификации);
• чтобы избавиться от такого UEFI BIOS, требуется заменить чипсет с запрограммированными FPF-ами на «чистый» (т.е. перепаять чипсет, если у вас есть доступ к инфракрасной паяльной станции ценой в автомобиль, ну или просто заменить материнскую плату).

Для понимания того, что может натворить такой руткит, нужно оценить, что даёт возможность исполнять свой код в среде UEFI BIOS. Скажем, в самом привилегированном режиме процессора – SMM. Такой руткит может иметь следующие свойства:

• исполняться параллельно ОС (можно настроить отработку по генерации SMI прерывания, которое будет триггериться по таймеру);
• иметь все преимущества нахождения в режиме SMM (полный доступ к содержимому оперативной памяти и к аппаратным ресурсам, скрытность от ОС);
• программный код руткита может находиться в шифрованном виде и дешифровываться при запуске в режиме SMM. В качестве ключа для шифрования можно использовать любые данные, доступные только в режиме SMM. Например, хеш от набора адресов в SMRAM. Чтобы получить этот ключ, потребуется забраться в SMM. А это можно сделать двумя способами. Найти RCE в коде SMM и проэксплуатировать, либо добавить в BIOS свой SMM модуль, что невозможно, поскольку мы включили Boot Guard.

Таким образом, эта уязвимость позволяет злоумышленнику:

• создать в системе скрытый, неудаляемый руткит неизвестного назначения;
• исполнять свой код на одном из ядер чипсета внутри Intel SoC, а именно, на Intel ISH (внимательно взглянем на картинку).

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

Выводы

1. Исследование позволило получить техническое описание работы технологии Intel Boot Guard. Минус пара тайн в Intel-овской модели security through obscurity.
2. Представлен сценарий атаки, позволяющий создать в системе неудаляемый руткит.
3. Мы увидели, что современные процессоры Intel способны исполнить много проприетарного кода ещё до начала работы BIOS.
4. Платформы с архитектурой Intel 64 становятся всё менее пригодными для запуска свободного ПО: аппаратная верификация, увеличивающееся число проприетарных технологий и подсистем (три ядра в чипсете SoC: x86 ME, x86 ISH и ARC PMC).

Mitigations

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

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

Источник: habr.com