Javasoljuk, hogy menjünk le ismét az alacsony szintre, és beszéljünk az x86-kompatibilis firmware-platformok biztonságáról. Ezúttal a kutatás fő összetevője az Intel Boot Guard (nem tévesztendő össze az Intel BIOS Guarddal!) – egy hardverrel támogatott BIOS megbízható rendszerindítási technológia, amelyet a számítógépes rendszer gyártója véglegesen engedélyezhet vagy letilthat a gyártási szakaszban. Nos, a kutatási receptet már ismerjük: ennek a technológiának a megvalósítását reverse engineering-el vékonyra vágjuk, felépítését leírjuk, megtöltve nem dokumentált részletekkel, ízlés szerint fűszerezzük támadási vektorokkal és keverjük össze. Gyújtsunk egy történetet arról, hogy egy klónozott hiba több gyártó gyártásában évek óta lehetővé teszi a potenciális támadó számára, hogy ezzel a technológiával egy rejtett rootkitet hozzon létre, amelyet nem lehet eltávolítani (még egy programozó által sem) a rendszerből.
A cikk egyébként a konferencia „On Guard for Rootkits: Intel BootGuard” beszámolóin alapul. és 29. ülés (mindkét előadás ).
Firmware számítógépes platformhoz Intel 64 architektúrával
Először is válaszoljunk a kérdésre: mi a firmware egy modern számítógépes platform Intel 64 architektúrájával? Természetesen UEFI BIOS. De ez a válasz nem lesz pontos. Vessünk egy pillantást az ábrára, amely ennek az architektúrának az asztali (laptop) változatát mutatja.
A link az alapja:
- Processzor (CPU, Central Processing Unit), amely a fő magok mellett beépített grafikus maggal (nem minden modellben) és memóriavezérlővel (IMC, Integrated Memory Controller) rendelkezik;
- Chipset (PCH, Platform Controller Hub), amely különféle vezérlőket tartalmaz a perifériás eszközökkel való interakcióhoz és az alrendszerek kezeléséhez. Köztük van a hírhedt Intel Management Engine (ME), amely firmware-rel (Intel ME firmware) is rendelkezik.
A laptopokhoz a fentieken kívül szükség van egy integrált vezérlőre (ACPI EC, Advanced Control and Power Interface Embedded Controller), amely az energiaellátási alrendszer, érintőpad, billentyűzet, Fn billentyűk (képernyő fényereje, hangerő, billentyűzet) működéséért felelős. háttérvilágítás stb.). ) és így tovább. És van saját firmware-je is.
Tehát a fenti firmware kombinációja a számítógépes platform firmware-je (rendszer firmware), amelyet egy közös SPI flash memóriában tárolnak. Annak érdekében, hogy a memória felhasználói ne keveredjenek össze, hol fekszik valaki, a memória tartalma a következő régiókra van felosztva (az ábrán látható módon):
- UEFI BIOS;
- ACPI EC firmware (egy külön régió jelent meg a Skylake processzor mikroarchitektúrájával (2015), de a vadonban még nem láttunk példát a használatára, így a beágyazott vezérlő firmware továbbra is az UEFI BIOS része);
- Intel ME firmware;
- a beépített GbE (Gigabit Ethernet) hálózati adapter konfigurálása (MAC-cím stb.);
- flash leírók - a flash memória fő régiója, amely mutatókat tartalmaz más régiókra, valamint hozzáférési engedélyeket.
A régiókhoz való hozzáférés differenciálását (a megadott jogosultságoknak megfelelően) az SPI-busz-master - a lapkakészletbe épített SPI-vezérlő - kezeli, amelyen keresztül ez a memória elérhető. Ha az engedélyek az Intel által (biztonsági okokból) ajánlott értékekre vannak beállítva, akkor az SPI flash minden felhasználója teljes hozzáféréssel (olvasási/írási) csak a saját régiójához rendelkezik. A többi vagy csak olvasható, vagy nem érhető el. Ismert tény: sok rendszeren a CPU teljes hozzáféréssel rendelkezik az UEFI BIOS-hoz és GbE-hez, csak olvasási hozzáférése van a flash leírókhoz, és egyáltalán nem fér hozzá az Intel ME régióhoz. Miért sokan és miért nem mind? Ami ajánlott, az opcionális. A cikk későbbi részében többet fogunk elmondani.
A számítógépes platform firmware-ének módosításokkal szembeni védelmének mechanizmusai
Nyilvánvaló, hogy a számítógépes platform firmware-jét védeni kell az esetleges kompromisszumoktól, ami lehetővé tenné a potenciális támadó számára, hogy megvesse a lábát benne (túlélje az operációs rendszer frissítéseit / újratelepítését), a kódját a legkiváltságosabb módokban hajtsa végre, stb. És természetesen nem elég az SPI flash memória régióihoz való hozzáférés elhatárolása. Ezért az egyes végrehajtási környezetekre jellemző különféle mechanizmusokat használnak a firmware módosítások elleni védelmére.
Tehát az Intel ME firmware alá van írva az integritás és a hitelesség ellenőrzésére, és az ME vezérlő minden alkalommal ellenőrzi, amikor betölti az ME UMA memóriába. Ezt az ellenőrzési folyamatot már tárgyaltuk az egyikben dedikált az Intel ME alrendszernek.
És az ACPI EC firmware-t általában csak az integritás szempontjából ellenőrzik. Mivel azonban ez a bináris fájl szerepel az UEFI BIOS-ban, szinte mindig ugyanazok a védelmi mechanizmusok vonatkoznak rá, mint az UEFI BIOS. Beszéljünk róluk.
Ezek a mechanizmusok két kategóriába sorolhatók.
Írásvédelem az UEFI BIOS régióba
- Az SPI flash memória tartalmának fizikai védelme írásvédelmi jumperrel;
- Az UEFI BIOS régió vetületének védelme a CPU címterében a chipkészlet PRx regiszterei segítségével;
- Az UEFI BIOS régióba való írási kísérletek blokkolása a megfelelő SMI megszakítás generálásával és feldolgozásával a BIOS_WE / BLE és SMM_BWP bitek beállításával a chipkészlet regiszterekben;
- Ennek a védelemnek egy fejlettebb változata az Intel BIOS Guard (PFAT).
Ezeken a mechanizmusokon kívül a gyártók saját biztonsági intézkedéseiket is kifejleszthetik és megvalósíthatják (például aláírhatják a kapszulákat UEFI BIOS-frissítésekkel).
Fontos megjegyezni, hogy egy adott rendszeren (szállítótól függően) előfordulhat, hogy a fenti védelmi mechanizmusok mindegyike nem alkalmazható, vagy egyáltalán nem, vagy sérülékenyen valósul meg. Ezekről a mechanizmusokról és megvalósításuk helyzetéről itt olvashat bővebben . Az érdeklődőknek javasoljuk, hogy olvassák el az UEFI BIOS biztonságáról szóló teljes cikksorozatot .
UEFI BIOS hitelesítés
Amikor a megbízható rendszerindítási technológiákról beszélünk, az első dolog, ami eszünkbe jut, a Secure Boot. Építészetileg azonban az UEFI BIOS-on kívüli összetevők (illesztőprogramok, betöltők stb.) hitelesítésére szolgál, nem pedig magát a firmware-t.
Ezért az Intel a Bay Trail mikroarchitektúrájú SoC-kban (2012) egy hardveresen nem váltható Secure Boot-ot (Verified Boot) valósított meg, aminek semmi köze a fent említett Secure Boot technológiához. Később (2013) ezt a mechanizmust továbbfejlesztették, és Intel Boot Guard néven Haswell mikroarchitektúrával ellátott asztali számítógépekre is kiadták.
Az Intel Boot Guard leírása előtt nézzük meg az Intel 64 architektúra végrehajtási környezeteit, amelyek együttesen a bizalom gyökerei e megbízható rendszerindítási technológia iránt.
Intel CPU
A Cap azt sugallja, hogy a processzor a fő végrehajtási környezet az Intel 64 architektúrában. Miért ez a bizalom gyökere? Kiderül, hogy a következő elemek birtoklása teszi azzá:
- A Microcode ROM egy nem felejtő, nem újraírható memória a mikrokód tárolására. Úgy gondolják, hogy a mikrokód a processzor utasításrendszerének megvalósítása a legegyszerűbb utasításokra. Mikrokódban is előfordul . Tehát a BIOS-ban találhatunk mikrokód frissítésekkel rendelkező binárisokat (a rendszerindításkor egymásra kerülnek, mert a ROM nem írható felül). Ezeknek a binárisoknak a tartalma titkosított, ami nagymértékben megnehezíti az elemzést (ezért a mikrokód konkrét tartalmát csak azok ismerik, akik fejlesztik), és aláírják az integritás és hitelesség ellenőrzésére;
- AES kulcs a mikrokód-frissítések tartalmának visszafejtéséhez;
- az RSA nyilvános kulcsának kivonatát, amely ellenőrzi a mikrokód-frissítések aláírását;
- RSA nyilvános kulcs hash, amely ellenőrzi az Intel által fejlesztett ACM (Authenticated Code Module) kódmodulok aláírását, amelyeket a CPU a BIOS indulása előtt (hello mikrokód) vagy annak működése közben, bizonyos események bekövetkezésekor futtathat.
Intel ME
Blogunkban ennek az alrendszernek szenteltük . Emlékezzünk vissza, hogy ez a végrehajtható környezet a chipkészletbe épített mikrokontrolleren alapul, és a rendszer legrejtettebb és legelőnyösebb környezete.
A lopakodás ellenére az Intel ME a bizalom gyökere is, mert rendelkezik:
- ME ROM - nem felejtő, nem újraírható memória (nincs frissítési mód), amely tartalmazza a kezdőkódot, valamint az RSA nyilvános kulcsának SHA256 hash-jét, amely ellenőrzi az Intel ME firmware aláírását;
- AES kulcs titkos információk tárolására;
- hozzáférés a chipkészletbe integrált biztosítékkészlethez (FPF-ek, helyszíni programozható biztosítékok) bizonyos információk állandó tárolására, beleértve a számítógép-rendszer gyártója által megadott információkat is.
Intel Boot Guard 1.x
Kis felelősségkizárás. Az Intel Boot Guard technológia ebben a cikkben használt verziószámai tetszőlegesek, és lehet, hogy nincs közük az Intel belső dokumentációjában használt számozáshoz. Ezen túlmenően, az itt közölt, a technológia megvalósítására vonatkozó információk visszafejtés során kerültek beszerzésre, és pontatlanságokat tartalmazhatnak az Intel Boot Guard specifikációjához képest, amelyet valószínűleg soha nem fognak közzétenni.
Tehát az Intel Boot Guard (BG) egy hardver által támogatott UEFI BIOS hitelesítési technológia. A [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot] című könyvben található kis leírása alapján megbízható rendszerindítási láncként működik. Az első link benne pedig a CPU-n belüli boot kód (mikrokód), amit a RESET esemény vált ki (nem tévesztendő össze a BIOS-ban lévő RESET vektorral!). A CPU megtalálja az Intel által fejlesztett és aláírt kódmodult (Intel BG startup ACM) az SPI flash memórián, betölti a gyorsítótárába, ellenőrzi (az már fentebb volt, hogy a CPU rendelkezik egy nyilvános kulcsú kivonattal, amely ellenőrzi az ACM aláírást ) és elindul.
Ez a kódmodul felelős az UEFI BIOS - Initial Boot Block (IBB) kis kezdő részének ellenőrzéséért, amely viszont tartalmazza az UEFI BIOS fő részének ellenőrzésére szolgáló funkciókat. Így az Intel BG lehetővé teszi a BIOS hitelességének ellenőrzését az operációs rendszer indítása előtt (ami a Secure Boot technológia felügyelete mellett hajtható végre).
Az Intel BG technológia két működési módot biztosít (és az egyik nem zavarja a másikat, azaz mindkét mód engedélyezhető a rendszeren, és mindkettő letiltható).
Mért Boot
Mért rendszerindítás (MB) módban minden rendszerindító komponens (a CPU rendszerindító ROM-mal kezdődően) "méri" a következőt a Trusted Platform Module (TPM) képességei segítségével. Aki nem tudja, hadd magyarázzam el.
A TPM rendelkezik PCR-ekkel (Platform Configuration Registers), amelyek rögzítik a hash művelet eredményét a következő képlet szerint:
Azok. az aktuális PCR-érték az előzőtől függ, és ezek a regiszterek csak akkor állnak vissza, ha a rendszer RESET van.
Így MB módban egy bizonyos időpontban a PCR-ek a „megmért” kód vagy adat egyedi (a hash művelet lehetőségein belül) azonosítóját tükrözik. A PCR értékek egyes adatok titkosításában (TPM_Seal) használhatók. Ezt követően a visszafejtésük (TPM_Unseal) csak akkor lesz lehetséges, ha a PCR-értékek a betöltés hatására nem változtak (azaz egyetlen „mért” komponens sem módosult).
Ellenőrzött rendszerindítás
Az UEFI BIOS módosítását kedvelők számára a legfélelmetesebb a Verified Boot (VB) mód, amelyben minden indító komponens titkosítással ellenőrzi a következő sértetlenségét és hitelességét. Ellenőrzési hiba esetén (az alábbiak egyike) történik:
- leállítás időtúllépéssel 1 percről 30 percre (hogy a felhasználónak legyen ideje megérteni, miért nem indul el a számítógépe, és ha lehetséges, megpróbálja visszaállítani a BIOS-t);
- azonnali leállítás (hogy a felhasználónak ne legyen ideje megérteni és ráadásul megtenni);
- a munka folytatása egyenes arccal (az az eset, amikor nincs idő a biztonságra, mert vannak fontosabb tennivalók).
A művelet megválasztása a megadott Intel BG konfigurációtól függ (nevezetesen az úgynevezett végrehajtási szabályzattól), amelyet a számítógép-platform gyártója állandóan rögzít egy speciálisan kialakított tárolóban - chipkészlet biztosítékok (FPF). Erről a pontról a későbbiekben még részletesebben kitérünk.
A konfiguráción kívül a szállító két RSA 2048 kulcsot generál, és két adatstruktúrát hoz létre (az ábrán látható):
- A szállítói gyökérkulcs-jegyzék (KEYM, OEM Root Key Manifest), amely a jegyzék SVN-jét (Security Version Number), a következő jegyzék nyilvános kulcsának SHA256-kivonatát helyezi el, az RSA nyilvános kulcsát (vagyis a jegyzék nyilvános részét). szállítói gyökérkulcs) a jegyzék aláírásának és magának az aláírásnak az ellenőrzéséhez;
- Az IBB Manifest (IBBM, Initial Boot Block Manifest), amely a jegyzék SVN-jét, az IBB SHA256 hash-jét, a jegyzék aláírásának ellenőrzésére szolgáló nyilvános kulcsot és magát az aláírást helyezi el.
Az OEM-gyökérkulcs SHA256 hash-je állandóan a lapkakészlet-biztosítékokba (FPF) van írva, akárcsak az Intel BG konfigurációja. Ha az Intel BG konfigurációja rendelkezik ennek a technológiának a beépítéséről, akkor ezentúl ezen a rendszeren csak az OEM Root Key privát részének tulajdonosa frissítheti a BIOS-t (azaz újraszámolhatja ezeket a manifeszteket), pl. eladó.
Ha megnézi a képet, azonnal kétségek merülnek fel egy ilyen hosszú ellenőrzési lánc szükségességével kapcsolatban - használhatott volna egy manifestet. Miért bonyolult?
Valójában így az Intel lehetőséget biztosít az eladónak, hogy különböző IBB-kulcsokat használjon a különböző termékcsaládokhoz, és egyet gyökérként. Ha az IBB-kulcs privát része (amely a második jegyzéket aláírja) kiszivárog, az incidens csak egy termékvonalat érint, és csak addig, amíg a szállító nem generál új párt, és engedélyezi az újraszámított jegyzékeket a következő BIOS-frissítésben.
De ha a gyökérkulcs sérül (amivel az első jegyzéket aláírták), akkor nem lehet lecserélni, a visszavonási eljárás nem biztosított. ennek a kulcsnak a nyilvános részének hash-je egyszer s mindenkorra be van programozva az FPF-ekbe.
Intel Boot Guard konfiguráció
Most pedig nézzük meg közelebbről az Intel BG konfigurációját és létrehozásának folyamatát. Ha megnézi a megfelelő fület az Intel System Tool Kit (STK) Flash Image Tool grafikus felhasználói felületén, észre fogja venni, hogy az Intel BG konfigurációja tartalmazza a szállító gyökérkulcsának nyilvános részének kivonatát, ami néhány homályos. értékek, és így tovább. Intel BG profil.
Ennek a profilnak a felépítése:
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;
};Általánosságban elmondható, hogy az Intel BG konfigurációja nagyon rugalmas entitás. Vegyük például a Force_Boot_Guard_ACM jelzőt. Ha törlődik, ha az SPI flash BG indító ACM modulja nem található, nem történik megbízható rendszerindítás. Megbízhatatlan lesz.
Fentebb már írtuk, hogy a VB mód végrehajtási szabályzata konfigurálható úgy, hogy ha az ellenőrzés sikertelen, ismét nem megbízható letöltés történjen.
Az ilyesmit bízd az eladókra...
A segédprogram grafikus felhasználói felülete a következő "kész" profilokat biztosítja:
Nem.
rezsim
Leírás
0
No_FVME
Az Intel BG technológia le van tiltva
1
VE
VB mód engedélyezve, leállítás időtúllépéssel
2
VME kiterjesztés
mindkét mód engedélyezve van (VB és MB), leállítás időtúllépéssel
3
VM
mindkét mód engedélyezve van, a rendszer kikapcsolása nélkül
4
FVE
VB mód engedélyezve, azonnali leállítás
5
FVME
mindkét mód engedélyezve, azonnali leállítás
Mint már említettük, az Intel BG konfigurációt a rendszergyártónak egyszer s mindenkorra be kell írnia lapkakészlet biztosítékokba (FPF-ekbe) - egy kis (ellenőrizetlen információk szerint csak 256 bájtos) hardveres információtárolóba a chipkészleten belül, amely kívülről programozható. az Intel termelési létesítményeiből (tehát ezért Terepi programozható biztosítékok).
Kiválóan alkalmas konfigurációk tárolására, mert:
- egy egyszer programozható adattároló területtel rendelkezik (pont ott, ahol az Intel BG konfigurációja van írva);
- csak az Intel ME tudja olvasni és programozni.
Tehát az Intel BG technológia konfigurációjának egy adott rendszeren történő beállításához a gyártó a következőket teszi a gyártás során:
- A Flash Image Tool (Intel STK-tól) segítségével létrehoz egy firmware-képet adott Intel BG konfigurációval, mint változókat az Intel ME régión belül (az FPF-ek úgynevezett ideiglenes tükre);
- A Flash Programming Tool (Intel STK-tól) segítségével ezt a képet a rendszer SPI flash memóriájába írja és bezárja az ún. gyártási mód (ebben az esetben a megfelelő parancsot elküldi az Intel ME-nek).
Ezen műveletek eredményeként az Intel ME az ME régióban lévő FPF-ek tükréből leköti a megadott értékeket az FPF-ekre, az SPI flash-leírókban az engedélyeket az Intel által ajánlott értékekre állítja (leírása a cikk elején található). cikk), és hajtsa végre a rendszer VISSZAÁLLÍTÁSÁT.
Intel Boot Guard megvalósítási elemzés
Annak érdekében, hogy egy konkrét példán elemezhessük a technológia megvalósítását, a következő rendszerekben ellenőriztük az Intel BG technológia nyomait:
Rendszer
Megjegyzés
Gigabyte GA-H170-D3H
Skylake, van támogatás
Gigabyte GA-Q170-D3H
Skylake, van támogatás
Gigabyte GA-B150-HD3
Skylake, van támogatás
MSI H170A Gaming Pro
Skylake, nincs támogatás
Lenovo ThinkPad 460
Skylake, támogatás elérhető, technológia engedélyezett
Lenovo Yoga 2 Pro
Haswell, nincs támogatás
Lenovo U330p
Haswell, nincs támogatás
A "támogatás" az Intel BG indító ACM moduljának, a fent említett manifeszteknek és a megfelelő kódnak a BIOS-ban való jelenlétét jelenti, pl. megvalósítások elemzéséhez.
Példaként vegyük az irodából letöltöttet. A gyártó webhelyének képe az SPI flash memóriáról a Gigabyte GA-H170-D3H (F4-es verzió) számára.
Intel CPU indító ROM
Először is beszéljünk a processzor működéséről, ha az Intel BG technológia engedélyezve van.
A dekódolt mikrokódból nem sikerült mintákat találni, ezért nyitott kérdés, hogy az alábbiakban leírt műveletek hogyan valósulnak meg (mikrokódban vagy hardverben). Mindazonáltal tény, hogy a modern Intel processzorok „el tudják” végezni ezeket a műveleteket.
A RESET állapotból való kilépés után a processzor (amelynek címterében már le van képezve a flash memória tartalma) megtalálja a FIT-et (Firmware Interface Table). Megtalálása egyszerű, a mutató az FFFF FFC0h címre van írva.
Ebben a példában ez a cím az FFD6 9500h értéket tartalmazza. Erre a címre fordulva a processzor látja a FIT táblát, melynek tartalma rekordokra van felosztva. Az első bejegyzés a következő szerkezet fejléce:
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;
};
Valamilyen ismeretlen okból ezekben a táblázatokban nem mindig számítják ki az ellenőrző összeget (a mező üres marad).
A fennmaradó bejegyzések különböző binárisokra mutatnak, amelyeket a BIOS végrehajtása előtt elemezni / végrehajtani kell, pl. mielőtt átváltana az örökölt RESET vektorra (FFFF FFF0h). Az egyes bejegyzések felépítése a következő:
typedef struct FIT_ENTRY
{
unsigned long BaseAddress;
unsigned long : 32;
unsigned long Size;
unsigned short Version; // 1.0
unsigned char EntryType;
unsigned char Checksum;
};
Az EntryType mező jelzi a blokk típusát, amelyre ez a bejegyzés mutat. Több fajtáját ismerjük:
enum FIT_ENTRY_TYPES
{
FIT_HEADER = 0,
MICROCODE_UPDATE,
BG_ACM,
BIOS_INIT = 7,
TPM_POLICY,
BIOS_POLICY,
TXT_POLICY,
BG_KEYM,
BG_IBBM
};Most már nyilvánvaló, hogy az egyik bejegyzés az Intel BG indító ACM bináris helyére mutat. Ennek a binárisnak a fejlécstruktúrája jellemző az Intel által fejlesztett kódmodulokra (ACM-ek, mikrokód-frissítések, Intel ME kódrészek, ...).
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];
};
A processzor betölti ezt a bináris fájlt a gyorsítótárába, ellenőrzi és elindítja.
Intel BG indítási ACM
Az ACM munkájának elemzése eredményeként világossá vált, hogy a következőket teszi:
- megkapja az Intel ME-től a lapkakészlet biztosítékaira (FPF) írt Intel BG konfigurációt;
- megkeresi a KEYM és IBBM manifeszteket, ellenőrzi azokat.
A jegyzékek megtalálásához az ACM a FIT táblát is használja, amely kétféle bejegyzéssel mutat rá ezekre a struktúrákra (lásd fent: FIT_ENTRY_TYPES).
Nézzük meg közelebbről a kiáltványokat. Az első jegyzék szerkezetében számos homályos állandót látunk, a második jegyzék nyilvános kulcsának kivonatát, valamint egy nyilvános OEM-gyökérkulcsot, amely beágyazott szerkezetként van aláírva:
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];
};
Az OEM gyökérkulcs nyilvános kulcsának ellenőrzéséhez emlékeztetünk arra, hogy a biztosítékokból származó SHA256 hash-t használjuk, amelyet jelenleg már megkapott az Intel ME.
Térjünk át a második kiáltványra. Három szerkezetből áll:
typedef struct IBB_MANIFEST
{
ACBP Acbp; // Boot policies
IBBS Ibbs; // IBB description
IBB_DESCRIPTORS[];
PMSG Pmsg; // IBBM signature
};Az első tartalmaz néhány állandót:
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
};A második tartalmazza az IBB SHA256 hash-jét, valamint az IBB tartalmát leíró leírók számát (azaz miből számítják ki a hash-t):
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;
};Az IBB leírók ezt a struktúrát követik egymás után. Tartalmuk a következő formátumú:
typedef struct IBB_DESCRIPTOR
{
unsigned long : 32;
unsigned long BaseAddress;
unsigned long Size;
};Egyszerű: minden leíró egy IBB-darab címét/méretét tartalmazza. Így az ezen leírók által mutatott blokkok összefűzése (maguk a leírók sorrendjében) az IBB. És általában az IBB a SEC és PEI fázis összes moduljának kombinációja.
A második jegyzék egy olyan szerkezettel végződik, amely tartalmazza az IBB nyilvános kulcsot (amelyet az SHA256 hash ellenőrzött az első jegyzékből) és a jegyzék aláírását:
typedef struct PMSG
{
char Tag[8]; // ‘__PMSG__’
unsigned char : 8; // 10h
BG_RSA_ENTRY IbbKey;
};
Tehát még az UEFI BIOS végrehajtásának megkezdése előtt a processzor elindítja az ACM-et, amely a SEC és PEI fáziskóddal ellenőrzi a szakaszok tartalmának hitelességét. Ezután a processzor kilép az ACM-ből, a RESET vektor mentén mozog, és megkezdi a BIOS végrehajtását.
A PEI ellenőrzött partíciónak tartalmaznia kell egy modult, amely ellenőrzi a BIOS többi részét (DXE kód). Ezt a modult már az IBV (Independent BIOS Vendor) vagy maga a rendszerszállító fejleszti. Mert Kizárólag Lenovo és Gigabyte rendszerek állnak rendelkezésünkre, és Intel BG támogatással, tekintsük az ezekből a rendszerekből kinyert kódot.
UEFI BIOS modul LenovoVerifiedBootPei
A Lenovo esetében kiderült, hogy a Lenovo által fejlesztett LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} modulról van szó.
Feladata, hogy megkeressen (GUID alapján) egy hash táblát a DXE számára, és ellenőrizze a DXE-t.
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 modul BootGuardPei
A Gigabyte esetében kiderült, hogy az AMI által kifejlesztett BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} modulról van szó, és ezért minden Intel BG támogatással rendelkező AMI BIOS-ban megtalálható.
Működési algoritmusa némileg eltér, de ugyanaz:
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;
}Az általa kikeresett hash-tábla {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} a következő formátumú:
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
Röviden beszéljünk az Intel Boot Guard egy másik megvalósításáról, amelyet egy újabb, Apollo Lake mikroarchitektúrával rendelkező Intel SoC alapú rendszerben találtak meg - ASRock J4205-IT.
Bár ezt a verziót csak SoC-kben fogják használni (a Kaby Lake processzor mikroarchitektúrájú új rendszerek továbbra is az Intel Boot Guard 1.x-et használják), nagy érdeklődésre tart számot az Intel SoC-kon alapuló platformok új architektúra-lehetőségének felfedezése, amely kézzelfoghatónak bizonyult. változások, például:
- A BIOS és az Intel ME régiók (vagy inkább az Intel SoC terminológiája szerint az Intel TXE) immár egy IFWI régió;
- bár az Intel BG engedélyezve volt a platformon, olyan struktúrák, mint a FIT, KEYM, IBBM, nem találhatók a flash memóriában;
- A TXE és ISH magok (x86) mellett egy harmadik mag (egyébként ismét ARC) került a chipkészletbe - PMC (Power Management Controller), amely az energiaellátási alrendszer működőképességének biztosításához és a teljesítmény figyeléséhez kapcsolódik.
Az új IFWI régió tartalma a következő modulokból áll:
elmozdulás
név
Leírás
0000 2000 óra
SMIP
néhány platformkonfiguráció, amelyet a szállító ír alá
0000 6000 óra
RBEP
Intel TXE firmware kódrész, x86, az Intel aláírásával
0001 0000 óra
PMCP
firmware kód szakasz Intel PMC, ARC, az Intel által aláírt
0002 0000 óra
FTPR
Intel TXE firmware kódrész, x86, az Intel aláírásával
0007B000h
UCOD
Az Intel által aláírt CPU mikrokód frissítések
0008 0000 óra
IBBP
UEFI BIOS, SEC/PEI fázisok, x86, gyártó aláírt
0021 8000 óra
ISHC
Az Intel ISH firmware, x86 kódrészlete, amelyet a gyártó aláírt
0025 8000 óra
FTP
Intel TXE firmware kódrész, x86, az Intel aláírásával
0036 1000 óra
IUNP
ismeretlen
0038 1000 óra
OBBP
UEFI BIOS, DXE fázis, x86, aláírás nélküli
A TXE firmware elemzése során nyilvánvalóvá vált, hogy a RESET után a TXE addig tartja ebben az állapotban a processzort, amíg el nem készíti a CPU számára a címtér alaptartalmát (FIT, ACM, RESET vektor ...). Sőt, a TXE ezeket az adatokat az SRAM-jába helyezi, ami után ideiglenesen ott hozzáférést biztosít a processzornak, és „felszabadítja” a RESET-ből.
A rootkitek őrében
Nos, most térjünk át a "melegre". Egyszer felfedeztük, hogy sok rendszerben az SPI flash leírók jogosultsággal rendelkeznek az SPI flash memória régióihoz való hozzáférésre, így ennek a memóriának minden felhasználója írhat és olvashat bármely régiót. Azok. semmiképpen.
A MEinfo segédprogrammal (Intel STK-tól) ellenőrizve azt láttuk, hogy ezeken a rendszereken a gyártási mód nem volt lezárva, ezért a chipkészlet biztosítékai (FPF-ek) határozatlan állapotban maradtak. Igen, az Intel BG ilyen esetekben nincs engedélyezve vagy letiltva.
A következő rendszerekről beszélünk (az Intel BG-vel kapcsolatban, és a cikk későbbi részében leírtakkal kapcsolatban Haswell processzor mikroarchitektúrájú és magasabb rendszerekkel fogunk beszélni):
- minden Gigabyte termék;
- minden MSI termék;
- 21 Lenovo laptop modell és 4 Lenovo szerver modell.
Természetesen jelentettük a leletet ezeknek a gyártóknak, valamint az Intelnek.
Megfelelő válasz csak től következett Lenovoaki elismerte a problémát és .
Gigabyte Úgy tűnik, elfogadtak információt a sérülékenységről, de nem kommentáltak.
Kommunikáció vele MSI teljesen leállt a nyilvános PGP-kulcsunk elküldésére irányuló kérésünkre (a titkosított biztonsági figyelmeztetés elküldése érdekében). Kijelentették, hogy "hardvergyártók, és nem gyártanak PGP-kulcsokat".
De inkább a lényegre. Mivel a biztosítékok definiálatlan állapotban maradnak, a felhasználó (vagy támadó) saját maga programozhatja azokat (a legnehezebb ). Ehhez a következő lépésekre van szükség.
1. Indítsa el a Windows operációs rendszert (általában az alábbiakban leírt lépéseket Linux alatt is meg lehet tenni, ha Intel STK analógját fejleszti a kívánt operációs rendszerhez). A MEinfo segédprogram használatával győződjön meg arról, hogy a rendszer biztosítékai nincsenek beprogramozva.
2. Olvassa el a flash memória tartalmát a Flash Programming Tool segítségével.
3. Nyissa meg az olvasott képet bármely UEFI BIOS szerkesztőeszközzel, hajtsa végre a szükséges módosításokat (például hajtson végre rootkitet), hozza létre / szerkessze a meglévő KEYM és IBBM struktúrákat az ME régióban.
Az RSA kulcs nyilvános része van kiemelve a képen, melynek hash-ét az Intel BG konfiguráció többi részével együtt a chipkészlet biztosítékaiba programozzák.
4. A Flash Image Tool segítségével hozzon létre egy új firmware lemezképet (az Intel BG konfiguráció beállításával).
5. Írjon egy új flash-képet a Flash Programming Tool segítségével, és ellenőrizze a MEinfo segítségével, hogy az ME régió már tartalmazza az Intel BG konfigurációt.
6. A gyártási mód bezárásához használja a Flash programozó eszközt.
7. A rendszer újraindul, majd a MEinfo segítségével ellenőrizheti, hogy az FPF-ek be vannak-e programozva.
Ezek az akciók örökre engedélyezze az Intel BG-t ezen a rendszeren. A műveletet nem lehet visszavonni, ami azt jelenti:
- csak a gyökérkulcs privát részének tulajdonosa (vagyis az, aki engedélyezte az Intel BG-t) tudja frissíteni az UEFI BIOS-t ezen a rendszeren;
- ha például programozó segítségével visszaküldi az eredeti firmware-t ehhez a rendszerhez, az nem is kapcsol be (ellenőrzési hiba esetén a végrehajtási politika következménye);
- hogy megszabaduljon egy ilyen UEFI BIOS-tól, le kell cserélni a programozott FPF-eket tartalmazó chipkészletet egy „tisztára” (azaz újraforrasztani kell a lapkakészletet, ha autó áron van hozzáférése infravörös forrasztóállomáshoz, vagy csak alaplapot kell cserélni ).
Ahhoz, hogy megértse, mire képes egy ilyen rootkit, fel kell mérnie, mi teszi lehetővé a kód futtatását UEFI BIOS környezetben. Mondjuk a processzor legkiváltságosabb módjában - SMM. Egy ilyen rootkit a következő tulajdonságokkal rendelkezhet:
- párhuzamosan kell végrehajtani az operációs rendszerrel (a feldolgozást konfigurálhatja egy SMI megszakítás generálásával, amelyet egy időzítő indít el);
- rendelkezik az SMM mód minden előnyével (teljes hozzáférés a RAM tartalmához és a hardver erőforrásokhoz, az operációs rendszertől való titkosság);
- A rootkit kód titkosítható és visszafejthető, ha SMM módban indítja el. Bármely, csak SMM módban elérhető adat felhasználható titkosítási kulcsként. Például az SMRAM-ban lévő címkészletből származó hash. A kulcs megszerzéséhez be kell másznia az SMM-be. És ezt kétféleképpen lehet megtenni. Keresse meg az RCE-t az SMM kódban, és használja ki, vagy adja hozzá a saját SMM modulját a BIOS-hoz, ami lehetetlen, mivel engedélyeztük a Boot Guard-ot.
Így ez a biztonsági rés lehetővé teszi a támadó számára, hogy:
- hozzon létre egy rejtett, eltávolíthatatlan, ismeretlen célú rootkitet a rendszerben;
- hajtsa végre a kódot az Intel SoC belsejében található chipset magok egyikén, nevezetesen az Intel ISH-n (nézze meg közelebbről a képet).
Bár az Intel ISH alrendszer képességeit még nem tárták fel, érdekes támadási vektornak tűnik az Intel ME ellen.
Álláspontja
- A tanulmány technikai leírást adott az Intel Boot Guard technológia működéséről. Mínusz néhány titka az Intel biztonságának homályos modelljén keresztül.
- Megjelenik egy támadási forgatókönyv, amely lehetővé teszi egy eltávolíthatatlan rootkit létrehozását a rendszerben.
- Láttuk, hogy a modern Intel processzorok már a BIOS elindulása előtt is képesek sok saját kódot végrehajtani.
- Az Intel 64 architektúrájú platformok egyre kevésbé alkalmasak ingyenes szoftverek futtatására: hardverellenőrzés, egyre több szabadalmaztatott technológia és alrendszer (három mag a SoC lapkakészletben: x86 ME, x86 ISH és ARC PMC).
Csökkentések
Azok a szállítók, akik szándékosan hagyják nyitva a gyártási módot, feltétlenül zárják be. Egyelőre csak becsukják a szemüket, és az új Kaby Lake rendszerek ezt mutatják.
A felhasználók letilthatják az Intel BG-t rendszereiken (amelyeket a leírt biztonsági rés érint) a Flash Programming Tool -closemnf kapcsolóval történő futtatásával. Először is meg kell győződnie arról (a MEinfo segítségével), hogy az Intel BG ME régióban lévő konfigurációja lehetővé teszi ennek a technológiának a pontos kikapcsolását az FPF-ekben történő programozás után.
Forrás: will.com