Schrödingerin luotettu saapas. Intel Boot Guard

Ehdotamme laskeutua jälleen matalalle tasolle ja puhua laiteohjelmiston x86-yhteensopivien tietokonealustojen turvallisuudesta. Tällä kertaa tutkimuksen pääainesosa on Intel Boot Guard (ei pidä sekoittaa Intel BIOS Guardiin!) - laitteistotuettu BIOS-luotettava käynnistystekniikka, jonka tietokonejärjestelmän toimittaja voi ottaa käyttöön tai poistaa käytöstä pysyvästi tuotantovaiheessa. No, tiedämme jo tutkimusreseptin: leikkaa tämän tekniikan toteutusta ohueksi käänteistekniikalla, kuvaile sen arkkitehtuuria täyttämällä se dokumentoimattomilla yksityiskohdilla, mausta sitä hyökkäysvektoreilla maun mukaan ja sekoita. Lisätään tulta tarinalla siitä, kuinka useiden valmistajien tuotannossa vuosien ajan kloonattu bugi mahdollistaa potentiaalisen hyökkääjän tämän tekniikan avulla luoda piilotetun rootkitin, jota ei voi poistaa (edes ohjelmoijan toimesta) järjestelmästä.

Muuten, artikkeli perustuu konferenssin raportteihin "On Guard for Rootkits: Intel BootGuard" ZeroNights 2016 ja 29. kokous DefCon Venäjä (molemmat esitykset täällä).

Laiteohjelmisto tietokonealustaan ​​Intel 64 -arkkitehtuurilla

Aluksi vastataan kysymykseen: mikä on Intel 64 -arkkitehtuurilla varustetun nykyaikaisen tietokonealustan laiteohjelmisto? Tietenkin UEFI BIOS. Mutta tämä vastaus ei ole tarkka. Katsotaanpa kuvaa, joka esittää tämän arkkitehtuurin työpöytäversion (kannettava tietokone).

Pohja on linkki:

• Prosessori (CPU, Central Processing Unit), jossa on pääytimien lisäksi sisäänrakennettu grafiikkaydin (ei kaikissa malleissa) ja muistiohjain (IMC, Integrated Memory Controller);
• Piirisarja (PCH, Platform Controller Hub), joka sisältää erilaisia ​​ohjaimia vuorovaikutukseen oheislaitteiden kanssa ja alijärjestelmien hallintaan. Niiden joukossa on pahamaineinen Intel Management Engine (ME), jolla on myös laiteohjelmisto (Intel ME firmware).

Kannettavat vaativat edellä mainittujen lisäksi integroidun ohjaimen (ACPI EC, Advanced Control and Power Interface Embedded Controller), joka vastaa tehoalijärjestelmän toiminnasta, kosketuslevystä, näppäimistöstä, Fn-näppäimistä (näytön kirkkaus, äänenvoimakkuus, näppäimistö). taustavalo jne.) ja paljon muuta. Ja hänellä on myös oma laiteohjelmisto.

Joten yllä olevan laiteohjelmiston yhdistelmä on tietokonealustan laiteohjelmisto (järjestelmän laiteohjelmisto), joka on tallennettu yhteiseen SPI-flash-muistiin. Jotta tämän muistin käyttäjät eivät hämmentyisi, missä joku makaa, tämän muistin sisältö on jaettu seuraaviin alueisiin (kuten kuvassa):

• UEFI BIOS;
• ACPI EC -laiteohjelmisto (erillinen alue ilmestyi Skylake-prosessorin mikroarkkitehtuurilla (2015), mutta luonnossa emme ole vielä nähneet esimerkkejä sen käytöstä, joten sulautetun ohjaimen laiteohjelmisto on edelleen osa UEFI BIOS:ia);
• Intel ME firmware;
• sisäänrakennetun GbE (Gigabit Ethernet) -verkkosovittimen konfigurointi (MAC-osoite jne.);
• flash-kuvaukset - flash-muistin pääalue, joka sisältää osoittimia muille alueille sekä käyttöoikeudet niihin.

Alueille pääsyn eriyttämisestä (määritettyjen oikeuksien mukaisesti) huolehtii SPI-väyläisäntä - piirisarjaan sisäänrakennettu SPI-ohjain, jonka kautta tätä muistia käytetään. Jos käyttöoikeudet on asetettu Intelin (turvallisuussyistä) suosittelemiin arvoihin, jokaisella SPI-flashin käyttäjällä on täysi pääsy (luku/kirjoitus) vain omalle alueelleen. Loput ovat joko vain luku -tilassa tai eivät ole käytettävissä. Tunnettu tosiasia: monissa järjestelmissä suorittimella on täysi pääsy UEFI BIOSiin ja GbE:hen, lukuoikeus vain flash-kuvauksiin, eikä Intel ME -alueeseen ollenkaan pääsyä. Miksi monet eivätkä kaikki? Se, mitä suositellaan, on valinnaista. Kerromme sinulle lisää myöhemmin artikkelissa.

Mekanismit tietokonealustan laiteohjelmiston suojaamiseksi muutoksilta

Ilmeisesti tietokonealustan laiteohjelmisto tulee suojata mahdolliselta kompromissilta, mikä antaisi mahdolliselle hyökkääjälle jalansijaa siinä (selviytyä käyttöjärjestelmän päivityksistä / uudelleenasennuksista), suorittaa koodinsa etuoikeutetuimmissa tiloissa jne. Ja pääsyn rajoittaminen SPI-flash-muistialueille ei tietenkään riitä. Siksi erilaisia ​​kullekin suoritusympäristölle ominaisia ​​mekanismeja käytetään suojaamaan laiteohjelmistoa muutoksilta.

Joten Intel ME -laiteohjelmisto on allekirjoitettu eheyden ja aitouden valvontaa varten, ja ME-ohjain tarkistaa sen aina, kun se ladataan ME UMA -muistiin. Olemme jo keskustelleet tästä vahvistusprosessista yhdessä artikkelitomistettu Intel ME -alijärjestelmälle.

Ja ACPI EC -laiteohjelmisto tarkistetaan yleensä vain eheyden suhteen. Kuitenkin, koska tämä binaari sisältyy UEFI BIOSiin, siihen sovelletaan lähes aina samoja suojausmekanismeja, joita UEFI BIOS käyttää. Puhutaanpa niistä.

Nämä mekanismit voidaan jakaa kahteen luokkaan.

Kirjoitussuojaus UEFI BIOS -alueelle

1. SPI-flash-muistin sisällön fyysinen suojaus kirjoitussuojaussuojalla;
2. UEFI BIOS -alueen projisoinnin suojaus CPU-osoiteavaruudessa piirisarjan PRx-rekistereillä;
3. Estetään yritykset kirjoittaa UEFI BIOS -alueelle generoimalla ja käsittelemällä vastaava SMI-keskeytys asettamalla BIOS_WE / BLE- ja SMM_BWP-bitit piirisarjarekistereihin;
4. Tämän suojauksen edistyneempi versio on Intel BIOS Guard (PFAT).

Näiden mekanismien lisäksi toimittajat voivat kehittää ja toteuttaa omia turvatoimiaan (esimerkiksi allekirjoittaa kapseleita UEFI BIOS -päivityksillä).

On tärkeää huomata, että tietyssä järjestelmässä (riippuen toimittajasta) kaikkia yllä olevia suojamekanismeja ei välttämättä sovelleta, niitä ei välttämättä sovelleta ollenkaan tai ne voidaan toteuttaa haavoittuvalla tavalla. Näistä mekanismeista ja niiden toteutustilanteesta voit lukea lisää osoitteesta tässä artikkelissa. Kiinnostuneille suosittelemme lukemaan koko artikkelisarjan UEFI BIOS -tietoturvasta CodeRush.

UEFI BIOS -todennuksen vahvistus

Kun puhumme luotetuista käynnistystekniikoista, ensimmäinen asia, joka tulee mieleen, on Secure Boot. Arkkitehtonisesti se on kuitenkin suunniteltu todentamaan UEFI BIOSin ulkopuoliset komponentit (ohjaimet, latauslaitteet jne.), ei itse laiteohjelmistoa.

Siksi Intel SoC:issa Bay Trail -mikroarkkitehtuurilla (2012) otti käyttöön laitteistolla ei-vaihdettavan Secure Bootin (Verified Boot), jolla ei ole mitään tekemistä edellä mainitun Secure Boot -tekniikan kanssa. Myöhemmin (2013) tätä mekanismia parannettiin ja Intel Boot Guard -nimellä se julkaistiin pöytäkoneille, joissa oli Haswell-mikroarkkitehtuuri.

Ennen kuin kuvaat Intel Boot Guardia, katsotaanpa Intel 64 -arkkitehtuurin suoritusympäristöjä, jotka yhdessä ovat tämän luotettavan käynnistystekniikan luottamuksen juuret.

Intel CPU

Cap ehdottaa, että prosessori on tärkein suoritusympäristö Intel 64 -arkkitehtuurissa. Miksi se on myös luottamuksen juuri? Osoittautuu, että seuraavien elementtien hallussapito tekee siitä niin:

• Microcode ROM on haihtumaton, ei uudelleenkirjoitettava muisti mikrokoodin tallentamiseen. Mikrokoodin uskotaan olevan prosessorin käskyjärjestelmän toteutus yksinkertaisimmilla käskyillä. Tapahtuu myös mikrokoodissa Bugs. Joten BIOSista löydät binaarit, joissa on mikrokoodipäivityksiä (ne ovat päällekkäin käynnistyksen yhteydessä, koska ROM:ia ei voi korvata). Näiden binaarien sisältö on salattu, mikä vaikeuttaa suuresti analysointia (siten mikrokoodin erityinen sisältö on vain sen kehittäjien tiedossa) ja allekirjoitettu eheyden ja aitouden valvomiseksi;
• AES-avain mikrokoodipäivitysten sisällön salauksen purkamiseen;
• julkisen RSA-avaimen tiiviste, joka varmistaa mikrokoodipäivitysten allekirjoituksen;
• RSA-julkisen avaimen hash, joka tarkistaa Intelin kehittämien ACM (Authenticated Code Module) -koodimoduulien allekirjoitukset, joita CPU voi suorittaa ennen BIOSin käynnistymistä (hello mikrokoodi) tai sen toiminnan aikana, kun jotain tapahtuu.

Intel ME

Tämä blogimme alajärjestelmä oli omistettu kaksi Artikkeli. Muista, että tämä suoritettava ympäristö perustuu piirisarjaan sisäänrakennettuun mikro-ohjaimeen ja on järjestelmän piilotetuin ja etuoikeutetuin.

Hiljaisuudesta huolimatta Intel ME on myös luottamuksen juuri, koska sillä on:

• ME ROM - haihtumaton, ei-uudelleenkirjoitettava muisti (ei päivitysmenetelmää), joka sisältää aloituskoodin sekä julkisen RSA-avaimen SHA256-tiivisteen, joka tarkistaa Intel ME -laiteohjelmiston allekirjoituksen;
• AES-avain salaisten tietojen tallentamiseen;
• pääsy piirisarjaan integroituihin sulakkeisiin (FPF:t, Field Programmable Fuses) joidenkin tietojen, mukaan lukien tietokonejärjestelmän toimittajan määrittämien tietojen, pysyvää tallennusta varten.

Intel Boot Guard 1.x

Pieni vastuuvapauslauseke. Tässä artikkelissa käyttämämme Intel Boot Guard -tekniikan versionumerot ovat mielivaltaisia, eikä niillä välttämättä ole mitään tekemistä Intelin sisäisessä dokumentaatiossa käytetyn numeroinnin kanssa. Lisäksi tässä annetut tiedot tämän tekniikan käyttöönotosta on saatu käänteisen suunnittelun aikana, ja ne voivat sisältää epätarkkuuksia verrattuna Intel Boot Guard -spesifikaatioon, jota ei todennäköisesti koskaan julkaista.

Joten Intel Boot Guard (BG) on laitteistotuettu UEFI BIOS -todennustekniikka. Kirjassa [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot] olevasta pienestä kuvauksesta päätellen se toimii luotettavana käynnistysketjuna. Ja ensimmäinen linkki siinä on CPU:n sisällä oleva käynnistyskoodi (mikrokoodi), jonka RESET-tapahtuma laukaisee (ei pidä sekoittaa BIOSin RESET-vektoriin!). Prosessori löytää SPI-flash-muistista Intelin kehittämän ja allekirjoittaman koodimoduulin (Intel BG startup ACM), lataa sen välimuistiinsa, tarkistaa sen (yllä mainittiin jo, että suorittimessa on julkisen avaimen hash, joka varmistaa ACM-allekirjoituksen ) ja alkaa.

Tämä koodimoduuli vastaa UEFI BIOSin pienen aloitusosan tarkistamisesta - Initial Boot Block (IBB), joka puolestaan ​​sisältää toiminnot UEFI BIOSin pääosan tarkistamiseksi. Näin ollen Intel BG:n avulla voit varmistaa BIOSin aitouden ennen käyttöjärjestelmän käynnistämistä (joka voidaan suorittaa Secure Boot -tekniikan valvonnassa).

Intel BG -tekniikka tarjoaa kaksi toimintatilaa (ja toinen ei häiritse toista, eli molemmat tilat voidaan ottaa käyttöön järjestelmässä ja molemmat voidaan poistaa käytöstä).

Mitattu Boot

Mitattu käynnistys (MB) -tilassa jokainen käynnistyskomponentti (alkaen CPU:n käynnistysROM-muistista) "mittaa" seuraavan käyttämällä Trusted Platform Module (TPM) -moduulin ominaisuuksia. Niille, jotka eivät tiedä, anna minun selittää.

TPM:ssä on PCR:t (Platform Configuration Registers), jotka tallentavat hajautustoiminnon tuloksen seuraavan kaavan mukaan:

Nuo. nykyinen PCR-arvo riippuu edellisestä, ja nämä rekisterit nollataan vain, kun järjestelmä RESET.

Siten MB-tilassa jossain vaiheessa PCR:t heijastavat "mitatun" koodin tai datan ainutlaatuista (hajautustoiminnon kykyjen puitteissa) tunnistetta. PCR-arvoja voidaan käyttää joidenkin tietojen salaukseen (TPM_Seal). Sen jälkeen niiden salauksen purku (TPM_Unseal) on mahdollista vain, jos PCR-arvot eivät ole muuttuneet latauksen seurauksena (eli yhtäkään "mitattua" komponenttia ei ole muokattu).

Vahvistettu käynnistys

Pelottavin asia niille, jotka haluavat muokata UEFI BIOS:ia, on Verified Boot (VB) -tila, jossa jokainen käynnistyskomponentti varmistaa salausteknisesti seuraavan eheyden ja aitouden. Ja jos tapahtuu vahvistusvirhe, tapahtuu (jokin seuraavista):

• sammutus aikakatkaisulla 1 minuutista 30 minuuttiin (jotta käyttäjällä on aikaa ymmärtää, miksi hänen tietokoneensa ei käynnisty, ja jos mahdollista yrittää palauttaa BIOSin);
• välitön sammutus (jotta käyttäjällä ei ole aikaa ymmärtää ja lisäksi tehdä);
• työn jatkaminen suoralla kasvoilla (tapaus, jossa ei ole aikaa turvallisuuteen, koska on tärkeämpää tekemistä).

Toimenpiteen valinta riippuu määritetystä Intel BG -kokoonpanosta (eli ns. täytäntöönpanokäytännöstä), jonka tietokonealustan toimittaja tallentaa pysyvästi erityisesti suunniteltuun tallennustilaan - piirisarjan sulakkeet (FPF). Pysähdymme tähän kohtaan tarkemmin myöhemmin.

Kokoonpanon lisäksi toimittaja luo kaksi RSA 2048 -avainta ja luo kaksi tietorakennetta (näkyy kuvassa):

1. Toimittajan juuriavaimen luettelo (KEYM, OEM Root Key Manifest), joka asettaa tämän luettelon SVN:n (suojausversionumeron), seuraavan luettelon julkisen avaimen SHA256-tiivisteen, julkisen RSA-avaimen (eli luettelon julkisen osan) toimittajan juuriavain) tämän luettelon allekirjoituksen ja itse allekirjoituksen tarkistamiseksi;
2. IBB-luettelo (IBBM, Initial Boot Block Manifest), joka asettaa tämän luettelon SVN:n, IBB:n SHA256-tiivisteen, julkisen avaimen tämän luettelon allekirjoituksen tarkistamiseksi ja itse allekirjoituksen.

OEM-juuriavaimen SHA256-tiiviste kirjoitetaan pysyvästi piirisarjan sulakkeisiin (FPF), aivan kuten Intel BG -kokoonpanossa. Jos Intel BG -kokoonpano mahdollistaa tämän tekniikan sisällyttämisen, tästä lähtien vain OEM-juuriavaimen yksityisen osan omistaja voi päivittää BIOS:n (eli laskea nämä manifestit uudelleen), ts. myyjä.

Kun katsot kuvaa, herää välittömästi epäilys näin pitkän varmennusketjun tarpeesta - olisit voinut käyttää yhtä manifestia. Miksi monimutkaista?

Itse asiassa Intel tarjoaa siten toimittajalle mahdollisuuden käyttää erilaisia ​​IBB-avaimia eri tuotelinjoille ja yhtä juurina. Jos IBB-avaimen yksityinen osa (joka allekirjoittaa toisen luettelon) vuotaa, tapahtuma vaikuttaa vain yhteen tuotelinjaan ja vain siihen asti, kunnes toimittaja luo uuden parin ja ottaa käyttöön uudelleen lasketut luettelot seuraavassa BIOS-päivityksessä.

Mutta jos juuriavain vaarantuu (jolla ensimmäinen manifesti on allekirjoitettu), sitä ei voida korvata, peruutusmenettelyä ei tarjota. tämän avaimen julkisen osan hash ohjelmoidaan lopullisesti FPF:iin.

Intel Boot Guard -kokoonpano

Katsotaanpa nyt lähemmin Intel BG -kokoonpanoa ja sen luomisprosessia. Jos katsot vastaavaa välilehteä Intel System Tool Kitin (STK) Flash Image Toolin graafisessa käyttöliittymässä, huomaat, että Intel BG -kokoonpano sisältää toimittajan juuriavaimen julkisen osan tiivisteen, pari epäselvää. arvot ja niin edelleen. Intel BG -profiili.

Tämän profiilin rakenne:

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

Yleisesti ottaen Intel BG -kokoonpano on erittäin joustava kokonaisuus. Harkitse esimerkiksi Force_Boot_Guard_ACM-lippua. Kun se on tyhjennetty, jos SPI-flashin BG-käynnistys-ACM-moduulia ei löydy, luotettua käynnistystä ei tapahdu. Siitä tulee epäluotettava.

Kirjoitimme jo yllä, että VB-tilan täytäntöönpanokäytäntö voidaan konfiguroida niin, että jos vahvistus epäonnistuu, tapahtuu jälleen epäluotettava lataus.

Jätä tällaiset asiat myyjille...

Apuohjelman graafinen käyttöliittymä tarjoaa seuraavat "valmiit" profiilit:

Nro
järjestelmä
Kuvaus

0
Ei_FVME
Intel BG -tekniikka pois käytöstä

1
VE
VB-tila käytössä, sammutus aikakatkaisulla

2
VME
molemmat tilat ovat käytössä (VB ja MB), sammutus aikakatkaisulla

3
VM
molemmat tilat ovat käytössä sammuttamatta järjestelmää

4
FVE
VB-tila käytössä, välitön sammutus

5
FVME
molemmat tilat käytössä, välitön sammutus

Kuten jo mainittiin, järjestelmän toimittajan on kirjoitettava Intel BG -kokoonpano lopullisesti piirisarjan sulakkeisiin (FPF) - pieneen (todentamattomien tietojen mukaan vain 256 tavua) laitteistotietovarastoon piirisarjan sisällä, joka voidaan ohjelmoida sen ulkopuolelle. Intelin tuotantolaitoksista (joten siksi Kentällä ohjelmoitava sulakkeet).

Se sopii erinomaisesti asetusten tallentamiseen, koska:

• sisältää kertakäyttöisen ohjelmoitavan tiedontallennusalueen (vain sinne, missä Intel BG -kokoonpano kirjoitetaan);
• vain Intel ME voi lukea ja ohjelmoida sen.

Jotta Intel BG -tekniikan asetukset voidaan määrittää tietyssä järjestelmässä, toimittaja tekee tuotannon aikana seuraavat toimet:

1. Flash Image Tool -apuohjelman (Intel STK:lta) avulla luodaan laiteohjelmistokuva tietyllä Intel BG -kokoonpanolla muuttujina Intel ME -alueen sisällä (ns. väliaikainen peili FPF:ille);
2. Flash Programming Tool -työkalulla (Intel STK:lta) kirjoittaa tämän kuvan järjestelmän SPI-flash-muistiin ja sulkee ns. valmistustila (tässä tapauksessa vastaava komento lähetetään Intel ME:lle).

Näiden toimintojen tuloksena Intel ME sitoutuu FPF:ihin annetut arvot peilistä ME-alueen FPF:ille, asettaa SPI-flash-kuvaajien luvat Intelin suosittelemiin arvoihin (kuvattu julkaisun alussa). artikkeli) ja suorita järjestelmän RESET.

Intel Boot Guard -toteutusanalyysi

Analysoidaksemme tämän tekniikan toteutusta tietyssä esimerkissä, tarkistimme seuraavista järjestelmistä Intel BG -tekniikan jälkiä:

Järjestelmä
Huomata

Gigabyte GA-H170-D3H
Skylake, siellä on tukea

Gigabyte GA-Q170-D3H
Skylake, siellä on tukea

Gigabyte GA-B150-HD3
Skylake, siellä on tukea

MSI H170A Gaming Pro
Skylake, ei tukea

Lenovo ThinkPad 460
Skylake, tuki saatavilla, tekniikka käytössä

Lenovo Yoga 2 Pro
Haswell, ei tukea

Lenovo U330p
Haswell, ei tukea

"Tuki" tarkoittaa Intel BG -käynnistys ACM -moduulin, yllä mainittujen manifestien ja vastaavan koodin läsnäoloa BIOSissa, ts. toteutuksia analysointia varten.

Otetaan esimerkkinä toimistosta ladattu. toimittajasivuston kuva SPI-flash-muistista Gigabyte GA-H170-D3H:lle (versio F4).

Intel CPU boot ROM

Ensinnäkin puhutaan prosessorin toimista, jos Intel BG -tekniikka on käytössä.

Salauksesta puretusta mikrokoodista ei löytynyt näytteitä, joten se, miten alla kuvatut toimet toteutetaan (mikrokoodissa tai laitteistossa), on avoin kysymys. Siitä huolimatta, että nykyaikaiset Intel-prosessorit "voivat" suorittaa nämä toiminnot, on tosiasia.

Palattuaan RESET-tilasta prosessori (jonka osoiteavaruudessa flash-muistin sisältö on jo kartoitettu) löytää FIT (Firmware Interface Table). Sen löytäminen on helppoa, osoitin siihen kirjoitetaan osoitteeseen FFFF FFC0h.

Tässä esimerkissä tämä osoite sisältää arvon FFD6 9500h. Kääntyessään tähän osoitteeseen prosessori näkee FIT-taulukon, jonka sisältö on jaettu tietueisiin. Ensimmäinen merkintä on seuraavan rakenteen otsikko:

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

Jostain tuntemattomasta syystä tarkistussummaa ei aina lasketa näissä taulukoissa (kenttä jätetään tyhjäksi).

Loput merkinnät viittaavat erilaisiin binääriin, jotka on jäsennettävä / suoritettava ennen BIOSin suorittamista, ts. ennen kuin vaihdat vanhaan RESET-vektoriin (FFFF FFF0h). Kunkin tällaisen merkinnän rakenne on seuraava:

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

EntryType-kenttä osoittaa lohkotyypin, johon tämä syöttö osoittaa. Tiedämme useita tyyppejä:

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

Nyt on ilmeistä, että yksi merkinnöistä osoittaa Intel BG:n käynnistyksen ACM-binaarin sijaintiin. Tämän binaarin otsikkorakenne on tyypillinen Intelin kehittämille koodimoduuleille (ACM:t, mikrokoodipäivitykset, Intel ME -koodiosat, ...).

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

Prosessori lataa tämän binaarin välimuistiinsa, tarkistaa ja käynnistää.

Intel BG käynnistys ACM

Tämän ACM:n työn analyysin tuloksena kävi selväksi, että se tekee seuraavaa:

• vastaanottaa Intel ME:ltä piirisarjan sulakkeisiin (FPF) kirjoitetun Intel BG -konfiguraation;
• löytää KEYM- ja IBBM-luettelot, tarkistaa ne.

Näiden luetteloiden löytämiseen ACM käyttää myös FIT-taulukkoa, jossa on kahden tyyppisiä merkintöjä, jotka osoittavat näihin rakenteisiin (katso FIT_ENTRY_TYPES yllä).

Katsotaanpa manifesteja tarkemmin. Ensimmäisen luettelon rakenteessa näemme useita epäselviä vakioita, toisen luettelon julkisen avaimen tiivisteen ja julkisen OEM-juuriavaimen, joka on allekirjoitettu sisäkkäisenä rakenteena:

typedef struct KEY_MANIFEST
{
	char           Tag[8];          // ‘__KEYM__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned char  : 8;             // 1
	unsigned short : 16;            // 0Bh
	unsigned short : 16;            // 20h == hash size?
	unsigned char  IbbmKeyHash[32]; // SHA256 of an IBBM public key
	BG_RSA_ENTRY   OemRootKey;
};

typedef struct BG_RSA_ENTRY
{
	unsigned char  : 8;             // 10h
	unsigned short : 16;            // 1
	unsigned char  : 8;             // 10h
	unsigned short RsaPubKeySize;   // 800h
	unsigned long  RsaPubExp;
	unsigned char  RsaPubKey[256];
	unsigned short : 16;            // 14
	unsigned char  : 8;             // 10h
	unsigned short RsaSigSize;      // 800h
	unsigned short : 16;            // 0Bh
	unsigned char  RsaSig[256];
};

OEM-juuriavaimen julkisen avaimen tarkistamiseksi muistamme, että käytetään sulakkeiden SHA256-tiivistettä, joka on tällä hetkellä jo vastaanotettu Intel ME:ltä.

Siirrytään toiseen manifestiin. Se koostuu kolmesta rakenteesta:

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

Ensimmäinen sisältää joitain vakioita:

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

Toinen sisältää IBB:n SHA256-tiivisteen ja IBB:n sisältöä kuvaavien kuvaajien lukumäärän (eli mistä hash lasketaan):

typedef struct IBBS
{
	char           Tag[8];            // ‘__IBBS__’
	unsigned char  : 8;               // 10h
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // x <= 0Fh
	unsigned long  : 32;              // x & FFFFFFF8h = 0
	unsigned long  Unknown[20];
	unsigned short : 16;              // 0Bh
	unsigned short : 16;              // 20h == hash size ?
	unsigned char  IbbHash[32];       // SHA256 of an IBB
	unsigned char  NumIbbDescriptors;
};

IBB-kuvaajat noudattavat tätä rakennetta yksi toisensa jälkeen. Niiden sisältö on seuraavassa muodossa:

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

Se on yksinkertaista: jokainen kuvaaja sisältää IBB-palan osoitteen/koon. Siten näiden kuvaajien osoittamien lohkojen ketjutus (itse kuvaajien järjestyksessä) on IBB. Ja yleensä IBB on yhdistelmä kaikista SEC- ja PEI-vaiheiden moduuleista.

Toinen luettelo päättyy rakenteeseen, joka sisältää IBB:n julkisen avaimen (joka on vahvistettu SHA256-tiivisteellä ensimmäisestä luettelosta) ja tämän luettelon allekirjoituksen:

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

Joten jo ennen UEFI BIOS -suorituksen alkamista prosessori käynnistää ACM:n, joka tarkistaa osioiden sisällön aitouden SEC- ja PEI-vaihekoodilla. Seuraavaksi prosessori poistuu ACM:stä, liikkuu RESET-vektoria pitkin ja aloittaa BIOSin suorittamisen.

PEI-vahvistetun osion on sisällettävä moduuli, joka tarkistaa loput BIOSista (DXE-koodi). Tätä moduulia kehittää jo IBV (Independent BIOS Vendor) tai itse järjestelmän toimittaja. Koska Ainoastaan ​​Lenovo- ja Gigabyte-järjestelmät osoittautuivat käytettävissämme ja Intel BG-tuen ansiosta harkitaan näistä järjestelmistä poimittua koodia.

UEFI BIOS -moduuli LenovoVerifiedBootPei

Lenovon tapauksessa se osoittautui Lenovon kehittämäksi LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} -moduuliksi.

Sen tehtävänä on etsiä (GUID:n avulla) hajautustaulukko DXE:lle ja tarkistaa 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 -moduuli BootGuardPei

Gigabyten tapauksessa se osoittautui BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} -moduuliksi, jonka on kehittänyt AMI ja joka on siksi läsnä missä tahansa Intel BG -tuella varustetussa AMI BIOSissa.

Sen toiminta-algoritmi on hieman erilainen, mutta se tiivistyy samaan:

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

Hash-taulukon {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} muoto on seuraava:

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

Puhutaanpa lyhyesti toisesta Intel Boot Guardin toteutuksesta, joka löytyi uudemmasta Intel SoC:hen perustuvasta Apollo Lake -mikroarkkitehtuurilla varustetusta järjestelmästä - ASRock J4205-IT.

Vaikka tätä versiota käytetään vain SoC:issa (uudet järjestelmät, joissa on Kaby Lake -prosessorimikroarkkitehtuuri, käyttävät edelleen Intel Boot Guard 1.x:tä), on erittäin mielenkiintoista tutkia Intelin SoC:ihin perustuvien alustojen uutta arkkitehtuurivaihtoehtoa, joka on nähty konkreettisesti. muutoksia, esim.

• BIOS- ja Intel ME -alueet (tai pikemminkin Intel TXE Intel SoC -terminologian mukaan) ovat nyt yksi IFWI-alue;
• vaikka Intel BG oli käytössä alustalla, rakenteita, kuten FIT, KEYM, IBBM, ei löytynyt flash-muistista;
• TXE- ja ISH-ytimien (x86) lisäksi piirisarjaan lisättiin kolmas ydin (muuten, jälleen ARC) - PMC (Power Management Controller), joka liittyy tehoalijärjestelmän toimivuuden varmistamiseen ja suorituskyvyn valvontaan.

Uuden IFWI-alueen sisältö koostuu seuraavista moduuleista:

siirtymä
nimi
Kuvaus

0000h
SMIP
toimittajan allekirjoittama alustakokoonpano

0000h
RBEP
Intelin TXE-laiteohjelmiston koodiosa, x86, Intelin allekirjoittama

0001h
PMCP
laiteohjelmiston koodiosio Intel PMC, ARC, Intelin allekirjoittama

0002h
FTPR
Intelin TXE-laiteohjelmiston koodiosa, x86, Intelin allekirjoittama

0007B000h
UCOD
Intelin allekirjoittamat suorittimen mikrokoodipäivitykset

0008h
IBBP
UEFI BIOS, SEC/PEI-vaiheet, x86, toimittajan allekirjoitus

0021h
ISHC
Intel ISH -laiteohjelmiston x86 koodiosio, jonka myyjä on allekirjoittanut

0025h
NFTP
Intelin TXE-laiteohjelmiston koodiosa, x86, Intelin allekirjoittama

0036h
IUNP
on tuntematon

0038h
OBBP
UEFI BIOS, DXE-vaihe, x86, allekirjoittamaton

TXE-laiteohjelmiston analysoinnin aikana kävi selväksi, että RESET-toiminnon jälkeen TXE pitää prosessorin tässä tilassa, kunnes se valmistelee CPU:n osoiteavaruuden perussisällön (FIT, ACM, RESET-vektori ...). Lisäksi TXE sijoittaa nämä tiedot SRAM-muistiinsa, minkä jälkeen se antaa prosessorille tilapäisesti pääsyn sinne ja "vapauttaa" sen RESET-toiminnosta.

Vartioi rootkitteja

No, siirrytään nyt "kuumaan". Havaitsimme kerran, että monissa järjestelmissä SPI-flash-kuvaajilla on oikeudet käyttää SPI-flash-muistin alueita, jotta kaikki tämän muistin käyttäjät voivat sekä kirjoittaa että lukea mitä tahansa aluetta. Nuo. ei onnistu.

Tarkistettuamme MEinfo-apuohjelmalla (Intel STK:lta) huomasimme, että valmistustila näissä järjestelmissä ei ollut suljettu, joten piirisarjan sulakkeet (FPF:t) jäivät määrittelemättömään tilaan. Kyllä, Intel BG ei ole käytössä tai poistettu käytöstä tällaisissa tapauksissa.

Puhumme seuraavista järjestelmistä (Intel BG:n osalta ja mitä myöhemmin artikkelissa kuvataan, puhumme järjestelmistä, joissa on Haswell-prosessorimikroarkkitehtuuri tai uudempi):

• kaikki Gigabyte tuotteet;
• kaikki MSI tuotteet;
• 21 Lenovon kannettavaa mallia ja 4 Lenovon palvelinmallia.

Tietysti ilmoitimme löydöstä näille myyjille sekä Intelille.

Riittävä vastaus seurasi vasta Lenovojoka myönsi ongelman ja julkaisi korjaustiedoston.

Gigabyte Vaikuttaa siltä, ​​että he ottivat vastaan ​​tiedon haavoittuvuudesta, mutta eivät kommentoineet millään tavalla.

Viestintä kanssa MSI täysin pysähtynyt pyynnöstämme lähettää julkinen PGP-avaimemme (johdetaan lähettää heille salattu tietoturvatiedote). He ilmoittivat olevansa laitteiston valmistajia eivätkä valmista PGP-avaimia.

Mutta enemmän asiaan. Koska sulakkeet jätetään määrittelemättömään tilaan, käyttäjä (tai hyökkääjä) voi ohjelmoida ne itse (vaikein on Etsi Intel STK). Tämä vaatii seuraavat vaiheet.

1. Käynnistä Windows-käyttöjärjestelmä (yleensä alla kuvatut vaiheet voidaan tehdä myös Linuxista, jos kehität Intel STK:n analogisen halutulle käyttöjärjestelmälle). Varmista MEinfo-apuohjelman avulla, että tämän järjestelmän sulakkeita ei ole ohjelmoitu.

2. Lue flash-muistin sisältö Flash-ohjelmointityökalulla.

3. Avaa lukukuva millä tahansa UEFI BIOS -muokkaustyökalulla, tee tarvittavat muutokset (toteuta esimerkiksi rootkit), luo / muokkaa olemassa olevia KEYM- ja IBBM-rakenteita ME-alueella.

Kuvassa on korostettuna RSA-avaimen julkinen osa, jonka hash ohjelmoidaan piirisarjan sulakkeisiin yhdessä muun Intel BG -kokoonpanon kanssa.

4. Luo uusi laiteohjelmiston näköistiedosto Flash Image Tool -työkalulla (asettamalla Intel BG -kokoonpano).

5. Kirjoita uusi flash-kuva Flash-ohjelmointityökalulla, varmista MEinfolla, että ME-alue sisältää nyt Intel BG -kokoonpanon.

6. Sulje valmistustila Flash-ohjelmointityökalulla.

7. Järjestelmä käynnistyy uudelleen, minkä jälkeen MEinfon avulla voit varmistaa, että FPF:t on nyt ohjelmoitu.

Nämä toimet ikuisesti ota Intel BG käyttöön tässä järjestelmässä. Toiminnon kumoaminen on mahdotonta, mikä tarkoittaa:

• vain juuriavaimen yksityisen osan omistaja (eli se, joka on ottanut käyttöön Intel BG:n) voi päivittää UEFI BIOSin tässä järjestelmässä;
• jos palautat alkuperäisen laiteohjelmiston tähän järjestelmään esimerkiksi ohjelmoijan avulla, se ei edes käynnisty (seuraus valvontakäytännöstä vahvistusvirheen sattuessa);
• päästäksesi eroon tällaisesta UEFI BIOSista, sinun on korvattava piirisarja ohjelmoiduilla FPF:illä "puhtaalla" (eli juota piirisarja uudelleen, jos sinulla on pääsy infrapunajuotosasemaan auton hinnalla, tai vaihda vain emolevy ).

Ymmärtääksesi, mitä tällainen rootkit voi tehdä, sinun on arvioitava, mikä mahdollistaa koodisi suorittamisen UEFI BIOS -ympäristössä. Sano, prosessorin etuoikeutetuimmassa tilassa - SMM. Tällaisella rootkitillä voi olla seuraavat ominaisuudet:

• suoritetaan rinnakkain käyttöjärjestelmän kanssa (voit määrittää käsittelyn luomalla SMI-keskeytyksen, jonka ajastin laukaisee);
• niillä on kaikki SMM-tilan edut (täysi pääsy RAM-muistin ja laitteistoresurssien sisältöön, käyttöjärjestelmän salaisuus);
• Rootkit-koodi voidaan salata ja purkaa, kun se käynnistetään SMM-tilassa. Kaikkia vain SMM-tilassa saatavilla olevia tietoja voidaan käyttää salausavaimena. Esimerkiksi hajautus SMRAM-muistissa olevien osoitejoukosta. Saadaksesi tämän avaimen sinun on kiivettävä SMM:ään. Ja tämä voidaan tehdä kahdella tavalla. Etsi RCE SMM-koodista ja hyödynnä sitä tai lisää oma SMM-moduuli BIOSiin, mikä on mahdotonta, koska otimme käyttöön Boot Guardin.

Näin ollen tämä haavoittuvuus antaa hyökkääjälle mahdollisuuden:

• luoda piilotettu, irrotettava rootkit, jonka tarkoitus on tuntematon järjestelmään;
• suorita koodisi jollakin Intel SoC:n sisällä olevista piirisarjan ytimistä, nimittäin Intel ISH:lla (katso kuvaa tarkemmin).

Vaikka Intel ISH -alijärjestelmän ominaisuuksia ei ole vielä tutkittu, se näyttää olevan mielenkiintoinen hyökkäysvektori Intel ME:tä vastaan.

Tulokset

1. Tutkimus tarjosi teknisen kuvauksen Intel Boot Guard -tekniikan toiminnasta. Miinus pari salaisuutta Intelin turvallisuudesta obscurity-mallin kautta.
2. Hyökkäysskenaario esitetään, joka mahdollistaa irrotettavan rootkitin luomisen järjestelmään.
3. Olemme nähneet, että nykyaikaiset Intel-prosessorit pystyvät suorittamaan paljon omaa koodia jo ennen BIOSin käynnistymistä.
4. Intel 64 -arkkitehtuurilla varustetut alustat ovat yhä vähemmän sopivia ilmaisten ohjelmistojen ajamiseen: laitteiston varmennus, kasvava määrä omaa teknologiaa ja alijärjestelmiä (SoC-piirisarjassa kolme ydintä: x86 ME, x86 ISH ja ARC PMC).

vähentämiskeinot

Valmistajien, jotka jättävät valmistustilan avoimeksi, tulee ehdottomasti sulkea se. Toistaiseksi he vain sulkevat silmänsä, ja uudet Kaby Lake -järjestelmät osoittavat tämän.

Käyttäjät voivat poistaa Intel BG:n käytöstä järjestelmissään (joihin kuvattu haavoittuvuus vaikuttaa) suorittamalla Flash-ohjelmointityökalun -closemnf-vaihtoehdon kanssa. Ensinnäkin sinun tulee varmistaa (käyttäen MEinfoa), että Intel BG:n kokoonpano ME-alueella mahdollistaa tämän tekniikan tarkan sammutuksen FPF:issä ohjelmoinnin jälkeen.

Lähde: will.com