Довереният ботуш на Шрьодингер. Intel Boot Guard

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

Между другото, статията е базирана на докладите „На стража за руткитове: Intel BootGuard“ от конференцията ZeroNights 2016 и 29-та среща DefCon Русия (и двете презентации тук).

Firmware за компютърна платформа с 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 (яркост на екрана, сила на звука, клавиатура подсветка и др.) ) и др. И той също има собствен фърмуер.

И така, комбинацията от горния фърмуер е фърмуерът на компютърната платформа (системен фърмуер), който се съхранява на обща SPI флаш памет. За да не се объркат потребителите на тази памет къде лъже някой, съдържанието на тази памет е разделено на следните региони (както е показано на фигурата):

• UEFI BIOS;
• Фърмуер ACPI EC (отделен регион се появи с микроархитектурата на процесора Skylake (2015), но в дивата природа все още не сме видели примери за неговото използване, така че фърмуерът на вградения контролер все още е част от UEFI BIOS);
• Intel ME фърмуер;
• конфигурация (MAC адрес и др.) на вградения GbE (Gigabit Ethernet) мрежов адаптер;
• флаш дескриптори - основният регион на флаш паметта, който съдържа указатели към други региони, както и разрешения за достъп до тях.

Разграничаването на достъпа до региони (в съответствие с посочените разрешения) се управлява от SPI bus master - вградения в чипсета SPI контролер, чрез който се осъществява достъп до тази памет. Ако разрешенията са зададени на стойностите, препоръчани (от съображения за сигурност) от Intel, тогава всеки потребител на SPI флаш паметта има пълен достъп (четене/запис) само до своя регион. Останалите са или само за четене, или недостъпни. Известен факт: на много системи процесорът има пълен достъп до UEFI BIOS и GbE, достъп за четене само до флаш дескриптори и изобщо няма достъп до Intel ME региона. Защо много, а не всички? Това, което се препоръчва, не е задължително. Ще ви разкажем повече по-нататък в статията.

Механизми за защита на фърмуера на компютърна платформа от модификация

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

И така, фърмуерът на Intel ME е подписан за контрол на целостта и автентичността и се проверява от ME контролера всеки път, когато се зарежда в паметта на ME UMA. Този процес на проверка вече беше обсъден от нас в един от статиипосветен на подсистемата Intel ME.

И ACPI EC фърмуерът, като правило, се проверява само за целостта. Въпреки това, поради факта, че този двоичен файл е включен в UEFI BIOS, той почти винаги подлежи на същите механизми за защита, които използва UEFI BIOS. Нека поговорим за тях.

Тези механизми могат да бъдат разделени на две категории.

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

1. Физическа защита на съдържанието на SPI флаш паметта с джъмпер за защита от запис;
2. Защита на проекцията на региона на UEFI BIOS в адресното пространство на процесора с помощта на 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

Cap предполага, че процесорът е основната среда за изпълнение в архитектурата Intel 64. Защо той е и основата на доверието? Оказва се, че именно притежаването на следните елементи го прави такъв:

• Microcode ROM е енергонезависима, непрезаписваема памет за съхраняване на микрокод. Смята се, че микрокодът е внедряването на системата от инструкции на процесора върху най-простите инструкции. Случва се и в микрокод буболечки. Така че в BIOS можете да намерите двоични файлове с актуализации на микрокод (те се наслагват по време на зареждане, защото ROM не може да бъде презаписан). Съдържанието на тези двоични файлове е криптирано, което значително усложнява анализа (следователно конкретното съдържание на микрокода е известно само на тези, които го разработват), и е подписано за контрол на целостта и автентичността;
• AES ключ за дешифриране на съдържанието на актуализации на микрокод;
• хеш на публичния ключ RSA, който проверява подписа на актуализации на микрокод;
• Хеш на публичния ключ на RSA, който проверява подписа на разработените от Intel ACM (Authenticated Code Module) кодови модули, които процесорът може да изпълни преди стартирането на BIOS (hello microcode) или по време на неговата работа, когато настъпят някои събития.

Intel ME

Тази подсистема в нашия блог беше посветена на две статии. Спомнете си, че тази изпълнима среда е базирана на микроконтролера, вграден в чипсета и е най-скритата и привилегирована в системата.

Въпреки стелта, 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 технология за удостоверяване. Съдейки по краткото му описание в книгата [Разкрита технология за вградена сигурност на платформата, Глава Зареждане с цялост или не зареждане], той работи като надеждна верига за зареждане. И първата връзка в него е кодът за зареждане (микрокод) вътре в процесора, който се задейства от събитието 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 осигурява два режима на работа (и единият не пречи на другия, т.е. и двата режима могат да бъдат активирани в системата и двата могат да бъдат деактивирани).

Измерено зареждане

В режим Measured Boot (MB), всеки компонент за зареждане (започвайки с ROM за зареждане на процесора) „измерва“ следващия, използвайки възможностите на Trusted Platform Module (TPM). За тези, които не знаят, нека обясня.

TPM има PCR (Регистри за конфигурация на платформата), които записват резултата от операцията по хеширане съгласно формулата:

Тези. текущата PCR стойност зависи от предишната и тези регистри се нулират само когато системата се НУЛИРА.

По този начин, в MB режим, в даден момент от време, PCRs отразяват уникален (в рамките на възможностите на хеш операцията) идентификатор на кода или данните, които са били "измерени". Стойностите на PCR могат да се използват при криптиране на някои данни (TPM_Seal) операция. След това тяхното декриптиране (TPM_Unseal) ще бъде възможно само ако стойностите на PCR не са се променили в резултат на зареждането (т.е. нито един „измерен“ компонент не е променен).

Проверено зареждане

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

• изключване с изчакване от 1 минута до 30 минути (така че потребителят да има време да разбере защо компютърът му не се зарежда и, ако е възможно, да се опита да възстанови BIOS);
• незабавно изключване (така че потребителят да няма време да разбере и освен това да направи);
• продължаване на работата с право лице (случаят, когато няма време за безопасност, защото има по-важни неща за вършене).

Изборът на действие зависи от определената конфигурация на Intel BG (а именно от така наречената политика за прилагане), която се записва постоянно от доставчика на компютърната платформа в специално проектирано хранилище - предпазители на чипсет (FPFs). По-късно ще се спрем на този момент по-подробно.

В допълнение към конфигурацията, доставчикът генерира два RSA 2048 ключа и създава две структури от данни (показани на фигурата):

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

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

Когато погледнете снимката, веднага възникват съмнения относно необходимостта от толкова дълга верига за проверка - можеше да използвате един манифест. Защо да усложнявам?

Всъщност 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. Когато е изчистено, ако ACM модулът за стартиране на BG на SPI флаш паметта не бъде намерен, няма да се извърши надеждно зареждане. Ще бъде ненадеждно.

Вече написахме по-горе, че политиката за прилагане за режима 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 (така че ето защо Програмируем на място предпазители).

Той е чудесен за съхранение на конфигурация, защото:

• има еднократно програмируема област за съхранение на данни (само където е написана конфигурацията на Intel BG);
• само Intel ME може да го чете и програмира.

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

1. С помощта на Flash Image Tool (от Intel STK), създава изображение на фърмуера с дадена конфигурация на Intel BG като променливи в региона на Intel ME (така нареченото временно огледало за FPF);
2. Използвайки Flash Programming Tool (от Intel STK), записва това изображение в SPI флаш паметта на системата и затваря т.нар. режим на производство (в този случай съответната команда се изпраща на Intel ME).

В резултат на тези операции Intel ME ще ангажира към FPF дадените стойности от огледалото за FPF в региона ME, ще зададе разрешенията в SPI флаш дескриптори на стойностите, препоръчани от Intel (описани в началото на статия) и извършете НУЛИРАНЕ на системата.

Анализ на внедряването на 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 Йога 2 Pro
Хасуел, няма поддръжка

Lenovo U330p
Хасуел, няма поддръжка

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

Като пример да вземем изтегления от офиса. изображение на сайта на доставчика на SPI флаш памет за Gigabyte GA-H170-D3H (версия F4).

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

Първо, нека поговорим за действията на процесора, ако технологията Intel BG е активирана.

Не беше възможно да се намерят проби от декриптирания микрокод, следователно как се изпълняват описаните по-долу действия (в микрокод или в хардуер) е открит въпрос. Независимо от това, фактът, че съвременните процесори на Intel "могат" да изпълняват тези действия, е факт.

След излизане от състояние 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. Заглавната структура на този двоичен файл е типична за кодови модули, разработени от 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 стартиране ACM

В резултат на анализа на работата на този 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 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 (Независим доставчик на 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, подписан от Intel

0001 0000ч
PMCP
раздел с код на фърмуера Intel PMC, ARC, подписан от Intel

0002 0000ч
FTPR
Раздел с фърмуерен код на Intel TXE, x86, подписан от Intel

0007B000h
UCOD
Актуализации на микрокод на процесора, подписани от Intel

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

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

0025 8000ч
FTP
Раздел с фърмуерен код на Intel TXE, x86, подписан от Intel

0036 1000ч
IUNP
неизвестен

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

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

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

Е, сега да преминем към "горещото". Веднъж открихме, че на много системи SPI флаш дескрипторите имат разрешения за достъп до региони на SPI флаш памет, така че всички потребители на тази памет да могат както да пишат, така и да четат всеки регион. Тези. няма начин.

След проверка с помощната програма MEinfo (от Intel STK), видяхме, че режимът на производство на тези системи не е затворен, следователно предпазителите на чипсета (FPF) са оставени в неопределено състояние. Да, Intel BG не е нито активиран, нито деактивиран в такива случаи.

Говорим за следните системи (по отношение на Intel BG и това, което ще бъде описано по-нататък в статията, ще говорим за системи с процесорна микроархитектура Haswell и по-висока):

• всички продукти на Gigabyte;
• всички продукти на MSI;
• 21 модела лаптопи Lenovo и 4 модела сървъри Lenovo.

Разбира се, докладвахме находката на тези доставчици, както и на Intel.

Адекватна реакция последва само от Lenovoкойто признава проблема и пусна кръпка.

Gigabyte Изглежда, че са приели информация за уязвимостта, но не са коментирали по никакъв начин.

Комуникация с MSI напълно спря при наше искане да изпратим нашия публичен PGP ключ (за да им изпратим криптирано съобщение за сигурност). Те заявиха, че "са производител на хардуер и не произвеждат PGP ключове."

Но по-точно. Тъй като предпазителите са оставени в недефинирано състояние, потребителят (или нападателят) може сам да ги програмира (най-трудното е намерете Intel STK). Това изисква следните стъпки.

1. Стартирайте в Windows OS (по принцип описаните по-долу стъпки могат да се извършат и от 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, проверете с помощта на MEinfo, че регионът ME вече съдържа конфигурацията на Intel BG.

6. Използвайте Flash Programming Tool, за да затворите производствения режим.

7. Системата ще се рестартира, след което с помощта на MEinfo можете да проверите дали FPF вече са програмирани.

Тези действия завинаги активирайте Intel BG на тази система. Ще бъде невъзможно да отмените действието, което означава:

• само собственикът на частната част от основния ключ (т.е. този, който е активирал Intel BG) ще може да актуализира UEFI BIOS на тази система;
• ако върнете оригиналния фърмуер на тази система, например с помощта на програмист, той дори няма да се включи (следствие от политиката за прилагане в случай на грешка при проверка);
• за да се отървете от такъв UEFI BIOS, трябва да смените чипсета с програмиран FPF с „чист“ (т.е. да запоите отново чипсета, ако имате достъп до инфрачервена станция за запояване на цената на кола, или просто да смените дънната платка ).

За да разберете какво може да направи такъв руткит, трябва да оцените какво прави възможно изпълнението на вашия код в UEFI BIOS среда. Да речем, в най-привилегирования режим на процесора - SMM. Такъв руткит може да има следните свойства:

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

По този начин тази уязвимост позволява на атакуващия да:

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

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

Данни

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

Смекчаващи мерки

Доставчиците, които умишлено оставят производствения режим отворен, определено трябва да го затворят. Засега те само си затварят очите и новите системи Kaby Lake показват това.

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

Източник: www.habr.com