🥇Давераная загрузка Шрэдынгера. Intel Boot Guard ProHoster

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

Дарэчы, у аснове артыкула – даклады "На варце руткітаў: Intel BootGuard" з канферэнцыі ZeroNights 2016 і 29-й сустрэчы DefCon Belarus (абедзве прэзентацыі тут).

Прашыўка кампутарнай платформы з архітэктурай 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

Фізічная абарона змесціва SPI флэш-памяці write-protect джамперам;
Абарона праекцыі рэгіёна UEFI BIOS у адраснай прасторы CPU з дапамогай PRx рэгістраў чыпсэта;
Блакаванне спроб запісу ў рэгіён UEFI BIOS генерацыяй і апрацоўкай адпаведнага перапынення SMI шляхам выстаўлення бітаў BIOS_WE/BLE і SMM_BWP у рэгістрах чыпсэта;
Больш прасунуты варыянт такой абароны - 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. Мяркуючы па яе невялікім апісанні ў кнізе, працуе яна як ланцужок даверанай загрузкі. І першае звяно ў ёй – загрузны код (мікракод) усярэдзіне 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 (MB) кожны загрузны кампанент (пачынальна з CPU boot ROM) "вымярае" наступны, выкарыстоўваючы магчымасці TPM (Trusted Platform Module). Для тых, хто не ў курсе, растлумачым.

У 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 (а менавіта, ад т.зв. enforcement policy), якая вендарам кампутарнай платформы перманентна запісваецца ў спецыяльна прызначанае сховішча – фьюзы чыпсэта (FPF-ы). Больш падрабязна на гэтым моманце спынімся пазней.

Акрамя канфігурацыі, вендар генеруе два ключа RSA 2048 і стварае дзве структуры дадзеных (намалявана на малюнку):

Маніфест каранёвага ключа вендара (KEYM, OEM Root Key Manifest), у які кладзе SVN (Security Version Number) гэтага маніфесту, SHA256 хэш публічнага ключа наступнага маніфеста, публічны ключ RSA (г.зн. публічную частку каранёвага ключа вендара маніфесту і сам подпіс;
Маніфест 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 (таму менавіта Праграмуемы па полі Fuses).

Яно выдатна падыходзіць для захоўвання канфігурацыі, паколькі:

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

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

З дапамогай утыліты Flash Image Tool (з Intel STK) стварае выяву прашыўкі з зададзенай канфігурацыяй Intel BG у выглядзе зменных усярэдзіне рэгіёна Intel ME (т.зв. часавае люстэрка для FPF-ов);
З дапамогай утыліты 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, якія прызналі праблему і выпусцілі патч.

Гігабайт накшталт і прынялі інфармацыю аб уразлівасці, але ніяк не пракаментавалі.

Зносіны з 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.

Высновы

Даследаванне дазволіла атрымаць тэхнічнае апісанне працы тэхналогіі Intel Boot Guard. Мінус пару таямніц у Intel-аўскай мадэлі security through obscurity.
Прадстаўлены сцэнар нападу, які дазваляе стварыць у сістэме невыдаляльны руткіт.
Мы ўбачылі, што сучасныя працэсары Intel здольныя выканаць шмат прапрыетарнага кода яшчэ да пачатку працы BIOS.
Платформы з архітэктурай Intel 64 становяцца ўсё меней прыдатнымі для запуску вольнага ПЗ: апаратная верыфікацыя, які павялічваецца лік прапрыетарных тэхналогій і падсістэм (тры ядра ў чыпсэце SoC: x86 ME, x86 ISH і ARC PMC).

Змякчэнне наступстваў

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

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

Крыніца: habr.com

Давераная загрузка Шрэдынгера. Intel Boot Guard