Pinagkakatiwalaang Pag-download ni Schrödinger. Intel Boot Guard

Iminumungkahi naming bumaba muli sa mababang antas at pag-usapan ang tungkol sa seguridad ng firmware para sa mga x86-compatible na computer platform. Sa pagkakataong ito, ang pangunahing sangkap ng pag-aaral ay ang Intel Boot Guard (hindi dapat ipagkamali sa Intel BIOS Guard!) - isang pinagkakatiwalaang teknolohiya ng BIOS boot na suportado ng hardware na maaaring permanenteng paganahin o hindi paganahin ng computer system vendor sa yugto ng produksyon. Buweno, pamilyar na sa amin ang recipe ng pananaliksik: hiwa-hiwain nang manipis ang pagpapatupad ng teknolohiyang ito gamit ang reverse engineering, ilarawan ang arkitektura nito, pinupunan ito ng mga hindi dokumentadong detalye, timplahan ito ng mga attack vector para tikman at ihalo. Magdagdag tayo ng gasolina sa kuwento kung paano ang isang bug na na-clone nang maraming taon sa paggawa ng ilang vendor ay nagbibigay-daan sa isang potensyal na umaatake na gamitin ang teknolohiyang ito upang lumikha ng isang nakatagong rootkit sa system na hindi maalis (kahit na may isang programmer).

Sa pamamagitan ng paraan, ang artikulo ay batay sa mga ulat na "On Guard of Rootkits: Intel BootGuard" mula sa kumperensya ZeroNights 2016 at ika-29 na pulong DefCon Russia (parehong pagtatanghal dito).

Firmware para sa isang computer platform na may Intel 64 architecture

Una, sagutin natin ang tanong: ano ang firmware ng isang modernong computer platform na may Intel 64 architecture? Siyempre, UEFI BIOS. Ngunit ang gayong sagot ay hindi magiging tumpak. Tingnan natin ang larawan, na nagpapakita ng desktop (laptop) na bersyon ng arkitektura na ito.

Ang batayan ay ang link:

• Processor (CPU, Central Processing Unit), na, bilang karagdagan sa mga pangunahing core, ay may built-in na graphics core (hindi sa lahat ng mga modelo) at isang memory controller (IMC, Integrated Memory Controller);
• Chipset (PCH, Platform Controller Hub), na naglalaman ng iba't ibang mga controller para sa pakikipag-ugnayan sa mga peripheral na device at pamamahala ng mga subsystem. Kabilang sa mga ito ay ang kilalang Intel Management Engine (ME), na mayroon ding firmware (Intel ME firmware).

Ang mga laptop, bilang karagdagan sa itaas, ay nangangailangan ng built-in na controller (ACPI EC, Advanced Control at Power Interface Embedded Controller), na responsable para sa pagpapatakbo ng power subsystem, touchpad, keyboard, Fn key (liwanag ng screen, dami ng tunog , backlight ng keyboard, atbp. ) at iba pang mga bagay. At mayroon din itong sariling firmware.

Kaya, ang kabuuan ng firmware sa itaas ay ang firmware ng platform ng computer (system firmware), na naka-imbak sa isang karaniwang memorya ng flash ng SPI. Upang ang mga gumagamit ng memorya na ito ay hindi malito kung nasaan ito, ang mga nilalaman ng memorya na ito ay nahahati sa mga sumusunod na rehiyon (tulad ng ipinapakita sa figure):

• UEFI BIOS;
• ACPI EC firmware (isang hiwalay na rehiyon ay lumitaw kasama ang Skylake processor microarchitecture (2015), ngunit sa-wild ay hindi pa namin nakikita ang mga halimbawa ng paggamit nito, kaya ang firmware ng built-in na controller ay kasama pa rin sa UEFI BIOS) ;
• Intel ME firmware;
• configuration (MAC address, atbp.) ng built-in na GbE (Gigabit Ethernet) network adapter;
• Ang mga Flash Descriptor ay ang pangunahing rehiyon ng flash memory na naglalaman ng mga pointer sa ibang mga rehiyon, pati na rin ang mga pahintulot na ma-access ang mga ito.

Ang master ng SPI bus, isang controller ng SPI na binuo sa chipset, kung saan na-access ang memorya na ito, ay may pananagutan sa pagtanggal ng access sa mga rehiyon (alinsunod sa mga tinukoy na pahintulot). Kung ang mga pahintulot ay nakatakda sa mga inirekomendang halaga ng Intel (para sa mga kadahilanang pangseguridad), ang bawat SPI flash user ay may ganap na access (magbasa/magsulat) sa kanilang rehiyon lamang. At ang iba ay read-only o hindi naa-access. Isang kilalang katotohanan: sa maraming system, ang CPU ay may ganap na access sa UEFI BIOS at GbE, read access lang sa mga flash descriptor, at walang access sa Intel ME region. Bakit sa marami, at hindi sa lahat? Ang inirerekomenda ay hindi kinakailangan. Sasabihin namin sa iyo nang mas detalyado sa susunod na artikulo.

Mga mekanismo para sa pagprotekta sa firmware ng platform ng computer mula sa pagbabago

Malinaw, ang firmware ng isang platform ng computer ay dapat na protektahan mula sa posibleng kompromiso, na magbibigay-daan sa isang potensyal na umaatake na magkaroon ng saligan dito (makaligtas sa mga pag-update/muling pag-install ng OS), i-execute ang kanilang code sa mga pinaka-privileged mode, atbp. At ang paghihigpit sa pag-access sa mga rehiyon ng flash memory ng SPI, siyempre, ay hindi sapat. Samakatuwid, upang maprotektahan ang firmware mula sa mga pagbabago, ginagamit ang iba't ibang mga mekanismo na tiyak sa bawat operating environment.

Kaya, ang Intel ME firmware ay nilagdaan upang kontrolin ang integridad at pagiging tunay, at sinusuri ng ME controller sa tuwing ito ay na-load sa ME UMA memory. Ang proseso ng pag-verify na ito ay napag-usapan na namin sa isa sa Artikulo, na nakatuon sa subsystem ng Intel ME.

At ang firmware ng ACPI EC, bilang panuntunan, ay sinusuri lamang para sa integridad. Gayunpaman, dahil sa katotohanan na ang binary na ito ay kasama sa UEFI BIOS, halos palaging napapailalim ito sa parehong mga mekanismo ng proteksyon na ginagamit ng UEFI BIOS. Pag-usapan natin sila.

Ang mga mekanismong ito ay maaaring nahahati sa dalawang kategorya.

Isulat ang proteksyon sa rehiyon ng UEFI BIOS

1. Pisikal na proteksyon ng mga nilalaman ng SPI flash memory na may isang write-protect jumper;
2. Pagprotekta sa projection ng UEFI BIOS region sa CPU address space gamit ang PRx chipset registers;
3. Pag-block sa mga pagtatangkang sumulat sa rehiyon ng UEFI BIOS sa pamamagitan ng pagbuo at pagproseso ng kaukulang SMI interrupt sa pamamagitan ng pagtatakda ng BIOS_WE/BLE at SMM_BWP bits sa mga rehistro ng chipset;
4. Ang isang mas advanced na bersyon ng proteksyon na ito ay ang Intel BIOS Guard (PFAT).

Bilang karagdagan sa mga mekanismong ito, maaaring bumuo at magpatupad ang mga vendor ng kanilang sariling mga hakbang sa seguridad (halimbawa, pagpirma sa mga kapsula na may mga update sa UEFI BIOS).

Mahalagang tandaan na sa isang partikular na system (depende sa vendor), hindi lahat ng mga mekanismo ng proteksyon sa itaas ay maaaring ilapat, maaaring hindi mailapat ang mga ito, o maaaring ipatupad ang mga ito sa isang mahinang paraan. Maaari kang magbasa nang higit pa tungkol sa mga mekanismong ito at ang sitwasyon sa kanilang pagpapatupad sa artikulong ito. Para sa mga interesado, inirerekumenda namin na basahin mo ang buong serye ng mga artikulo sa seguridad ng UEFI BIOS mula sa CodeRush.

UEFI BIOS authentication

Kapag pinag-uusapan natin ang mga pinagkakatiwalaang teknolohiya ng boot, ang unang naiisip ay Secure Boot. Gayunpaman, sa arkitektura ito ay idinisenyo upang i-verify ang pagiging tunay ng mga bahagi na panlabas sa UEFI BIOS (mga driver, bootloader, atbp.), at hindi ang firmware mismo.

Samakatuwid, ang Intel, sa mga SoC na may Bay Trail microarchitecture (2012), ay nagpatupad ng isang hardware na hindi pinagana na Secure Boot (Na-verify na Boot), na walang pagkakatulad sa nabanggit na teknolohiyang Secure Boot. Nang maglaon (2013), ang mekanismong ito ay pinahusay at inilabas sa ilalim ng pangalang Intel Boot Guard para sa mga desktop na may Haswell microarchitecture.

Bago ilarawan ang Intel Boot Guard, tingnan natin ang mga kapaligiran ng pagpapatupad sa arkitektura ng Intel 64, na, sa kumbinasyon, ang mga ugat ng tiwala para sa pinagkakatiwalaang teknolohiya ng boot na ito.

Intel CPU

Iminumungkahi ng Cap na ang processor ay ang pangunahing kapaligiran ng pagpapatupad sa arkitektura ng Intel 64. Bakit ito ang ugat ng tiwala? Lumalabas na ang dahilan kung bakit siya ganoon ay ang pagkakaroon ng mga sumusunod na elemento:

• Ang Microcode ROM ay isang non-volatile, non-rewritable memory para sa pag-iimbak ng microcode. Ito ay pinaniniwalaan na ang microcode ay ang pagpapatupad ng processor command system gamit ang pinakasimpleng mga tagubilin. Nangyayari din sa microcode mga bug. Kaya sa BIOS maaari kang makahanap ng mga binary na may mga update sa microcode (naka-overlay sa panahon ng boot, dahil hindi ma-overwritten ang ROM). Ang mga nilalaman ng mga binary na ito ay naka-encrypt, na lubhang nagpapalubha sa pagsusuri (samakatuwid, ang partikular na nilalaman ng microcode ay kilala lamang sa mga taong bumuo nito), at nilagdaan upang kontrolin ang integridad at pagiging tunay;
• AES key para sa pag-decrypting ng mga nilalaman ng microcode update;
• hash ng RSA public key na ginamit upang i-verify ang lagda ng mga update sa microcode;
• RSA public key hash, na nagbe-verify ng signature ng Intel-developed ACM (Authenticated Code Module) code modules, na maaaring ilunsad ng CPU bago ang BIOS execution (hello microcode) o sa panahon ng operasyon nito, kapag naganap ang ilang partikular na kaganapan.

Intel ME

Ang aming blog ay nakatuon sa subsystem na ito dalawa Artikulo. Alalahanin natin na ang executable environment na ito ay batay sa isang microcontroller na nakapaloob sa chipset at ito ang pinakanakatago at may pribilehiyo sa system.

Sa kabila ng pagiging lihim nito, ang Intel ME ay ugat din ng tiwala dahil mayroon itong:

• ME ROM - non-volatile, non-rewritable memory (walang ibinigay na paraan ng pag-update) na naglalaman ng start code, pati na rin ang SHA256 hash ng RSA public key, na nagpapatunay sa pirma ng Intel ME firmware;
• AES key para sa pag-iimbak ng lihim na impormasyon;
• access sa isang set ng mga piyus (FPFs, Field Programmable Fuses) na isinama sa chipset para sa permanenteng pag-imbak ng ilang impormasyon, kabilang ang tinukoy ng computer system vendor.

Intel Boot Guard 1.x

Isang maliit na disclaimer. Ang mga numero ng bersyon ng teknolohiya ng Intel Boot Guard na ginagamit namin sa artikulong ito ay arbitrary at maaaring walang kinalaman sa pagnunumero na ginamit sa panloob na dokumentasyon ng Intel. Bilang karagdagan, ang impormasyong ibinigay dito tungkol sa pagpapatupad ng teknolohiyang ito ay nakuha sa panahon ng reverse engineering, at maaaring maglaman ng mga kamalian kumpara sa detalye para sa Intel Boot Guard, na malamang na hindi mai-publish.

Kaya, ang Intel Boot Guard (BG) ay isang hardware-supported UEFI BIOS authentication verification technology. Sa paghusga sa maikling paglalarawan nito sa aklat [Platform Embedded Security Technology Revealed, chapter Boot with Integrity, or Not Boot], ito ay gumagana bilang isang pinagkakatiwalaang boot chain. At ang unang link dito ay ang boot code (microcode) sa loob ng CPU, na na-trigger ng RESET event (huwag malito sa RESET vector sa BIOS!). Nakahanap ang CPU ng code module na binuo at nilagdaan ng Intel (Intel BG startup ACM) sa SPI flash memory, nilo-load ito sa cache nito, nag-verify (nabanggit na sa itaas na ang CPU ay may hash ng public key na nagpapatunay sa ACM lagda) at magsisimula.

Ang module ng code na ito ay responsable para sa pag-verify ng isang maliit na panimulang bahagi ng UEFI BIOS - Initial Boot Block (IBB), na, naman, ay naglalaman ng pag-andar para sa pag-verify ng pangunahing bahagi ng UEFI BIOS. Kaya, pinapayagan ka ng Intel BG na i-verify ang pagiging tunay ng BIOS bago i-load ang OS (na maaaring isagawa sa ilalim ng pangangasiwa ng teknolohiyang Secure Boot).

Ang teknolohiya ng Intel BG ay nagbibigay ng dalawang operating mode (at ang isa ay hindi nakakasagabal sa isa pa, ibig sabihin, ang parehong mga mode ay maaaring paganahin sa system, o pareho ay maaaring hindi paganahin).

Sinukat na Boot

Sa Measured Boot (MB) mode, ang bawat boot component (simula sa CPU boot ROM) ay "nagsusukat" sa susunod gamit ang mga kakayahan ng TPM (Trusted Platform Module). Para sa mga hindi nakakaalam, hayaan mo akong magpaliwanag.

Ang TPM ay may mga PCR (Platform Configuration Registers), kung saan nakasulat ang resulta ng operasyon ng hashing ayon sa formula:

Yung. ang kasalukuyang halaga ng PCR ay nakasalalay sa nauna, at ang mga rehistrong ito ay na-reset lamang kapag ang sistema ay RESET.

Kaya, sa MB mode, sa ilang sandali, ang mga PCR ay nagpapakita ng isang natatanging (sa loob ng mga kakayahan ng operasyon ng hashing) na identifier ng code o data na "sinukat." Maaaring gamitin ang mga halaga ng PCR sa ilang operasyon ng pag-encrypt ng data (TPM_Seal). Pagkatapos nito, ang kanilang pag-decryption (TPM_Unseal) ay magiging posible lamang kung ang mga halaga ng PCR ay hindi nagbago bilang resulta ng paglo-load (ibig sabihin, walang isang "sinusukat" na bahagi ang nabago).

Na-verify na Boot

Ang pinakamasamang bagay para sa mga gustong baguhin ang UEFI BIOS ay ang Verified Boot (VB) mode, kung saan ang bawat bahagi ng boot ay cryptographically na nagpapatunay sa integridad at pagiging tunay ng susunod. At kung sakaling magkaroon ng error sa pag-verify, (isa sa) mangyayari:

• shutdown sa pamamagitan ng timeout mula 1 minuto hanggang 30 minuto (upang ang gumagamit ay may oras upang maunawaan kung bakit ang kanyang computer ay hindi nag-boot, at, kung maaari, sinusubukang ibalik ang BIOS);
• agarang pag-shutdown (upang ang gumagamit ay walang oras upang maunawaan, mas mababa ang gawin, anuman);
• patuloy na magtrabaho nang may kalmadong ekspresyon (sa kaso kapag walang oras para sa kaligtasan, dahil may mas mahahalagang bagay na dapat gawin).

Ang pagpili ng aksyon ay nakasalalay sa tinukoy na pagsasaayos ng Intel BG (ibig sabihin, sa tinatawag na patakaran sa pagpapatupad), na permanenteng naitala ng vendor ng platform ng computer sa isang espesyal na dinisenyo na imbakan - mga chipset fuse (FPF). Tatalakayin natin ang puntong ito nang mas detalyado sa ibang pagkakataon.

Bilang karagdagan sa configuration, ang vendor ay bumubuo ng dalawang RSA 2048 key at gumagawa ng dalawang istruktura ng data (ipinapakita sa figure):

1. Ang root key manifest ng vendor (KEYM, OEM Root Key Manifest), na naglalaman ng SVN (Security Version Number) ng manifesto na ito, ang SHA256 hash ng public key ng susunod na manifesto, ang RSA public key (i.e. ang pampublikong bahagi ng root key ng vendor) upang i-verify ang lagda ng manifesto na ito at ang mismong lagda;
2. IBB Manifest (IBBM, Initial Boot Block Manifest), na naglalaman ng SVN ng manifesto na ito, ang SHA256 hash ng IBB, ang pampublikong susi para sa pag-verify ng lagda ng manifesto na ito at ang mismong lagda.

Ang SHA256 hash ng OEM Root Key public key ay permanenteng naka-record sa mga chipset fuse (FPFs), tulad ng Intel BG configuration. Kung ang pagsasaayos ng Intel BG ay nagbibigay para sa pagsasama ng teknolohiyang ito, mula ngayon ang may-ari lamang ng pribadong bahagi ng OEM Root Key ang makakapag-update ng BIOS sa system na ito (ibig sabihin, magagawang muling kalkulahin ang mga manifest na ito), i.e. nagtitinda.

Kapag tinitingnan ang larawan, agad na bumangon ang mga pagdududa tungkol sa pangangailangan para sa napakahabang chain ng pag-verify - maaari sana silang gumamit ng isang manifest. Bakit ginagawang kumplikado ang mga bagay?

Sa katunayan, kaya binibigyan ng Intel ang vendor ng pagkakataong gumamit ng iba't ibang IBB key para sa iba't ibang linya ng mga produkto nito at isa bilang root key. Kung ang pribadong bahagi ng IBB key (kung saan nilagdaan ang pangalawang manifest) ay tumagas, ang insidente ay makakaapekto lamang sa isang linya ng produkto at hanggang sa makabuo lamang ang vendor ng bagong pares at isama ang mga muling nakalkulang manifest sa susunod na pag-update ng BIOS.

Ngunit kung ang root key (kung saan nilagdaan ang unang manifest) ay nakompromiso, hindi ito posibleng palitan; walang ibinigay na pamamaraan sa pagbawi. ang hash ng pampublikong bahagi ng key na ito ay naka-program sa FPF minsan at para sa lahat.

Configuration ng Intel Boot Guard

Ngayon tingnan natin ang pagsasaayos ng Intel BG at ang proseso ng paglikha nito. Kung titingnan mo ang kaukulang tab sa GUI ng Flash Image Tool utility mula sa Intel System Tool Kit (STK), mapapansin mo na ang Intel BG configuration ay may kasamang hash ng pampublikong bahagi ng root key ng vendor, isang pares ng hindi malinaw na mga halaga, atbp. Profile ng Intel BG.

Ang istraktura ng profile na ito:

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;
};

Sa pangkalahatan, ang pagsasaayos ng Intel BG ay isang napaka-flexible na entity. Isaalang-alang, halimbawa, ang Force_Boot_Guard_ACM flag. Kapag ito ay tinanggal, kung ang BG startup ACM module sa SPI flash ay hindi matagpuan, walang pinagkakatiwalaang boot na magaganap. Siya ay hindi mapagkakatiwalaan.

Naisulat na namin sa itaas na maaaring i-configure ang patakaran sa pagpapatupad para sa VB mode upang kung mayroong error sa pag-verify, magkakaroon ng hindi pinagkakatiwalaang pag-download.

Iwanan ang mga ganitong bagay sa pagpapasya ng mga vendor...

Ang GUI utility ay nagbibigay ng mga sumusunod na "ready-made" na mga profile:

Hindi.
rehimen
Описание

0
No_FVME
Hindi pinagana ang teknolohiya ng Intel BG

1
VE
Naka-enable ang VB mode, shutdown sa pamamagitan ng timeout

2
VME
ang parehong mga mode ay pinagana (VB at MB), shutdown sa pamamagitan ng timeout

3
VM
ang parehong mga mode ay pinagana, nang hindi pinapatay ang system

4
FVE
Pinagana ang VB mode, agarang pagsara

5
FVME
parehong pinagana ang mga mode, agarang pag-shutdown

Tulad ng nabanggit na, ang pagsasaayos ng Intel BG ay dapat na isulat nang isang beses at para sa lahat ng system vendor sa chipset fuses (FPFs) - isang maliit (ayon sa hindi na-verify na impormasyon, 256 bytes lamang) hardware na imbakan ng impormasyon sa loob ng chipset, na maaaring i-program. sa labas ng mga pasilidad ng produksyon ng Intel (kaya naman eksakto Field Programmable Mga piyus).

Ito ay mahusay para sa pag-iimbak ng configuration dahil:

• ay may isang minsanang-programmable na lugar para sa pag-iimbak ng data (eksaktong kung saan nakasulat ang pagsasaayos ng Intel BG);
• Ang Intel ME lang ang makakabasa at makakapagprogram nito.

Kaya, upang maitakda ang pagsasaayos para sa teknolohiya ng Intel BG sa isang partikular na sistema, ginagawa ng vendor ang sumusunod sa panahon ng produksyon:

1. Gamit ang utility ng Flash Image Tool (mula sa Intel STK), lumilikha ito ng imahe ng firmware na may ibinigay na pagsasaayos ng Intel BG sa anyo ng mga variable sa loob ng rehiyon ng Intel ME (ang tinatawag na pansamantalang salamin para sa mga FPF);
2. Gamit ang utility ng Flash Programming Tool (mula sa Intel STK), isinusulat nito ang larawang ito sa flash memory ng SPI ng system at isinasara ang tinatawag na. manufacturing mode (sa kasong ito, ang kaukulang command ay ipinadala sa Intel ME).

Bilang resulta ng mga operasyong ito, ibibigay ng Intel ME ang mga tinukoy na halaga mula sa salamin para sa mga FPF sa rehiyon ng ME hanggang sa mga FPF, itatakda ang mga resolusyon sa mga flash descriptor ng SPI sa mga halagang inirerekomenda ng Intel (inilarawan sa simula ng artikulo) at magsagawa ng system RESET.

Pagsusuri ng pagpapatupad ng Intel Boot Guard

Upang masuri ang pagpapatupad ng teknolohiyang ito gamit ang isang partikular na halimbawa, sinuri namin ang mga sumusunod na sistema para sa mga bakas ng teknolohiya ng Intel BG:

Sistema
Nota

Gigabyte GA-H170-D3H
Skylake, may suporta

Gigabyte GA-Q170-D3H
Skylake, may suporta

Gigabyte GA-B150-HD3
Skylake, may suporta

MSI H170A Gaming Pro
Skylake, walang suporta

Lenovo ThinkPad 460
Skylake, suportado, pinagana ang teknolohiya

Lenovo Yoga 2 Pro
Haswell, walang suporta

Lenovo U330p
Haswell, walang suporta

Ang ibig sabihin ng "suporta" ay ang pagkakaroon ng Intel BG startup ACM module, ang mga manifest na nabanggit sa itaas at ang kaukulang code sa BIOS, i.e. pagpapatupad para sa pagsusuri.

Bilang halimbawa, kunin natin ang na-download mula sa opisina. imahe ng website ng vendor ng flash memory ng SPI para sa Gigabyte GA-H170-D3H (bersyon F4).

Intel CPU boot ROM

Una sa lahat, pag-usapan natin ang mga aksyon ng processor kung pinagana ang teknolohiya ng Intel BG.

Hindi posibleng makahanap ng mga sample ng na-decrypt na microcode, kaya isang bukas na tanong kung paano ipinapatupad ang mga pagkilos na inilarawan sa ibaba (sa microcode o hardware). Gayunpaman, ito ay isang katotohanan na ang mga modernong processor ng Intel ay "maaaring" gawin ang mga pagkilos na ito.

Pagkatapos lumabas sa RESET state, ang processor (ang mga nilalaman ng flash memory ay nai-mapa na sa address space) ang FIT (Firmware Interface Table) na talahanayan. Madali itong hanapin; ang pointer dito ay nakasulat sa address na FFFF FFC0h.

Sa halimbawang isinasaalang-alang, ang halagang FFD6 9500h ay matatagpuan sa address na ito. Sa pamamagitan ng pag-access sa address na ito, nakikita ng processor ang FIT table, ang mga nilalaman nito ay nahahati sa mga talaan. Ang unang entry ay ang header ng sumusunod na istraktura:

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;
};

Para sa ilang hindi kilalang dahilan, ang checksum ay hindi palaging kinakalkula sa mga talahanayang ito (ang field ay naiwang zero).

Ang natitirang mga entry ay tumuturo sa iba't ibang mga binary na kailangang i-parse/isagawa bago isagawa ang BIOS, i.e. bago lumipat sa legacy na RESET vector (FFFF FFF0h). Ang istraktura ng bawat naturang entry ay ang mga sumusunod:

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

Sinasabi sa iyo ng field na EntryType ang uri ng block na itinuturo ng entry na ito. Alam namin ang ilang uri:

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

Ngayon ay malinaw na ang isa sa mga entry ay tumuturo sa lokasyon ng Intel BG startup ACM binary. Ang istraktura ng header ng binary na ito ay tipikal para sa mga module ng code na binuo ng Intel (mga ACM, mga update sa microcode, mga seksyon ng Intel ME code, ...).

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];
};

Nilo-load ng processor ang binary na ito sa cache nito, bini-verify ito at pinapatakbo ito.

Intel BG startup ACM

Bilang resulta ng pagsusuri sa gawain ng ACM na ito, naging malinaw na ginagawa nito ang sumusunod:

• tumatanggap ng configuration ng Intel BG mula sa Intel ME, na nakasulat sa mga chipset fuse (FPFs);
• hinahanap ang KEYM at IBBM na nagpapakita at nagpapatunay sa kanila.

Para mahanap ang mga manifest na ito, ginagamit din ng ACM ang FIT table, na may dalawang uri ng entry para isaad ang structure data (tingnan ang FIT_ENTRY_TYPES sa itaas).

Tingnan natin ang mga manifesto. Sa istruktura ng unang manifest, nakikita namin ang ilang hindi malinaw na constant, isang hash ng pampublikong key mula sa pangalawang manifest, at ang pampublikong OEM Root Key na nilagdaan bilang isang nested structure:

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];
};

Upang i-verify ang OEM Root Key na pampublikong key, naaalala namin na ginagamit namin ang SHA256 hash ng mga piyus, na sa puntong ito ay natanggap na mula sa Intel ME.

Lumipat tayo sa pangalawang manifesto. Binubuo ito ng tatlong istruktura:

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

Ang una ay naglalaman ng ilang mga pare-pareho:

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
};

Ang pangalawa ay naglalaman ng SHA256 hash ng IBB at ang bilang ng mga deskriptor na naglalarawan sa mga nilalaman ng IBB (ibig sabihin, kung saan kinakalkula ang hash):

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;
};

Ang mga deskriptor ng IBB ay sumusunod sa istrukturang ito, isa-isa. Ang kanilang mga nilalaman ay may sumusunod na format:

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

Ito ay simple: ang bawat descriptor ay naglalaman ng address/laki ng IBB chunk. Kaya, ang pagsasama-sama ng mga bloke na itinuro ng mga deskriptor na ito (sa pagkakasunud-sunod ng mga naglalarawan mismo) ay IBB. At, bilang panuntunan, ang IBB ay ang koleksyon ng lahat ng mga module ng SEC at PEI phase.

Ang pangalawang manifest ay kinukumpleto ng isang istraktura na naglalaman ng IBB public key (na-verify ng SHA256 hash mula sa unang manifest) at ang lagda ng manifest na ito:

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

Kaya, kahit na bago magsimulang mag-execute ang UEFI BIOS, ilulunsad ng processor ang ACM, na magpapatunay sa pagiging tunay ng mga nilalaman ng mga seksyon na may SEC at PEI phase code. Susunod, ang processor ay lumabas sa ACM, sumunod sa RESET vector at magsisimulang i-execute ang BIOS.

Ang na-verify na partition ng PEI ay dapat maglaman ng isang module na susuriin ang natitirang bahagi ng BIOS (DXE code). Ang module na ito ay binuo na ng IBV (Independent BIOS Vendor) o ng system vendor mismo. kasi Tanging ang mga sistema ng Lenovo at Gigabyte ang nasa aming pagtatapon at mayroong suporta sa Intel BG; tingnan natin ang code na kinuha mula sa mga system na ito.

UEFI BIOS module LenovoVerifiedBootPei

Sa kaso ng Lenovo, ito pala ay ang LenovoVerifiedBootPei module {B9F2AC77-54C7-4075-B42E-C36325A9468D}, na binuo ng Lenovo.

Ang trabaho nito ay hanapin (sa pamamagitan ng GUID) ang hash table para sa DXE at i-verify ang 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 module na BootGuardPei

Sa kaso ng Gigabyte, ito ay naging BootGuardPei module {B41956E1-7CA2-42DB-9562-168389F0F066}, na binuo ng AMI, samakatuwid, naroroon sa anumang AMI BIOS na may suporta sa Intel BG.

Ang operating algorithm nito ay medyo naiiba, gayunpaman, ito ay bumaba sa parehong bagay:

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;
}

Ang hash table na {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} na hinahanap nito ay may sumusunod na format:

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

Pag-usapan natin sandali ang tungkol sa isa pang pagpapatupad ng Intel Boot Guard, na natagpuan sa isang mas bagong sistema batay sa Intel SoC na may Apollo Lake microarchitecture - ASRock J4205-IT.

Bagama't ang bersyon na ito ay gagamitin lamang sa mga SoC (ang mga bagong system na may Kaby Lake processor microarchitecture ay patuloy na gumagamit ng Intel Boot Guard 1.x), ito ay malaking interes sa pag-aaral ng bagong opsyon sa arkitektura para sa mga platform ng Intel SoC, na nakakita ng mga makabuluhang pagbabago, halimbawa:

• ang mga rehiyon ng BIOS at Intel ME (o sa halip Intel TXE, ayon sa terminolohiya para sa Intel SoC) ay isa na ngayong rehiyon ng IFWI;
• kahit na pinagana ang Intel BG sa platform, ang mga istruktura tulad ng FIT, KEYM, IBBM ay hindi natagpuan sa flash memory;
• bilang karagdagan sa mga TXE at ISH core (x86), isang ikatlong core ay idinagdag sa chipset (ARC muli, sa pamamagitan ng paraan) - PMC (Power Management Controller), na nauugnay sa pagtiyak ng operability ng power subsystem at pagsubaybay sa pagganap.

Ang nilalaman ng bagong rehiyon ng IFWI ay isang set ng mga sumusunod na module:

Bias
pangalan
Описание

0000 2000h
SMIP
isang partikular na configuration ng platform, na nilagdaan ng vendor

0000 6000h
RBEP
Seksyon ng Intel TXE firmware code, x86, nilagdaan ng Intel

0001 0000h
PMCP
Seksyon ng firmware code ng Intel PMC, ARC, nilagdaan ng Intel

0002 0000h
FTPR
Seksyon ng Intel TXE firmware code, x86, nilagdaan ng Intel

0007 B000h
UCOD
mga update sa microcode para sa CPU, na nilagdaan ng Intel

0008 0000h
IBBP
UEFI BIOS, SEC/PEI phases, x86, nilagdaan ng vendor

0021 8000h
ISHC
Seksyon ng Intel ISH firmware code, x86, na nilagdaan ng vendor

0025 8000h
NFTP
Seksyon ng Intel TXE firmware code, x86, nilagdaan ng Intel

0036 1000h
IUNP
hindi alam

0038 1000h
OBBP
UEFI BIOS, DXE phase, x86, unsigned

Sa panahon ng pagsusuri ng firmware ng TXE, naging malinaw na pagkatapos ng isang RESET, pinapanatili ng TXE ang processor sa ganitong estado hanggang sa ihanda nito ang mga pangunahing nilalaman ng address space para sa CPU (FIT, ACM, RESET vector ...). Bukod dito, inilalagay ng TXE ang data na ito sa SRAM nito, pagkatapos nito ay pansamantalang binibigyan ang processor ng access doon at "ilalabas" ito mula sa RESET.

Sa pagbabantay laban sa mga rootkit

Well, ngayon ay lumipat tayo sa "mainit" na bagay. Minsan naming natuklasan na sa maraming mga system, ang mga flash descriptor ng SPI ay naglalaman ng mga pahintulot na ma-access ang mga rehiyon ng SPI flash memory upang ang lahat ng mga gumagamit ng memorya na ito ay maaaring magsulat at magbasa ng anumang rehiyon. Yung. walang paraan.

Matapos suriin ang MEinfo utility (mula sa Intel STK), nakita namin na ang manufacturing mode sa mga system na ito ay hindi sarado, samakatuwid, ang mga chipset fuse (FPFs) ay naiwan sa isang hindi natukoy na estado. Oo, ang Intel BG ay hindi naka-on o naka-off sa mga ganitong kaso.

Pinag-uusapan natin ang tungkol sa mga sumusunod na sistema (tungkol sa Intel BG at kung ano ang ilalarawan mamaya sa artikulo, pag-uusapan natin ang tungkol sa mga system na may Haswell processor microarchitecture at mas mataas):

• lahat ng mga produkto ng Gigabyte;
• lahat ng produkto ng MSI;
• 21 modelo ng Lenovo laptop at 4 na modelo ng Lenovo server.

Siyempre, iniulat namin ang pagtuklas sa mga vendor na ito, gayundin sa Intel.

Ang isang sapat na reaksyon ay nagmula lamang sa Lenovona nakakilala sa problema at naglabas ng patch.

Gigabyte Tila tinanggap nila ang impormasyon tungkol sa kahinaan, ngunit hindi nagkomento sa anumang paraan.

Komunikasyon sa MSI ganap na natigil sa aming kahilingang ipadala ang iyong pampublikong PGP key (upang magpadala sa kanila ng security advisory sa naka-encrypt na form). Sinabi nila na sila ay "isang tagagawa ng hardware at hindi gumagawa ng mga PGP key."

Ngunit dumating tayo sa punto. Dahil ang mga piyus ay naiwan sa isang hindi tinukoy na estado, ang user (o umaatake) ay maaaring mag-program ng mga ito nang nakapag-iisa (ang pinakamahirap na bagay ay hanapin ang Intel STK). Upang gawin ito, kailangan mong kumpletuhin ang mga sumusunod na hakbang.

1. Mag-boot sa Windows OS (sa pangkalahatan, ang mga aksyon na inilarawan sa ibaba ay maaari ding gawin sa ilalim ng Linux, kung bumuo ka ng isang analogue ng Intel STK para sa nais na OS). Gamit ang MEinfo utility, siguraduhin na ang mga piyus ay hindi naka-program sa system na ito.

2. Basahin ang mga nilalaman ng flash memory gamit ang Flash Programming Tool.

3. Buksan ang nabasang larawan gamit ang anumang tool sa pag-edit ng UEFI BIOS, gawin ang mga kinakailangang pagbabago (ipakilala ang isang rootkit, halimbawa), lumikha/mag-edit ng mga umiiral na istruktura ng KEYM at IBBM sa rehiyon ng ME.

Itinatampok ng larawan ang pampublikong bahagi ng RSA key, na ang hash ay ipo-program sa mga piyus ng chipset kasama ang natitirang configuration ng Intel BG.

4. Gamit ang Flash Image Tool, bumuo ng bagong firmware na imahe (sa pamamagitan ng pagtatakda ng Intel BG configuration).

5. Sumulat ng bagong imahe sa flash memory gamit ang Flash Programming Tool, at i-verify gamit ang MEinfo na ang ME region ay naglalaman na ngayon ng Intel BG configuration.

6. Gamitin ang Flash Programming Tool upang isara ang manufacturing mode.

7. Magre-reboot ang system, pagkatapos nito ay maaari mong gamitin ang MEinfo upang i-verify na ang mga FPF ay naka-program na ngayon.

Ang mga pagkilos na ito magpakailanman paganahin ang Intel BG sa system na ito. Ang pagkilos ay hindi maaaring bawiin, na nangangahulugang:

• Tanging ang may-ari ng pribadong bahagi ng root key (i.e., ang nagpagana ng Intel BG) ang makakapag-update ng UEFI BIOS sa system na ito;
• kung ibabalik mo ang orihinal na firmware sa system na ito, halimbawa, gamit ang isang programmer, hindi rin ito mag-on (isang kinahinatnan ng patakaran sa pagpapatupad kung sakaling magkaroon ng error sa pag-verify);
• upang maalis ang naturang UEFI BIOS, kailangan mong palitan ang chipset ng mga naka-program na FPF ng isang "malinis" (ibig sabihin, i-resolder ang chipset kung mayroon kang access sa isang infrared soldering station ang presyo ng isang kotse, o palitan lang ang motherboard ).

Upang maunawaan kung ano ang magagawa ng naturang rootkit, kailangan mong suriin kung ano ang ginagawang posible upang maisagawa ang iyong code sa kapaligiran ng UEFI BIOS. Sabihin natin, sa pinaka-pribilehiyo na mode ng processor - SMM. Ang nasabing rootkit ay maaaring may mga sumusunod na katangian:

• isinagawa nang kahanay sa OS (maaari mong i-configure ang pagproseso upang makabuo ng isang SMI interrupt, na ma-trigger ng isang timer);
• magkaroon ng lahat ng mga pakinabang ng pagiging nasa SMM mode (buong pag-access sa mga nilalaman ng RAM at mga mapagkukunan ng hardware, lihim mula sa OS);
• Ang program code ng rootkit ay maaaring i-encrypt at i-decrypt kapag inilunsad sa SMM mode. Ang anumang data na available lamang sa SMM mode ay maaaring gamitin bilang isang encryption key. Halimbawa, isang hash mula sa isang hanay ng mga address sa SMRAM. Para makuha ang key na ito, kakailanganin mong makapasok sa SMM. At ito ay maaaring gawin sa dalawang paraan. Hanapin ang RCE sa SMM code at samantalahin ito, o idagdag ang iyong sariling SMM module sa BIOS, na imposible dahil pinagana namin ang Boot Guard.

Kaya, ang kahinaang ito ay nagbibigay-daan sa isang umaatake na:

• lumikha ng isang nakatagong, hindi matatanggal na rootkit ng hindi kilalang layunin sa system;
• isagawa ang iyong code sa isa sa mga chipset core sa loob ng Intel SoC, ibig sabihin, sa Intel ISH (tingnang mabuti ang larawan).

Bagama't ang mga kakayahan ng subsystem ng Intel ISH ay hindi pa nasusuri, lumilitaw na ito ay isang kawili-wiling vector ng pag-atake para sa Intel ME.

Natuklasan

1. Ginawang posible ng pag-aaral na makakuha ng teknikal na paglalarawan ng pagpapatakbo ng teknolohiya ng Intel Boot Guard. Minus ng ilang mga lihim sa seguridad ng Intel sa pamamagitan ng obscurity model.
2. Ang isang senaryo ng pag-atake ay ipinakita na nagbibigay-daan sa iyo upang lumikha ng isang hindi mai-install na rootkit sa system.
3. Nakita namin na ang mga modernong Intel processor ay may kakayahang magsagawa ng maraming proprietary code bago pa man magsimulang tumakbo ang BIOS.
4. Ang mga platform na may arkitektura ng Intel 64 ay nagiging mas hindi na angkop para sa pagpapatakbo ng libreng software: pag-verify ng hardware, pagtaas ng bilang ng mga proprietary na teknolohiya at subsystem (tatlong core sa SoC chipset: x86 ME, x86 ISH at ARC PMC).

Pagpapagaan

Ang mga vendor na sadyang iwanang bukas ang manufacturing mode ay dapat tiyaking isasara ito. Sa ngayon, ang kanilang mga mata lamang ang nakapikit, at ang mga bagong sistema ng Kaby Lake ay nagpapakita nito.

Maaaring i-disable ng mga user ang Intel BG sa kanilang mga system (na madaling kapitan sa inilarawang kahinaan) sa pamamagitan ng pagpapatakbo ng Flash Programming Tool na may parameter na -closemnf. Una, dapat mong tiyakin (gamit ang MEinfo) na ang pagsasaayos ng Intel BG sa rehiyon ng ME ay nagbibigay para sa pag-off ng teknolohiyang ito pagkatapos ng programming sa mga FPF.

Pinagmulan: www.habr.com