Ngarkesa e besueshme e Schrödinger-it. Intel Boot Guard

Të ofrojmë përsëri të zbresim në nivelin bazë dhe të flasim për sigurinë e firmware-eve të platformave kompjuterike të përshtatshme për x86. Këtë herë, përbërësi kryesor i hulumtimit është Intel Boot Guard (mos ngatërroni me Intel BIOS Guard!) – një teknologji e mbështetur nga hardueri për ngarkimin e besueshëm të BIOS-it, e cila mund të aktivizohet ose çaktivizohet nga prodhuesi i sistemit kompjuterik gjatë procesit të prodhimit. Ndërsa recetën e hulumtimit tashmë e njohim: të ndajmë me hollësi implementimin e kësaj teknologjie përmes inxhinierisë së kundërt, të përshkruajmë arkitekturën e saj, duke e mbushur atë me detaje të pa dokumentuara, dhe ta përziejmë me vektorë sulmesh. Do të shtojmë zjarrin me një tregim se si një gabim i klonuar gjatë prodhimit nga disa prodhues lejon një sulmues të mundshëm të përdorë këtë teknologji për të krijuar një rootkit të fshehur në sistem që nuk mund të fshihet (madje as nga programatori).

Përveç kësaj, thelbi i artikullit është raportet "Në mbrojtje të rootkiteve: Intel BootGuard" nga konferenca ZeroNights 2016 dhe takimi i 29-të DefCon Russia (të dyja prezantimet këtu).

Firmware e platformës kompjuterike me arkitekturë Intel 64

Së pari, le të përgjigjemi në pyetjen: çfarë është firmware-i i një platforme kompjuterike moderne me arkitekturë Intel 64? Sigurisht, UEFI BIOS. Por kjo përgjigje do të ishte jo e saktë. Le të shohim figurën, e cila tregon variantin desktop (laptop) të kësaj arkitekture.

Baza e saj është lidhja:

• Procesorin (CPU, Njësia Qendrore e Përpunimit), në të cilin, përveç bërthamave themelore, është integruar një njësi grafike (jo në të gjitha modelet) dhe një kontrollues memorjeje (IMC, Kontrolluesi i Integruar i Memorjes);
• Çipsetin (PCH, Qendra e Kontrollit të Platformës), që përmban kontrollues të ndryshëm për të bashkëpunuar me pajisjet periferike dhe për të menaxhuar nën-sistemet. Mes tyre është e njohura Intel Management Engine (ME), e cila gjithashtu ka firmware (Intel ME firmware).

Laptopët, përveç asaj që përmenda më parë, parashikojnë praninë e një kontrolluesi të integruar (ACPI EC, Kontrolleri i Integruar i Fuqisë dhe Kontrollit të Avancuar), i cili është përgjegjës për funksionimin e nën-sistemit të energjisë, pad-ës, tastierës, çelësave Fn (ndriçimi i ekranit, volumi i zërit, ndriçimi i tastierës etj.) dhe të tjera. Dhe ai gjithashtu ka firmware-in e tij.

Pra ndodhi, kombinimi i firmuerave të përmendura më lart është firmueri i platformës kompjuterike (system firmware), i cili ruhet në memorien e përbashkët SPI flash. Për të mos u ngatërruar përdoruesit e kësaj memorie, përmbajtja e saj është e ndarë në rajone të ndryshme (siç tregohet në figurë):

• UEFI BIOS;
• firmuara ACPI EC (një rajon i veçantë u shfaq me mikroarkitekturën e procesorit Skylake (viti 2015), por deri më tani nuk kemi parë shembuj të përdorimit të tij, kështu që firmuara e kontrolluesit të integruar ende bëhet pjesë e UEFI BIOS);
• firmuara Intel ME;
• konfigurimi (MAC-adresa etj.) i adapterit të integruar të rrjetit GbE (Gigabit Ethernet);
• deshkrimet e flashit (Flash Descriptors) – rajoni kryesor i flashit, i cili përmban treguesit për rajonet e tjera, si dhe lejet për qasje në to.

Ndahja e aksesit në rajone (në përputhje me lejet e dhëna) bëhet nga master i shinës SPI – kontrolluesi SPI i integruar në çip, përmes të cilit realizohet qasja në këtë memorie. Nëse lejet janë vendosur në vlerat e rekomanduara (për arsyet e sigurisë) nga kompania Intel, çdo përdorues i flashit SPI ka qasje të plotë (lexim/shkruarje) vetëm në rajonin e tij. Të tjerët – janë ose vetëm për lexim, ose të paarritshëm. Një fakt i njohur: në shumë sisteme, CPU ka qasje të plotë në UEFI BIOS dhe GbE, qasje leximi vetëm në përshkrimet e flashit, ndërsa në rajonin Intel ME nuk ka qasje fare. Pse në shumë, e jo në të gjitha? Ajo që rekomandohet, nuk është domosdoshmërisht e detyrueshme. Më shumë do të flasim në vazhdim të artikullit.

Mekanizmat e mbrojtjes së firmuerit të platformës kompjuterike nga modifikimi

Çështja është se firmuara e platformës kompjuterike duhet të mbrohet nga mundësia e kompromitimit, e cila do të lejonte një sulmues potencial të ngjitej brenda saj (të kalonte përditësimet/rinstalimet e OS), të ekzekutonte kodin e tij në regjimet më të privilegjuara, etj. Dhe ndarja e aksesit në rajonet e flashit SPI, sigurisht, nuk është e mjaftueshme. Prandaj, për mbrojtjen e firmuerit nga modifikimet, përdoren mekanizma të ndryshëm, specifikë për çdo ambient ekzekutimi.

Kështu, firmuara Intel ME është nënshkruar për kontrollin e integritetit dhe autentikitetit, dhe verifikohet nga kontrolluesi ME në çdo ngarkim në memorien ME UMA. Ky proces verifikimi është shqyrtuar tashmë nga ne në një të artikull, e dedikuar nën-sistemit Intel ME.

Firmware ACPI EC, zakonisht kontrollohet vetëm për integritet. Megjithatë, për shkak se ky binar përfshihet në UEFI BIOS, pothuajse gjithmonë i nënshtrohet të njëjtat mekanizma mbrojtjeje që përdor UEFI BIOS. Këto do t'i diskutojmë.

Këta mekanizma mund të ndahen në dy kategori.

Mbrojtja nga shkruajtja në regjionin UEFI BIOS

1. Mbrojtja fizike e përmbajtjes së memorjes SPI flash përmes jumper-it write-protect;
2. Mbrojtja e projektimit të regjionit UEFI BIOS në hapësirën adresore të CPU-së duke përdorur regjistrat PRx të çipit;
3. Bllokimi i përpjekjeve për të shkruar në regjionin UEFI BIOS përmes gjenerimit dhe përpunimit të një ndërprerjeje përkatëse SMI duke vendosur bitet BIOS_WE/BLE dhe SMM_BWP në regjistrat e çipit;
4. Një variant më i avancuar i kësaj mbrojtjeje është Intel BIOS Guard (PFAT).

Përveç këtyre mekanizmave, shitësit mund të zhvillojnë dhe aplikojnë masa të tyre të sigurisë (për shembull, nënshkrimi i kapsulave me përditësimet e UEFI BIOS).

Është e rëndësishme të theksohet se në një sistem konkret (varet nga shitësi) mund të mos aplikohet asnjë nga mekanizmat e mësipërm të mbrojtjes, mund të mos aplikohen fare, ose mund të jenë implementuar në mënyrë të dobët. Më shumë për këto mekanizma dhe situatën e realizimit të tyre mund të lexoni në këto artikuj. Ata që janë të interesuar rekomandojmë të njohin të gjithë ciklin e artikujve mbi sigurinë e UEFI BIOS nga CodeRush.

Verifikimi i autenticitetit të UEFI BIOS

Kur flasim për teknologjitë e ngarkesës së besueshme, gjëja e parë që të vjen në mendje është Secure Boot. Megjithatë, arktikturalisht ai është i destinuar për të verifikuar autenticitetin e komponentëve të jashtëm, për hirtë të UEFI BIOS, (drajverë, boot-a etj.), dhe jo vetë firmware-in.

Prandaj, kompania Intel në SoC-të me mikroarkitekturë Bay Trail (viti 2012) implementoi Secure Boot fizikisht të pakthyeshëm (Verified Boot), i cili nuk ka asgjë të përbashkët me teknologjinë e mësipërme Secure Boot. Më vonë (viti 2013) ky mekanizëm u përmirësua dhe me emrin Intel Boot Guard u lëshua për desktopët me mikroarkitekturë Haswell.

Para se të përshkruajmë Intel Boot Guard, le të shqyrtojmë ambientet e ekzekutimit në arkitekturën Intel 64, të cilat, përveç kësaj, janë rrënjët e besueshmërisë për këtë teknologji të ngarkesës së besueshme.

Intel CPU

Kapiteni sugjeron se procesori është ambienti kryesor i ekzekutimit në arkitekturën Intel 64. Pse ai është rrënjët e besueshmërisë? Duket se kjo e bën atë atë që ka elementët e mëposhtëm:

• Microcode ROM — memorie energiei independente, neefectuată de scriere, pentru stocarea microcodului. Se consideră că microcodul este o implementare a sistemului de comenzi al procesorului pe instrucțiuni de bază. În microcod există de asemenea bug-uri. Așa că în BIOS se pot găsi binare cu actualizări ale microcodului (acestea se aplică în timpul încărcării, deoarece ROM-ul nu poate fi rescris). Conținutul acestor binare este criptat, ceea ce complică semnificativ analiza (prin urmare, conținutul specific al microcodului este cunoscut doar de cei care îl dezvoltă) și este semnat, pentru a verifica integritatea și autenticitatea;
• cheia AES pentru decriptarea conținutului actualizărilor microcodului;
• hash-ul cheii publice RSA, care verifică semnătura actualizărilor microcodului;
• hash-ul cheii publice RSA, care verifică semnătura modulelor de cod autentificate ACM (Authenticated Code Module) dezvoltate de Intel, pe care CPU le poate lansa înainte de execuția BIOS-ului (salut microcodului) sau în timpul funcționării sale, în cazul apariției anumitor evenimente.

Intel ME

Acest subsystem a fost dedicat în blogul nostru timp de două artikulli. Să ne amintim că acest mediu executabil este bazat pe un microcontroler încorporat în chipset și este cel mai ascuns și privilegiat din sistem.

În ciuda discreției sale, Intel ME este de asemenea rădăcina încrederii, deoarece are:

• ME ROM — memorie energiei independente, neefectuată de scriere (metode de actualizare nu sunt prevăzute), care conține codul de pornire, precum și hash-ul SHA256 al cheii publice RSA, care verifică semnătura firmware-ului Intel ME;
• cheia AES pentru stocarea informațiilor secrete;
• acces la setul integrat de fuse-uri (FPFs, Field Programmable Fuses) din chipset pentru stocarea permanentă a unor informații, inclusiv cele specificate de furnizorul sistemului computerizat.

Intel Boot Guard 1.x

O scurtă avertizare. Numerele versiunilor tehnologiei Intel Boot Guard pe care le folosim în acest articol sunt condiționale și pot să nu aibă nimic în comun cu numărătoarea utilizată în documentația internă a companiei Intel. De asemenea, informațiile prezentate aici despre implementarea acestei tehnologii au fost obținute prin inginerie inversă și pot conține inexactități în comparație cu specificația Intel Boot Guard, care probabil că nu va fi publicată niciodată.

Pra, Intel Boot Guard (BG) është një teknologji e verifikimit të autencitetit të BIOS UEFI e mbështetur nga hardueri. Sipas përshkrimit të saj të shkurtër në librin [Platform Embedded Security Technology Revealed, kapitulli Boot with Integrity, or Not Boot], ajo funksionon si një zinxhir besimi për ngarkim. Dhe elementi i parë në këtë zinxhir është kodi i ngarkimit (mikrokodi) brenda CPU, i cili aktivizohet nga ngjarja RESET (mos e ngatërroni me vektorin RESET në BIOS!). CPU gjen në memorjen flakë SPI një modul kodi të dizajnuar dhe të nënshkruar nga Intel (Intel BG startup ACM), e ngarkon në cache dhe e verifikon (siç u përmend më lart, CPU ka një hash të çelësit publik, me të cilin kontrollohet nënshkrimi i ACM) dhe e aktivizon.

Ky modul kodi është përgjegjës për verifikimin e një pjese të vogël fillestare të BIOS UEFI — Initial Boot Block (IBB), e cila nga ana e saj përmban funksionalitetin për verifikimin e pjesës kryesore të BIOS UEFI. Kështu, Intel BG lejon të sigurohet autenciteti i BIOS para ngarkimit të OS (e cila mund të funksionojë nën mbikëqyrjen e teknologjisë Secure Boot).

Teknologjia Intel BG parashikon dy regjime funksionimi (dhe njëri nuk pengon tjetrin, dmth të dy regjimet mund të jenë aktive në sistem, ose të dy të jenë të çaktivizuar).

Measured Boot

Në regjimin Measured Boot (MB), çdo komponent ngarkimi (duke filluar nga CPU boot ROM) "mat" tjetrin, duke përdorur mundësitë e TPM (Trusted Platform Module). Për ata që nuk janë në dijeni, le të sqarojmë.

TPM ka PCR-të (Platform Configuration Registers), në të cilat regjistrohet rezultati i operacionit të hashing sipas formulës:

Dmth, vlera aktuale e PCR varet nga e mëparshmja, duke u zerozuar këto regjistra vetëm në rastin e RESET-it të sistemit.

Kështu, në regjimin MB në një moment të caktuar, PCR-të pasqyrojnë një identifikues unik (brenda mundësive të operacionit të hashing) të kodit ose të dhënave që janë "matur". Vlerat e PCR mund të përdoren gjatë operacionit të enkriptimit të disa të dhënave (TPM_Seal). Pas kësaj, dekriptimi i tyre (TPM_Unseal) do të jetë i mundur vetëm në rast se vlerat e PCR gjatë ngarkimit nuk janë ndryshuar (dmth, asnjë "komponent i matur" nuk është modifikuar).

Verified Boot

Më e frikshme për ata që pëlqejnë të modifikojnë BIOS UEFI është regjimi Verified Boot (VB), ku çdo komponent ngarkimi kontrollon në mënyrë kriptografike integritetin dhe autencitetin e tjetrit. Në rastin e një gabimi në verifikim, ndodh (një nga):

• ndarje me kohëzgjatje nga 1 minut deri në 30 minuta (në mënyrë që përdoruesi të kuptojë arsyen pse kompjuteri i tij nuk ngarkohet dhe, nëse është e mundur, përpiqet të rikuperojë BIOS-in);
• ndarje e menjëhershme (në mënyrë që përdoruesi të mos ketë kohë të kuptojë asgjë dhe, për më tepër, të bëjë diçka);
• vazhdimi i punës me qetësi (rasti kur nuk është për siguri, sepse ka çështje më të rëndësishme).

Zgjedhja e veprimit varet nga konfigurimi i caktuar të Intel BG (veçanërisht, nga e ashtuquajtura politika e zbatimit), e cila regjistrohet përherë nga shitësi i platformës kompjuterike në një magazinë të veçantë - fuse të chipset-it (FPF). Më shumë rreth kësaj do të diskutojmë më vonë.

Përveç konfigurimit, shitësi gjeneron dy çelësa RSA 2048 dhe krijon dy struktura të të dhënave (të ilustruar në figurë):

1. Manifesti i çelësit themelor të shitësit (KEYM, OEM Root Key Manifest), në të cilin vendos SVN (Numri i Versionit të Sigurisë) të këtij manifesti, SHA256 hash të çelësit publik të manifestit të ardhshëm, çelësi publik RSA (dmth. pjesa publike e çelësit themelor të shitësit) për verifikimin e nënshkrimit të këtij manifesti dhe vetë nënshkrimin;
2. Manifesti IBB (IBBM, Initial Boot Block Manifest), në të cilin vendos SVN të këtij manifesti, SHA256 hash IBB, çelësin publik për verifikimin e nënshkrimit të këtij manifesti dhe vetë nënshkrimin.

SHA256 hash i çelësit publik OEM Root Key regjistrohet përherë në fuse të chipset-it (FPF), ashtu si konfigurimi i Intel BG. Nëse konfigurimi i Intel BG parashikon aktivizimin e kësaj teknologi, atëherë që nga ky moment, në këtë sistem, të përditësoni BIOS (dmth. të keni mundësinë të rindërtoni këto manifeste) mund të bëhet vetëm nga mbajtësi i pjesës private të OEM Root Key, dmth. nga shitësi.

Duke parë figurën, menjëherë lindin dyshime në lidhje me nevojën për një zinxhir kaq të gjatë verifikimi – mund të përdorej vetëm një manifest. Pse ta komplikohet?

Në të vërtetë, kompania Intel kështu i ofron shitësit mundësinë për të përdorur çelësa të ndryshëm IBB për linja të ndryshme produktesh dhe një – si çelës themelor. Nëse e privatuara e çelësit IBB (me të cilin nënshkruhet manifesti i dytë) rrjedh, incidenti do të prekë vetëm një linjë produktesh dhe vetëm deri sa shitësi të gjenerojë një çift të ri dhe të përfshijë manifestet e rinj në përditësimin e ardhshëm të BIOS-it.

Porosi që nëse çelësi themelor (nëpërmjet të cilit nënshkruhet manifesti i parë) komprometohet, nuk do të jetë e mundur ta zëvendosësh atë, sepse procedurat e revokimit nuk janë parashikuar, pasi hashi i pjesës publike të këtij çelësi programohet në FPF vetëm një herë e përgjithmonë.

Konfigurimi i Intel Boot Guard

Tani le të ndalojmë më në detaje mbi konfigurimin e Intel BG dhe procesin e krijimit të saj. Nëse shikojmë në seksionin përkatës në GUI të utilitarit Flash Image Tool nga paketa Intel System Tool Kit (STK), mund të vërejmë se konfigurimi i Intel BG përfshin hashin e pjesës publike të çelësit themelor të shitësit, një çift vlerash të pafavorshme dhe profilin e quajtur Intel BG.

Struktura e këtij profili:

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 – mos bëj asgjë
                                              // 01b – mbyll me kufizim kohor
                                              // 11b – mbyll menjëherë
	unsigned long : 26;
};

Në përgjithësi, konfigurimi i Intel BG është një entitet shumë fleksibël. Le të shqyrtojmë, për shembull, flakën Force_Boot_Guard_ACM. Kur ai është hequr, në rast se moduli BG startup ACM në memorjen SPI flash nuk gjendet, nuk do të ketë ngarkim të besueshëm. Do të ketë ngarkim të pamëshirshëm.

Më sipër ne kemi shkruar se politika e zbatimit për modalitetin VB mund të konfigurohet në mënyrë që, në rast të një gabimi verifikimi, të ndodhë përsëri një ngarkim i pamëshirshëm.

Të lihen gjëra të tilla në discretion të shitësve...

GUI e utilitarit parashikon profilet e mëposhtme "të gatshme":

Numri
Modaliteti
Përshkrimi

0
No_FVME
teknologjia Intel BG e fikur

1
VE
modaliteti VB i aktivizuar, mbyllje me kufizim kohor

2
VME
aktivizohen të dy modalitetet (VB dhe MB), mbyllje me kufizim kohor

3
VM
aktivizohen të dy modalitetet, pa mbyllje të sistemit

4
FVE
modaliteti VB i aktivizuar, mbyllje menjëherë

5
FVME
aktivizohen të dy modalitetet, mbyllje menjëherë

Siç është thënë tashmë, konfigurimi i Intel BG duhet të shkruhet një herë e përgjithmonë nga shitësi i sistemit në fusët e çipit (FPF) – një ruajtje të vogël (sipas informacioneve të pavërtetuara, vetëm 256 byte) të informacionit brenda çipit, e cila mund të programohet jashtë kapaciteteve prodhuese të kompanisë Intel (prandaj, pikërisht Field Programmable Fuses).

E përshtatshme për ruajtjen e konfiguracionit, sepse:

• ka një zonë one-time-programmable për ruajtjen e të dhënave (atosh, ku regjistrohet konfigurimi i Intel BG);
• vetëm Intel ME mund ta lexojë dhe programojë atë.

Prandaj, për të konfiguruar teknologjinë Intel BG në një sistem të caktuar, prodhuesi gjatë prodhimit bën si më poshtë:

1. Me ndihmën e utilitarit Flash Image Tool (nga Intel STK) krijohet një imazh i firmware me konfigurimin e caktuar të Intel BG si variabla brenda rajonit Intel ME (një lloj pasqyrë e përkohshme për FPF-të);
2. Me ndihmën e utilitarit Flash Programming Tool (nga Intel STK) shkruhet ky imazh në memorien SPI flash të sistemit dhe mbyllet ashtuquajtura manufacturing mode (në këtë moment, dërgohet një komandë përkatëse në Intel ME).

Si rezultat i këtyre operacioneve, Intel ME do të angazhojë marrëveshjet e caktuara nga pasqyra për FPF-të në rajonin ME, do të vendosë lejet në SPIs flash-deskriptorët në vlerat e rekomanduara nga kompania Intel (siç përmendej në fillim të artikullit) dhe do të kryejë një RINDIZJE të sistemit.

Analiza e implementimit të Intel Boot Guard

Me qëllim të analizës së zbatimit të kësaj teknologjie në një shembull të caktuar, ne kontrolluam sistemet e mëposhtme për shenjat e teknologjisë Intel BG:

Sistemi
Shënim

Gigabyte GA-H170-D3H
Skylake, ka mbështetje

Gigabyte GA-Q170-D3H
Skylake, ka mbështetje

Gigabyte GA-B150-HD3
Skylake, ka mbështetje

MSI H170A Gaming Pro
Skylake, nuk ka mbështetje

Lenovo ThinkPad 460
Skylake, ka mbështetje, teknologjia është e aktivizuar

Lenovo Yoga 2 Pro
Haswell, nuk ka mbështetje

Lenovo U330p
Haswell, nuk ka mbështetje

Me 'mbështetje' kuptohet prania e modulit Intel BG startup ACM, manifestet përmendur më sipër dhe kodi përkatës në BIOS, pra implementimi për analizë.

Si një shembull, do të marrim një imazh të shkarkuar nga faqja zyrtare e prodhuesit për memorien SPI flash për Gigabyte GA-H170-D3H (versioni F4).

Intel CPU boot ROM

Fillimisht, le të flasim për veprimet e procesorit në rast se teknologjia Intel BG është aktivizuar.

Nuk u gjetën mostra të dekoduar të mikrokodit, prandaj, sesi veprimet e përshkruara më poshtë janë realizuar (në mikrokod apo harduerikisht) mbetet një çështje e hapur. Megjithatë, është e vërtetë që procesorët modernë Intel ‘kanë’ aftësinë për të kryer këto veprime.

Pasi del nga gjendja RESET, procesori (në hapësirën adresuese të cilit tashmë është hartuar përmbajtja e memories flash) gjen tabelën FIT (Firmware Interface Table). Të gjejmë atë është e thjeshtë, pasi adresa e saj është regjistruar në adresën FFFF FFC0h.

Në shembullin e shqyrtuar, në këtë adresë ndodhet vlera FFD6 9500h. Duke u drejtuar në këtë adresë, procesori sheh tabelën FIT, përmbajtja e së cilës është e ndarë në regjistrime. Regjistrimi i parë është një titull me strukturën e mëposhtme:

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

Për një arsye të panjohur, çeksuma nuk është gjithmonë e llogaritur në këto tabela (në fushën e lënë zero).

Të dhënat e tjera tregojnë për binarë të ndryshëm, të cilët duhet të analizohen/ekzekutohen para ekzekutimit të BIOS-it, pra para kalimit në vektorin RESET legacy (FFFF FFF0h). Struktura e çdo regjistri të tillë është si në vijim:

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

Fusha EntryType tregon për llojin e bllokut, në të cilin i referohet ky regjistër. Na njoftohet për disa lloje:

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

Tani është e qartë se një nga regjistrat tregon për vendndodhjen e binarit Intel BG startup ACM. Struktura e titullit të këtij binari është tipike për modulet e kodit të zhvilluara nga Intel (ACM-ët, përditësimet e mikro kodit, seksionet e kodit të 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];
};

Proçesori e ngarkon këtë binar në memorie, e verifikon dhe e ekzekuton.

Intel BG startup ACM

Si pasojë e analizës së operimit të këtij ACM, u bë e qartë se ai bën këtë:

• merr nga Intel ME konfigurimin Intel BG, të regjistruar në fuzionet e çipit (FPF-ët);
• gjen manifestet KEYM dhe IBBM, i verifikon ato.

Për të gjetur këto manafestë, ACM gjithashtu përdor tabelën FIT, ku janë caktuar dy lloje regjistrash për të treguar të dhënat e strukturës (shih FIT_ENTRY_TYPES më lart).

Le të ndalemi më shumë tek manifestet. Në strukturën e manifestit të parë shohim disa konstanta të paqarta, hash-in e çelësit publik nga manifesti i dytë dhe çelësin publik OEM Root Key me një nënshkrim në formën e një strukture të ngjitur:

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

Për verifikimin e çelësit publik OEM Root Key, kujtojmë se përdoret hesh SHA256 nga fuse, i cili në atë moment është marrë tashmë nga Intel ME.

Të kalojmë në manifestin e dytë. Ai përbëhet nga tre struktura:

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Politikat e boot
	IBBS Ibbs;         // Përshkrimi IBB
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // Nënshkrimi IBBM
};

Në të parën – disa konstante:

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

Në të dytën është hesh SHA256 i IBB dhe numri i përshkruesve që përshkruajnë përmbajtjen e IBB (dmth. ajo nga e cila llogaritet hesh):

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

Përshkruesit IBB ndjekin këtë strukturë, një pas tjetrit. Përmbajtja e tyre ka formatin e mëposhtëm:

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

E gjithë kjo është e thjeshtë: çdo përshkrues përmban adresën/gabimin e një cope IBB. Kështu që, konkatena e blloqeve, për të cilat tregojnë këta përshkrues (në rendin e vendndodhjes së vetë përshkruesve) është IBB. Dhe, përgjithësisht, IBB është një grumbullim i të gjitha moduleve të fazës SEC dhe PEI.

Manifesti i dytë përfundon me një strukturë, që përmban çelësin publik IBB (i verifikuar nga hesh SHA256 i manifestit të parë) dhe nënshkrimin e këtij manifesti:

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

Pra fillon, para se të nisë ekzekutimi i UEFI BIOS, procesori do të aktivizojë ACM, i cili do të verifikojë autentikimin e përmbajtjes së segmenteve të kodit SEC dhe PEI. Më pas, procesori del nga ACM, kalon në vektorin RESET dhe fillon të ekzekutojë BIOS-in.

Segmeti i verifikuar PEI duhet të përmbajë një modul, i cili do të verifikojë pjesën e mbetur të BIOS-it (kode DXE). Ky modul zhvillohet nga IBV (Independent BIOS Vendor) ose vetë prodhuesi i sistemit. Ndërsa ishin në dispozicion dhe kishin mbështetje për Intel BG, vetëm sistemet Lenovo dhe Gigabyte dolën, kështu që do të shqyrtojmë kodin e nxjerrë saktësisht nga këto sisteme.

Moduli UEFI BIOS LenovoVerifiedBootPei

Në rastin e Lenovo, kjo ishte moduli LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, i zhvilluar nga kompania Lenovo.

Puna e tij përfshin kërkimin (sipër GUID) të tabelës së hash-it për DXE dhe verifikimin e DXE.

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

Tabela e hash-it {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} ka formatin e mëposhtëm:

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

Moduli UEFI BIOS BootGuardPei

Në rastin e Gigabyte, kjo ishte moduli BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, i zhvilluar nga AMI, për rrjedhojë, i pranishëm në çdo BIOS AMI me mbështetje për Intel BG.

Algoritmi i tij i funksionimit është paksa i ndryshëm, megjithatë, përfundon në të njëjtën gjë:

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

Tabela e hash-it {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, që ai kërkon, ka formatin e mëposhtëm:

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

Do të flasim shkurtimisht për një tjetër implementim të Intel Boot Guard, i cili u gjet në një sistem më të ri të bazuar në Intel SoC me mikroarkitekturën Apollo Lake — ASRock J4205-IT.

Megjithëse kjo version do të përdoret vetëm në SoC, (sistemet e reja me mikroarkitekturën e procesorit Kaby Lake vazhdojnë të përdorin Intel Boot Guard 1.x), ajo paraqet një interes të madh për studimin e një varianti të ri arkitekturor për platformat në Intel SoC, ku janë bërë ndryshime të dukshme, për shembull:

• rajone të BIOS dhe Intel ME (në fakt Intel TXE, sipas terminologjisë për Intel SoC) tani janë një rajon IFWI;
• ndonëse platforma kishte Intel BG aktivizuar, struktura si FIT, KEYM, IBBM nuk u gjetën në memorie flash;
• përveç bërthamave TXE dhe ISH (x86), çipseti përfshiu një bërthamë të tretë (përsëri ARC, përndryshe) – PMC (Menaxhimi i Energjisë), i lidhur me funksionimin e sistemit të furnizimit me energji dhe monitorimin e performancës.

Përmbajtja e rajonit të ri IFWI përbëhet nga një grup moduletish:

Pozita
Emri
Përshkrimi

0000 2000h
SMIP
një konfigurim i caktuar i platformës, nënshkruar nga ndërrmarrësi

0000 6000h
RBEP
seksioni i kodit të firmuerës Intel TXE, x86, nënshkruar nga Intel

0001 0000h
PMCP
seksioni i kodit të firmuerës Intel PMC, ARC, nënshkruar nga Intel

0002 0000h
FTPR
seksioni i kodit të firmuerës Intel TXE, x86, nënshkruar nga Intel

0007 B000h
UCOD
përditësime të mikro-kodit për CPU, nënshkruar nga Intel

0008 0000h
IBBP
UEFI BIOS, fazat SEC/PEI, x86, nënshkruar nga ndërrmarrësi

0021 8000h
ISHC
seksioni i kodit të firmuerës Intel ISH, x86, nënshkruar nga ndërrmarrësi

0025 8000h
NFTP
seksioni i kodit të firmuerës Intel TXE, x86, nënshkruar nga Intel

0036 1000h
IUNP
e panjohur

0038 1000h
OBBP
UEFI BIOS, faza DXE, x86, e pa nënshkruar

Gjatë analizës së firmuerës TXE, u bë e qartë se pas RESET-it, TXE mban procesorin në këtë gjendje deri sa të përgatisë përmbajtjen themelore të hapësirës adresuese për CPU (FIT, ACM, vektori RESET …). TXE vendos këto të dhëna në SRAM-në e saj, pastaj përkohësisht i jep procesorit akses atje dhe "e lirojnë" atë nga RESET-i.

Në mbrojtje të rootkits

Dhe tani le të kalojmë në "temën e nxehtë". Një herë kemi zbuluar se në shumë sisteme, në deskriptoret SPI flash janë shkruar lejet për akses në rajonet e memorie flash SPI në një mënyrë që të gjithë përdoruesit e kësaj memorjeje mund të shkruajnë dhe të lexojnë çdo rajon. Pra, ashtu si duhet.

Pas verifikimit me ndihmën e utilitetit MEinfo (nga Intel STK), ne pamë se moda e prodhimit në këto sisteme nuk ishte mbyllur, për rrjedhojë, fuzionet e çipsetit (FPF-të) mbetën në një gjendje të paqartë. Po, Intel BG në këto raste nuk është aktivizuar as çaktivizuar.

Bëhet fjalë për sistemet e mëposhtme (përsa i përket Intel BG dhe asaj që do të paraqitet më tej në artikull, ne do të flasim për sistemet me mikroarkitekturën e procesorëve Haswell dhe më lart):

• të gjithë produktet e Gigabyte;
• të gjithë produktet e MSI;
• 21 modele laptopësh Lenovo dhe 4 modele serverësh Lenovo.

Natyrisht, ne e raportuam këtë gjetje këtyre ndërrmarrjeve, si dhe kompanisë Intel.

Reagimi adekuat erdhi vetëm nga Lenovo, të cilët e pranuan problemin dhe lëshuan një patch.

Gigabyte duke pranuar informacionin për dobësinë, por nuk bënë asnjë koment.

Komunikimi me MSI kaqë është bllokuar në kërkesën tonë për të dërguar çelësin tuaj publik PGP (në mënyrë që t'u dërgojmë një njoftim për sigurinë në formë të enkriptuar). Ata deklaruan se "janë prodhues të pajisjeve, dhe nuk prodhojnë çelësa PGP".

Por le të kalojmë në detajet. Duke qenë se fusible-t janë lënë në një gjendje të pakonfiguruar, përdoruesi (apo ndonjë sulmues) mund t'i programojë ato vetë (gjëja më e vështirë është të gjejë Intel STK). Për këtë kërkohen hapat e mëposhtëm.

1. Të ngarkohet në sistemin operativ Windows (për më shumë, veprimet e përshkruara më poshtë mund të bëhen edhe nga Linux, nëse zhvillohet një alternativë për Intel STK për sistemin përkatës). Duke përdorur utilitarin MEinfo, sigurohuni që fusible-t në këtë sistem nuk janë të programuar.

2. Të lexoni përmbajtjen e memorjes flash duke përdorur Flash Programming Tool.

3. Të hapni imazhin e lexuar me ndihmën e çdo mjeti për modifikimin e UEFI BIOS, të bëni ndryshimet e nevojshme (për shembull, të integoni një rootkit), të krijoni/përditësoni strukturat ekzistuese KEYM dhe IBBM në rajonin ME.

Në figurë është theksuar pjesa publike e çelësit RSA, hash i të cilit do të programohet në fusible-t e çipsetit së bashku me konfigurimin tjetër të Intel BG.

4. Me ndihmën e Flash Image Tool, të krijoni një imazh të ri të firmware (duke skaduar konfigurimin e Intel BG).

5. Të shkruani imazhin e ri në memorjen flash duke përdorur Flash Programming Tool, të siguroheni me MEinfo se rajoni ME tani përmban konfigurimin e Intel BG.

6. Me ndihmën e Flash Programming Tool, të mbyllni modin e prodhimit.

7. Sistemi do të ribyllohet, pas së cilës me ndihmën e MEinfo mund të siguroheni që FPF tani janë të programuar.

Këto veprime përherë do të aktivizojnë Intel BG në këtë sistem. Veprimi nuk do të mund të anulohet, që do të thotë:

• për të përditësuar UEFI BIOS në këtë sistem mund të vetëm ai që ka pjesën private të çelësit rrënjësor (dmth. ai që aktivizoi Intel BG);
• nëse e ktheni këtë sistem në firmware-in origjinal, për shembull, me ndihmën e programatorit, ai as nuk do të ndizet (pasoja e politikës së zbatimit në rast verifikimi të gabuar);
• për t'u liruar nga një UEFI BIOS i tillë, kërkohet që të zëvendësohet çipseti me FPF të programuar me një "të pastër" (dmth. të riparoni çipsetin, nëse keni qasje në një stacion saldimi infra të kuqe, qindarka si një makinë, ose thjesht të zëvendësoni bordin e nënës).

Për të kuptuar se çfarë mund të bëjë një rootkit i tillë, duhet të vlerësohet se çfarë ofron mundësinë për të ekzekutuar kodin e tij në mjedisin e BIOS-it UEFI. Le të themi, në modin më të privilegjuar të procesorit – SMM. Një rootkit i tillë mund të ketë këto veti:

• të ekzekutohet paralelisht me OS-në (mund të konfigurohet për të përfunduar duke gjeneruar një ndërprerje SMI, e cila do të aktivizohet nga një timer);
• të ketë të gjitha avantazhet e qëndrimit në modin SMM (qasje e plotë në përmbajtjen e memories RAM dhe burimeve harduerike, fshehtësia nga OS);
• kode programi i rootkit-it mund të jetë në formë të enkriptuar dhe të dekriptohet gjatë ekzekutimit në modin SMM. Si çelës për enkriptim mund të përdoren të dhëna të ndryshme, që janë të disponueshme vetëm në modin SMM. Për shembull, një hash i një grupi adresash në SMRAM. Për të marrë këtë çelës, do të kërkohet të hyhet në SMM. Kjo mund të bëhet në dy mënyra. Të gjenden RCE në kodin SMM dhe të shfrytëzohet, ose të shtohet një moduli SMM në BIOS, që nuk është e mundur, pasi kemi aktivizuar Boot Guard.

Kështu, kjo vulnerabilitet lejon një sulmues:

• të krijojë një rootkit të fshehtë, të pavendosur për qëllime të panjohura në sistem;
• të ekzekutojë kodin e tij në një nga bërthamat e çipsetit brenda Intel SoC, konkretisht, në Intel ISH (shikoni me kujdes imazhin).

Megjithëse mundësitë e nën-sistemës Intel ISH ende nuk janë hulumtuar, ajo paraqitet si një vektor interesant sulmi ndaj Intel ME.

Përfundimet

1. Studimi mundësoi përftimin e një përshkrimi teknik të funksionimit të teknologjisë Intel Boot Guard. Një minus i disa sekretet në modelin e Intel-it për sigurinë përmes fshehtësisë.
2. U paraqit një skenar sulmi, i cili lejon krijimin e një rootkit-i të pavendosur në sistem.
3. Ne pamë se procesorët modernë Intel janë në gjendje të ekzekutojnë shumë kod pronar edhe para fillimit të punës së BIOS-it.
4. Platformat me arkitekturë Intel 64 janë duke u bërë gjithnjë e më pak të përshtatshme për të ekzekutuar softuer të lirë: verifikimi harduerik, numri në rritje i teknologjive dhe nën-sistemeve pronar (tre bërthama në çipin SoC: x86 ME, x86 ISH dhe ARC PMC).

Mitigimet

Furnizuesit që qëllimisht e lënë modin e prodhimit të hapur duhet ta mbyllin atë. Deri tani, vetëm mbyllin sytë dhe sistemet e reja Kaby Lake e tregojnë këtë.

Përdoruesit mund ta çaktivizojnë vetë Intel BG në sistemet e tyre (të cilat janë të ndjeshme ndaj dobësisë të përshkruar), duke bërë përdorimin e mjetit Flash Programming Tool me parametrin -closemnf. Para, duhet të sigurohen (me ndihmën e MEinfo), që konfigurimi i Intel BG në rajonin ME parasheh pikërisht çaktivizimin e kësaj teknologjie pas.Programimit në FPF.

Burimi: habr.com