🥇 Доверливо преземање на Шредингер. Intel Boot Guard

Предлагаме повторно да се спуштиме на ниско ниво и да зборуваме за безбедноста на компјутерските платформи компатибилни со фирмверот x86. Овој пат, главната состојка на студијата е Intel Boot Guard (да не се меша со Intel BIOS Guard!) - хардверски поддржана доверлива технологија за подигање на BIOS, која продавачот на компјутерски системи може трајно да ја вклучи или исклучи во фазата на производство. Па, ние веќе го знаеме рецептот за истражување: тенко исечете ја имплементацијата на оваа технологија со обратно инженерство, опишете ја нејзината архитектура, пополнете ја со недокументирани детали, зачинете ја со вектори за напад по вкус и измешајте ја. Ајде да додадеме оган со приказна за тоа како клонирана грешка во производството на неколку продавачи со години му дозволува на потенцијалниот напаѓач да ја користи оваа технологија за да создаде скриен rootkit што не може да се отстрани (дури и од програмер) во системот.

Патем, написот се базира на извештаите „On Guard for Rootkits: Intel BootGuard“ од конференцијата ZeroNights 2016 година и 29. состанок DefCon Русија (двете презентации тука).

Фирмвер за компјутерска платформа со архитектура Intel 64

За почеток, да одговориме на прашањето: каков е фирмверот на модерна компјутерска платформа со архитектурата Intel 64? Се разбира, UEFI BIOS-от. Но, овој одговор нема да биде точен. Ајде да ја погледнеме сликата, која ја прикажува десктоп (лаптоп) верзијата на оваа архитектура.

Врската е основата:

Процесор (CPU, Central Processing Unit), кој покрај главните јадра има и вградено графичко јадро (не во сите модели) и мемориски контролер (IMC, интегриран мемориски контролер);
Чипсет (PCH, Платформски контролер Hub), кој содржи различни контролери за интеракција со периферни уреди и управување со потсистеми. Меѓу нив е и озлогласениот Intel Management Engine (ME), кој има и фирмвер (Intel ME firmware).

За лаптопите, покрај горенаведеното, потребен е и интегриран контролер (ACPI EC, Advanced Control and Power Interface Embedded Controller), кој е одговорен за работата на потсистемот за напојување, тачпад, тастатура, копчиња Fn (осветленост на екранот, јачина на звук, тастатура позадинско осветлување, итн.) и повеќе. И тој исто така има свој фирмвер.

Значи, комбинацијата на горенаведениот фирмвер е фирмверот на компјутерската платформа (системски фирмвер), кој се чува на заедничка SPI флеш меморија. За да не се збунат корисниците на оваа меморија каде лежи некој, содржината на оваа меморија е поделена на следните региони (како што е прикажано на сликата):

UEFI BIOS;
Фирмверот ACPI EC (се појави посебен регион со микроархитектурата на процесорот Skylake (2015), но во дивината сè уште не сме виделе примери за негова употреба, така што фирмверот за вграден контролер сè уште е дел од UEFI BIOS-от);
Интел МЕ фирмверот;
конфигурација (MAC адреса, итн.) на вградениот мрежен адаптер GbE (Gigabit Ethernet);
блиц дескриптори - главниот регион на флеш меморија, кој содржи покажувачи кон други региони, како и дозволи за пристап до нив.

Диференцијацијата на пристапот до регионите (во согласност со наведените дозволи) се справува со SPI bus master - контролерот SPI вграден во чипсетот, преку кој се пристапува до оваа меморија. Ако дозволите се поставени на вредностите препорачани (од безбедносни причини) од Интел, тогаш секој корисник на блицот SPI има целосен пристап (читање/пишување) само до својот регион. Останатите се или само за читање или недостапни. Познат факт: на многу системи, процесорот има целосен пристап до UEFI BIOS-от и GbE, пристап за читање само до дескриптори на блиц и воопшто нема пристап до регионот ME на Intel. Зошто многу, а не сите? Она што се препорачува е опционално. Ќе ви кажеме повеќе подоцна во статијата.

Механизми за заштита на фирмверот на компјутерска платформа од модификација

Очигледно, фирмверот на компјутерската платформа треба да биде заштитен од можен компромис, што ќе му овозможи на потенцијалниот напаѓач да се зацврсти во него (да преживее ажурирања / реинсталации на ОС), да го изврши нивниот код во најпривилегираните режими итн. И разграничувањето на пристапот до регионите на флеш меморија SPI, се разбира, не е доволно. Затоа, се користат различни механизми специфични за секоја средина за извршување за да се заштити фирмверот од модификации.

Значи, фирмверот на Intel ME е потпишан за контрола на интегритетот и автентичноста и се проверува од контролорот ME секој пат кога ќе се вчита во меморијата ME UMA. Овој процес на верификација веќе беше дискутиран од нас во една од статиипосветен на потсистемот Intel ME.

И фирмверот ACPI EC, по правило, се проверува само за интегритет. Меѓутоа, поради фактот што овој бинарен е вклучен во UEFI BIOS-от, речиси секогаш е предмет на истите заштитни механизми што ги користи UEFI BIOS-от. Ајде да зборуваме за нив.

Овие механизми можат да се поделат во две категории.

Заштита за пишување во регионот на UEFI BIOS-от

Физичка заштита на содржината на SPI флеш меморијата со скокач за заштита од запишување;
Заштита на проекцијата на регионот UEFI BIOS во просторот за адреси на процесорот со користење на PRx регистрите на чипсетот;
Блокирање на обидите за пишување во регионот на UEFI BIOS со генерирање и обработка на соодветниот прекин на SMI со поставување на битови BIOS_WE / BLE и SMM_BWP во регистрите на чипсетот;
Понапредна верзија на оваа заштита е Intel BIOS Guard (PFAT).

Покрај овие механизми, продавачите можат да развијат и имплементираат сопствени безбедносни мерки (на пример, потпишување капсули со ажурирања на UEFI BIOS-от).

Важно е да се напомене дека на специфичен систем (во зависност од продавачот), не може да се применат сите горенаведени заштитни механизми, може воопшто да не се применуваат или да се имплементираат на ранлив начин. Повеќе за овие механизми и состојбата со нивната имплементација можете да прочитате во овој напис. За заинтересираните, препорачуваме да ја прочитате целата серија написи за безбедноста на UEFI BIOS-от од CodeRush.

Потврда за автентикација на UEFI BIOS-от

Кога зборуваме за доверливи технологии за подигање, првото нешто што ни паѓа на ум е Безбедно подигање. Сепак, архитектонски, тој е дизајниран да ги автентицира компонентите надвор од UEFI BIOS-от (возачи, натоварувачи итн.), а не самиот фирмвер.

Затоа, Интел во SoC со микроархитектурата Bay Trail (2012) имплементира хардверски непреклоплив Secure Boot (Verified Boot), кој нема никаква врска со гореспоменатата технологија за безбедно подигање. Подоцна (2013 година), овој механизам беше подобрен и, под името Intel Boot Guard, беше објавен за десктоп компјутери со микроархитектура Хасвел.

Пред да го опишеме Intel Boot Guard, да ги погледнеме времињата на работа во архитектурата Intel 64, кои, во комбинација, се корените на довербата за оваа доверлива технологија за подигање.

Интел процесор

Cap сугерира дека процесорот е главната средина за извршување во архитектурата Intel 64. Зошто тој е и коренот на довербата? Излегува дека поседувањето на следниве елементи го прави тоа така:

ROM-от за микрокод е неиспарлива, непрепишувачка меморија за складирање на микрокод. Се верува дека микрокодот е имплементација на процесорскиот инструкциски систем на наједноставните инструкции. Се случува и во микрокод бубачки. Така, во BIOS-от можете да најдете бинарни датотеки со ажурирања на микрокод (тие се надредени при подигање, бидејќи ROM-от не може да се препише). Содржината на овие бинарни датотеки е шифрирана, што во голема мера ја отежнува анализата (затоа, специфичната содржина на микрокодот им е позната само на оние кои го развиваат), и потпишана за контрола на интегритетот и автентичноста;
AES клуч за дешифрирање на содржината на ажурирањата на микрокодовите;
хаш на јавниот клуч RSA што го потврдува потписот на ажурирањата на микрокодовите;
RSA хаш на јавниот клуч, кој го проверува потписот на модулите за код ACM (Authenticated Code Module) развиени од Intel, кои процесорот може да ги стартува пред да започне BIOS-от (здраво микрокод) или за време на неговото работење, кога ќе се појават некои настани.

Интел МЕ

Овој потсистем во нашиот блог беше посветен на две Член. Потсетете се дека оваа извршна средина се заснова на микроконтролерот вграден во чипсетот и е најскриена и најпривилегирана во системот.

И покрај скришум, Intel ME е исто така коренот на довербата, бидејќи има:

ME ROM - неиспарлива, непрепишувачка меморија (не е обезбеден метод за ажурирање), која го содржи стартниот код, како и хашот SHA256 на јавниот клуч RSA, кој го проверува потписот на фирмверот на Intel ME;
AES клуч за складирање на тајни информации;
пристап до збир на осигурувачи (FPF, 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, Chapter Boot with Integrity, or Not Boot], тој работи како доверлив синџир за подигање. И првата врска во него е кодот за подигање (микрокод) во процесорот, кој се активира од настанот RESET (да не се меша со векторот RESET во BIOS-от!). Процесорот наоѓа коден модул (Intel BG startup ACM) развиен и потпишан од Intel на SPI флеш меморијата, го вчитува во неговата кеш меморија, го потврдува (веќе беше забележано погоре дека процесорот има хаш на јавен клуч што го потврдува потписот на ACM ) и започнува.

Овој код модул е одговорен за проверка на мал почетен дел од UEFI BIOS-от - Initial Boot Block (IBB), кој, пак, ја содржи функционалноста за проверка на главниот дел од UEFI BIOS-от. Така, Intel BG ви овозможува да ја потврдите автентичноста на BIOS-от пред да го подигнете оперативниот систем (што може да се изврши под надзор на технологијата Secure Boot).

Технологијата Intel BG обезбедува два режима на работа (и едниот не се меша со другиот, т.е. двата режими може да се овозможат на системот, а и двата може да се оневозможат).

Измерена чизма

Во режимот за мерено подигање (MB), секоја компонента за подигање (почнувајќи од ROM-от за подигање на процесорот) „ја мери“ следната користејќи ги можностите на модулот за доверлива платформа (TPM). За тие што не знаат, да објаснам.

TPM има PCR (Platform Configuration Registers), кои го снимаат резултатот од операцијата за хеширање според формулата:

Оние. моменталната вредност на PCR зависи од претходната и овие регистри се ресетираат само кога системот е RESET.

Така, во режимот MB, во одреден момент во времето, PCR рефлектираат единствен (во рамките на можностите на операцијата за хаш) идентификатор на кодот или податоците што биле „мерени“. Вредностите на PCR може да се користат при шифрирање на некои операции на податоци (TPM_Seal). После тоа, нивното дешифрирање (TPM_Unseal) ќе биде можно само ако вредностите на PCR не се променети како резултат на вчитувањето (т.е., ниту една „измерена“ компонента не е изменета).

Потврдена чизма

Најстрашното нешто за оние кои сакаат да го менуваат UEFI BIOS-от е режимот Verified Boot (VB), во кој секоја компонента за подигање криптографски го потврдува интегритетот и автентичноста на следната. И во случај на грешка при верификација, се појавува (едно од следниве):

исклучување со истек од 1 минута до 30 минути (така што корисникот има време да разбере зошто неговиот компјутер не се подига и, ако е можно, би се обидел да го врати BIOS-от);
итно исклучување (така што корисникот нема време да разбере и, згора на тоа, да направи);
продолжување на работата со директно лице (случај кога нема време за безбедност, бидејќи има поважни работи што треба да се направат).

Изборот на дејство зависи од наведената конфигурација на Intel BG (имено, од таканаречената политика за спроведување), која е трајно снимена од продавачот на компјутерската платформа во специјално дизајнирано складирање - осигурувачи за чипсет (FPF). На оваа точка ќе се задржиме подетално подоцна.

Покрај конфигурацијата, продавачот генерира два клуча RSA 2048 и создава две структури на податоци (прикажано на сликата):

Манифестот на коренскиот клуч на продавачот (KEYM, OEM Root Key Manifest), кој го става SVN (Број на безбедносна верзија) на овој манифест, хаш SHA256 на јавниот клуч на следниот манифест, јавниот клуч RSA (т.е. јавниот дел од root key key) за да го потврди потписот на овој манифест и самиот потпис;
IBB Manifest (IBBM, Initial Boot Block Manifest), кој го става SVN на овој манифест, хашот SHA256 на IBB, јавниот клуч за потврдување на потписот на овој манифест и самиот потпис.

Хешот SHA256 на коренскиот клуч OEM е трајно запишан на осигурувачите на чипсет (FPF), исто како и конфигурацијата на Intel BG. Ако конфигурацијата на Intel BG предвидува вклучување на оваа технологија, тогаш отсега натаму овој систем само сопственикот на приватниот дел од коренскиот клуч OEM може да го ажурира BIOS-от (т.е. да може повторно да ги пресмета овие манифестации), т.е. продавач.

Кога ќе ја погледнете сликата, веднаш се појавуваат сомнежи за потребата од толку долг синџир на верификација - можевте да користите еден манифест. Зошто да се комплицира?

Всушност, Intel на тој начин му дава на продавачот можност да користи различни IBB клучеви за различни линии на производи и еден како root. Ако приватниот дел од клучот IBB (кој го потпишува вториот манифест) протече, инцидентот ќе влијае само на една производна линија и само додека продавачот не генерира нов пар и не ги овозможи повторно пресметаните манифестации во следното ажурирање на BIOS-от.

Но, ако коренскиот клуч е компромитиран (со кој е потпишан првиот манифест), нема да биде можно да се замени, постапката за отповикување не е обезбедена. хашот на јавниот дел од овој клуч е програмиран во FPF еднаш засекогаш.

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

Сега ајде внимателно да ја разгледаме конфигурацијата на Intel BG и процесот на неговото создавање. Ако го погледнете соодветното јазиче во GUI на Flash Image Tool од Intel System Tool Kit (STK), ќе забележите дека Intel BG конфигурацијата вклучува хаш од јавниот дел од root клучот на продавачот, неколку нејасни вредности, и така натаму. Профил на 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 ACM модулот за стартување на SPI блицот, нема да се појави доверливо подигање. Ќе биде недоверливо.

Веќе напишавме погоре дека политиката за извршување за режимот VB може да се конфигурира така што ако потврдата не успее, повторно ќе се појави недоверливо преземање.

Оставете ги ваквите работи на продавачите...

GUI на алатката ги обезбедува следните „готови“ профили:

број
Режим
Опис

0
No_FVME
Технологијата Intel BG е оневозможена

1
VE
Режимот VB е овозможен, исклучување со истек на време

2
ВМЕ
двата режима се овозможени (VB и MB), исклучување со истек на време

3
VM
двата режима се овозможени, без исклучување на системот

4
ПЕВА
Режимот VB е овозможен, веднаш исклучување

5
FVME
двата режима се овозможени, итно исклучување

Како што веќе беше споменато, конфигурацијата на Intel BG мора еднаш засекогаш да биде напишана од продавачот на системот во осигурувачи на чипсет (FPF) - мало (според непроверени информации, само 256 бајти) складирање на хардверски информации во чипсетот, кое може да се програмира надвор на производствените капацитети на Интел (па затоа Програмирачко поле осигурувачи).

Одлично е за складирање на конфигурации затоа што:

има простор за складирање податоци што може да се програмира еднаш (токму каде што е напишана конфигурацијата на Intel BG);
само Intel ME може да го чита и програмира.

Значи, за да ја поставите конфигурацијата за технологијата Intel BG на одреден систем, продавачот го прави следново за време на производството:

Со помош на алатката Flash Image Tool (од Intel STK), се создава слика на фирмверот со дадена конфигурација на Intel BG како променливи внатре во регионот на Intel ME (т.н. привремено огледало за FPF);
Користејќи ја алатката за програмирање Flash (од Intel STK), ја запишува оваа слика на SPI флеш меморијата на системот и го затвора т.н. режим на производство (во овој случај, соодветната команда се испраќа до Intel ME).

Како резултат на овие операции, Intel ME ќе ги обврзе на FPF дадените вредности од огледалото за FPF во регионот ME, ќе ги постави дозволите во дескрипторите за блиц SPI на вредностите препорачани од Intel (опишани на почетокот на член) и изврши РЕСЕТИРАЊЕ на системот.

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

За да ја анализираме имплементацијата на оваа технологија на конкретен пример, ги проверивме следните системи за траги од технологијата Intel BG:

Систем
Имајте на ум

Гигабајт GA-H170-D3H
Скајлејк, има поддршка

Гигабајт GA-Q170-D3H
Скајлејк, има поддршка

Гигабајт GA-B150-HD3
Скајлејк, има поддршка

MSI H170A Gaming Pro
Скајлејк, без поддршка

Леново ThinkPad 460
Skylake, достапна поддршка, овозможена технологија

Леново јога 2 Pro
Хасвел, нема поддршка

Lenovo U330p
Хасвел, нема поддршка

„Поддршка“ значи присуство на ACM-модулот за стартување Intel BG, манифестациите споменати погоре и соодветниот код во BIOS-от, т.е. имплементации за анализа.

Како пример, да го земеме преземениот од канцеларијата. Слика на локацијата на продавачот на SPI флеш меморија за Gigabyte GA-H170-D3H (верзија F4).

ROM за подигање на процесорот на Intel

Пред сè, ајде да зборуваме за дејствата на процесорот ако е овозможена технологијата Intel BG.

Не беше можно да се најдат примероци од дешифрираниот микрокод, затоа, како се спроведуваат дејствата опишани подолу (во микрокод или во хардвер) е отворено прашање. Сепак, фактот дека современите процесори на Интел „можат“ да ги извршуваат овие дејства е факт.

По излегувањето од состојбата RESET, процесорот (во чиј адресен простор веќе е мапирана содржината на флеш меморијата) ја наоѓа FIT (табела за интерфејс на фирмверот). Наоѓањето е лесно, покажувачот кон него е напишан на адресата 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-от, т.е. пред да се префрлите на наследниот векторот 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
};

Сега е очигледно дека еден од записите укажува на локацијата на бинарниот ACM за стартување на Intel BG. Структурата на заглавието на овој бинарен е типична за кодните модули развиени од Интел (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];
};

Процесорот го вчитува овој бинарен во неговиот кеш, го потврдува и стартува.

Интел BG стартување ACM

Како резултат на анализата на работата на оваа АСМ, стана јасно дека го прави следново:

ја прима од Intel ME конфигурацијата Intel BG запишана на осигурувачите на чипсетот (FPF);
наоѓа KEYM и IBBM манифестира, ги потврдува.

За да ги пронајде овие манифестации, ACM ја користи и табелата FIT, која има два типа на записи за да укаже на овие структури (видете FIT_ENTRY_TYPES погоре).

Да ги погледнеме подетално манифестите. Во структурата на првиот манифест, гледаме неколку нејасни константи, хаш на јавниот клуч од вториот манифест и јавен коренски клуч OEM потпишан како вгнездена структура:

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, потсетуваме дека се користи хашот 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 (Независен продавач на BIOS) или самиот продавач на системот. Бидејќи Само Lenovo и Gigabyte системите ни се на располагање и имаат поддршка од Intel BG, ајде да го разгледаме кодот извлечен од овие системи.

Модул 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 (контролор за управување со енергија), поврзано со обезбедување на оперативност на потсистемот за напојување и следење на перформансите.

Содржината на новиот регион IFWI е збир од следните модули:

Офсет
име
Опис

0000 2000ч
SMIP
некоја конфигурација на платформата, потпишана од продавачот

0000 6000ч
RBEP
Секција за код на фирмверот на Intel TXE, x86, потпишана од Интел

0001 0000ч
PMCP
Секција за код на фирмверот Intel PMC, ARC, потпишан од Intel

0002 0000ч
FTPR
Секција за код на фирмверот на Intel TXE, x86, потпишана од Интел

0007B000h
UCOD
Ажурирања на микрокод на процесорот потпишани од Интел

0008 0000ч
IBBP
UEFI BIOS, фази SEC/PEI, x86, потпишан од продавачот

0021 8000ч
ISHC
дел за код на фирмверот Intel ISH, x86, потпишан од продавачот

0025 8000ч
NFTP
Секција за код на фирмверот на Intel TXE, x86, потпишана од Интел

0036 1000ч
IUNP
непознат

0038 1000ч
ОББП
UEFI BIOS, фаза DXE, x86, непотпишан

При анализата на фирмверот TXE, стана очигледно дека по RESET, TXE го задржува процесорот во оваа состојба додека не ги подготви основните содржини на адресниот простор за процесорот (FIT, ACM, RESET вектор ...). Покрај тоа, TXE ги става овие податоци во својот SRAM, по што привремено му обезбедува пристап на процесорот таму и го „ослободува“ од RESET.

На стража на rootkits

Па, сега да преминеме на „жешкото“. Еднаш откривме дека на многу системи SPI флеш-дескрипторите имаат дозволи за пристап до регионите на SPI флеш меморијата така што сите корисници на оваа меморија можат и да пишуваат и да читаат кој било регион. Оние. нема шанси.

Откако проверивме со алатката MEinfo (од Intel STK), видовме дека режимот на производство на овие системи не е затворен, затоа, осигурувачите на чипсетот (FPF) беа оставени во неодредена состојба. Да, Intel BG не е ниту вклучен ниту оневозможен во такви случаи.

Зборуваме за следните системи (во однос на Intel BG и она што ќе биде опишано подоцна во статијата, ќе зборуваме за системи со микроархитектура на процесор Haswell и повисоко):

сите производи од Gigabyte;
сите производи на MSI;
21 модел на лаптоп Lenovo и 4 модели на сервер на Lenovo.

Се разбира, откритието го пријавивме кај овие продавачи, како и кај Интел.

Адекватен одговор следеше само од Леновокој го призна проблемот и објави лепенка.

Gigabyte Се чини дека прифатиле информации за ранливоста, но не коментирале на никаков начин.

Комуникација со MSI целосно застој на нашето барање да го испратиме нашиот јавен PGP клуч (за да им испратиме шифрирана безбедносна совета). Тие изјавија дека „се производител на хардвер и не произведуваат PGP клучеви“.

Но, повеќе за поентата. Бидејќи осигурувачите се оставени во недефинирана состојба, корисникот (или напаѓачот) може сам да ги програмира (најтешко е најдете Intel STK). Ова бара следните чекори.

1. Подигнете се во оперативниот систем Windows (општо, чекорите опишани подолу може да се направат и од под Linux, ако развиете аналог на Intel STK за саканиот оперативен систем). Користејќи ја алатката MEinfo, проверете дали осигурувачите на овој систем не се програмирани.

2. Читајте ја содржината на флеш меморијата користејќи ја алатката за програмирање Flash.

3. Отворете ја прочитаната слика користејќи која било алатка за уредување на UEFI BIOS-от, направете ги потребните промени (имплементирајте rootkit, на пример), креирајте / уредете ги постојните структури на KEYM и IBBM во регионот ME.

Јавниот дел од клучот RSA е означен на сликата, чиј хаш ќе биде програмиран во осигурувачите на чипсетот заедно со остатокот од конфигурацијата на Intel BG.

4. Користејќи ја алатката Flash Image Tool, направете нова слика на фирмверот (со поставување на конфигурацијата на Intel BG).

5. Напишете нова слика за трепкање со помош на алатката за програмирање Flash, проверете со помош на MEinfo дека регионот ME сега ја содржи конфигурацијата на Intel BG.

6. Користете ја алатката за програмирање Flash за да го затворите режимот на производство.

7. Системот ќе се рестартира, по што, користејќи MEinfo, можете да потврдите дека FPF-ите сега се програмирани.

Овие акции засекогаш овозможете Intel BG на овој систем. Ќе биде невозможно да се врати дејството, што значи:

само сопственикот на приватниот дел од коренскиот клуч (т.е. оној што го овозможил Intel BG) ќе може да го ажурира UEFI BIOS-от на овој систем;
ако го вратите оригиналниот фирмвер на овој систем, на пример, користејќи програмер, тој дури и нема да се вклучи (последица на политиката за спроведување во случај на грешка при проверката);
за да се ослободите од таков UEFI BIOS, треба да го замените чипсетот со програмирани FPF со „чист“ (т.е. прелемете го чипсетот ако имате пристап до станица за инфрацрвено лемење по цена на автомобил, или само да ја замените матичната плоча ).

За да разберете што може да направи таков rootkit, треба да процените што овозможува да се изврши вашиот код во околина на UEFI BIOS. Кажи, во најпривилегираниот режим на процесорот - SMM. Таквиот rootkit може да ги има следниве својства:

да се изврши паралелно со ОС (можете да поставите обработка со генерирање на прекин на SMI, кој ќе се активира со тајмер);
ги имаат сите предности да се биде во режим на SMM (целосен пристап до содржината на RAM и хардверските ресурси, тајност од ОС);
Кодот на rootkit може да се шифрира и дешифрира кога ќе се стартува во режим SMM. Сите податоци достапни само во режимот SMM може да се користат како клуч за шифрирање. На пример, хаш од збир на адреси во SMRAM. За да го добиете овој клуч, ќе треба да се качите во SMM. И ова може да се направи на два начина. Најдете го RCE во SMM-кодот и искористете го или додајте свој SMM-модул во BIOS-от, што е невозможно, бидејќи го овозможивме Boot Guard.

Така, оваа ранливост му овозможува на напаѓачот да:

креирајте скриен, неотстранлив rootkit со непозната намена во системот;
извршете го вашиот код на едно од јадрата на чипсетот во Intel SoC, имено, на Intel ISH (погледнете ја сликата подетално).

Иако можностите на потсистемот Intel ISH сè уште не се истражени, се чини дека е интересен вектор за напад против Intel ME.

Наоди

Студијата даде технички опис за тоа како функционира технологијата Intel Boot Guard. Минус неколку тајни во безбедноста на Интел преку модел на затемнување.
Презентирано е сценарио за напад што овозможува создавање неотстранлив rootkit во системот.
Видовме дека современите процесори на Интел се способни да извршат многу комерцијален код дури и пред да започне BIOS-от.
Платформите со Intel 64 архитектура стануваат сè помалку погодни за водење на слободен софтвер: хардверска верификација, зголемен број на сопствени технологии и потсистеми (три јадра во чипсетот SoC: x86 ME, x86 ISH и ARC PMC).

Ублажувања

Продавачите кои намерно го оставаат отворен режимот на производство, дефинитивно треба да го затворат. Засега само ги затвораат очите и тоа го покажуваат новите системи на Kaby Lake.

Корисниците можат да го оневозможат Intel BG на нивните системи (кои се погодени од опишаната ранливост) со извршување на Алатката за програмирање Flash со опцијата -closemnf. Прво, треба да се уверите (користејќи MEinfo) дека конфигурацијата на Intel BG во регионот ME предвидува точно исклучување на оваа технологија по програмирањето во FPF.

Извор: www.habr.com

Доверлива чизма на Шредингер. Intel Boot Guard