Zaufane pobieranie Schrödingera. Intel Boot Guard

Proponujemy ponownie zejść na niski poziom i porozmawiać o bezpieczeństwie oprogramowania sprzętowego dla platform komputerowych zgodnych z x86. Tym razem głównym składnikiem badania jest Intel Boot Guard (nie mylić z Intel BIOS Guard!) – wspierana sprzętowo, zaufana technologia rozruchu BIOS-u, którą sprzedawca systemu komputerowego może na stałe włączyć lub wyłączyć na etapie produkcji. Cóż, przepis na badania jest nam już znany: pokrój cienko implementację tej technologii za pomocą inżynierii wstecznej, opisz jej architekturę, wypełniając ją nieudokumentowanymi szczegółami, dopraw wektorami ataku do smaku i wymieszaj. Dodajmy paliwa do historii o tym, jak błąd klonowany przez lata w produkcji kilku dostawców pozwala potencjalnemu atakującemu wykorzystać tę technologię do stworzenia ukrytego rootkita w systemie, którego nie można usunąć (nawet za pomocą programisty).

Nawiasem mówiąc, artykuł powstał w oparciu o raporty „Na straży rootkitów: Intel BootGuard” z konferencji ZeroNocy 2016 i 29. spotkanie DefCon Rosja (obie prezentacje tutaj).

Firmware dla platformy komputerowej z architekturą Intel 64

Najpierw odpowiedzmy sobie na pytanie: jakie jest oprogramowanie sprzętowe nowoczesnej platformy komputerowej z architekturą Intel 64? Oczywiście BIOS UEFI. Ale taka odpowiedź nie będzie dokładna. Przyjrzyjmy się obrazkowi, który przedstawia wersję desktopową (laptopową) tej architektury.

Podstawą jest link:

• Procesor (CPU, Central Processing Unit), który oprócz głównych rdzeni ma wbudowany rdzeń graficzny (nie we wszystkich modelach) i kontroler pamięci (IMC, Integrated Memory Controller);
• Chipset (PCH, Platform Controller Hub), zawierający różne kontrolery do interakcji z urządzeniami peryferyjnymi i zarządzania podsystemami. Wśród nich jest dobrze znany Intel Management Engine (ME), który ma również oprogramowanie układowe (oprogramowanie Intel ME).

Laptopy oprócz powyższych wymagają wbudowanego kontrolera (ACPI EC, Advanced Control oraz Power Interface Embedded Controller), który odpowiada za działanie podsystemu zasilania, touchpada, klawiatury, klawiszy Fn (jasność ekranu, głośność dźwięku , podświetlenie klawiatury itp.) i inne rzeczy. Ma także własne oprogramowanie sprzętowe.

Tak więc całość powyższego oprogramowania układowego to oprogramowanie sprzętowe platformy komputerowej (oprogramowanie systemowe), które jest przechowywane we wspólnej pamięci flash SPI. Aby użytkownicy tej pamięci nie byli zdezorientowani, gdzie ona się znajduje, zawartość tej pamięci została podzielona na następujące obszary (jak pokazano na rysunku):

• BIOS UEFI;
• Oprogramowanie sprzętowe ACPI EC (pojawił się osobny region z mikroarchitekturą procesora Skylake (2015), ale w praktyce nie widzieliśmy jeszcze przykładów jego użycia, więc oprogramowanie wbudowanego kontrolera jest nadal zawarte w UEFI BIOS) ;
• Oprogramowanie sprzętowe Intel ME;
• konfiguracja (adres MAC itp.) wbudowanej karty sieciowej GbE (Gigabit Ethernet);
• Deskryptory Flash to główny obszar pamięci flash, który zawiera wskaźniki do innych regionów, a także uprawnienia dostępu do nich.

Master magistrali SPI, czyli wbudowany w chipset kontroler SPI, poprzez który uzyskiwany jest dostęp do tej pamięci, odpowiada za rozgraniczenie dostępu do regionów (zgodnie z określonymi uprawnieniami). Jeśli uprawnienia są ustawione na wartości zalecane przez firmę Intel (ze względów bezpieczeństwa), każdy użytkownik SPI flash ma pełny dostęp (odczyt/zapis) tylko do swojego regionu. Reszta jest albo tylko do odczytu, albo niedostępna. Dobrze znany fakt: w wielu systemach procesor ma pełny dostęp do UEFI BIOS i GbE, dostęp tylko do odczytu deskryptorów flash i brak dostępu do regionu Intel ME. Dlaczego na wielu, a nie na wszystkich? To, co jest zalecane, nie jest wymagane. Więcej szczegółów powiemy Ci w dalszej części artykułu.

Mechanizmy ochrony oprogramowania platformy komputerowej przed modyfikacjami

Oczywiście oprogramowanie sprzętowe platformy komputerowej powinno być chronione przed możliwymi kompromisami, które umożliwiłyby potencjalnemu atakującemu zdobycie w nim przyczółka (przetrwanie aktualizacji/ponownych instalacji systemu operacyjnego), wykonanie kodu w najbardziej uprzywilejowanych trybach itp. A ograniczenie dostępu do obszarów pamięci flash SPI to oczywiście za mało. Dlatego, aby zabezpieczyć oprogramowanie przed modyfikacjami, stosowane są różne mechanizmy specyficzne dla każdego środowiska operacyjnego.

W ten sposób oprogramowanie sprzętowe Intel ME jest podpisane w celu kontroli integralności i autentyczności i jest sprawdzane przez kontroler ME za każdym razem, gdy jest ładowane do pamięci ME UMA. Ten proces weryfikacji był już przez nas omawiany w jednym z artykuły, dedykowany podsystemowi Intel ME.

Oprogramowanie sprzętowe ACPI EC z reguły sprawdzane jest tylko pod kątem integralności. Jednak ze względu na fakt, że ten plik binarny jest zawarty w UEFI BIOS, prawie zawsze podlega tym samym mechanizmom ochronnym, które wykorzystuje UEFI BIOS. Porozmawiajmy o nich.

Mechanizmy te można podzielić na dwie kategorie.

Ochrona przed zapisem w regionie UEFI BIOS

1. Fizyczne zabezpieczenie zawartości pamięci flash SPI za pomocą zworki zabezpieczającej przed zapisem;
2. Ochrona projekcji regionu UEFI BIOS w przestrzeni adresowej procesora za pomocą rejestrów chipsetu PRx;
3. Blokowanie prób zapisu do regionu UEFI BIOS poprzez generowanie i przetwarzanie odpowiedniego przerwania SMI poprzez ustawienie bitów BIOS_WE/BLE i SMM_BWP w rejestrach chipsetu;
4. Bardziej zaawansowaną wersją tego zabezpieczenia jest Intel BIOS Guard (PFAT).

Oprócz tych mechanizmów dostawcy mogą opracowywać i wdrażać własne środki bezpieczeństwa (na przykład podpisywanie kapsułek aktualizacjami UEFI BIOS).

Należy pamiętać, że w konkretnym systemie (w zależności od dostawcy) nie wszystkie z powyższych mechanizmów ochrony mogą zostać zastosowane, mogą w ogóle nie zostać zastosowane lub mogą zostać zaimplementowane w sposób podatny na ataki. Więcej o tych mechanizmach i sytuacji z ich wdrożeniem przeczytasz w ten artykuł. Dla zainteresowanych polecamy przeczytanie całej serii artykułów na temat bezpieczeństwa UEFI BIOS z CodeRush.

Uwierzytelnianie UEFI BIOS

Kiedy mówimy o technologiach zaufanego rozruchu, pierwszą rzeczą, która przychodzi na myśl, jest Bezpieczny rozruch. Jednak architektonicznie ma na celu weryfikację autentyczności komponentów zewnętrznych w stosunku do UEFI BIOS (sterowniki, programy ładujące itp.), a nie samego oprogramowania sprzętowego.

Dlatego Intel w SoC z mikroarchitekturą Bay Trail (2012) zaimplementował sprzętowo nie wyłączający się sprzęt Secure Boot (Verified Boot), który nie ma nic wspólnego z wyżej wspomnianą technologią Secure Boot. Później (2013) mechanizm ten został ulepszony i wydany pod nazwą Intel Boot Guard dla komputerów stacjonarnych z mikroarchitekturą Haswell.

Zanim opiszemy technologię Intel Boot Guard, przyjrzyjmy się środowiskom wykonawczym w architekturze Intel 64, które w połączeniu stanowią podstawę zaufania dla tej zaufanej technologii rozruchu.

CPU Intel

Cap sugeruje, że procesor jest głównym środowiskiem wykonawczym w architekturze Intel 64. Dlaczego jest on źródłem zaufania? Okazuje się, że czyni go takim posiadanie następujących elementów:

• Mikrokod ROM to nieulotna pamięć nie nadająca się do ponownego zapisu, służąca do przechowywania mikrokodu. Uważa się, że mikrokod to implementacja systemu poleceń procesora przy użyciu najprostszych instrukcji. Dzieje się tak również w mikrokodzie błędy. Tak więc w BIOS-ie można znaleźć pliki binarne z aktualizacjami mikrokodu (nakładane podczas uruchamiania, ponieważ ROM nie może zostać nadpisany). Zawartość tych plików binarnych jest szyfrowana, co znacznie komplikuje analizę (dlatego konkretna zawartość mikrokodu jest znana tylko tym, którzy go opracowują) i podpisana w celu kontroli integralności i autentyczności;
• Klucz AES do odszyfrowania zawartości aktualizacji mikrokodu;
• skrót klucza publicznego RSA używany do weryfikacji podpisu aktualizacji mikrokodu;
• Skrót klucza publicznego RSA, który weryfikuje sygnaturę opracowanych przez firmę Intel modułów kodowych ACM (Authenticated Code Module), które procesor może uruchomić przed wykonaniem BIOS-u (mikrokod hello) lub w trakcie jego działania, gdy wystąpią określone zdarzenia.

Intel ME

Nasz blog był poświęcony temu podsystemowi две Artykuł. Przypomnijmy, że to środowisko wykonywalne opiera się na mikrokontrolerze wbudowanym w chipset i jest najbardziej ukryte i uprzywilejowane w systemie.

Pomimo swojej tajemnicy, Intel ME budzi również zaufanie, ponieważ:

• ME ROM - pamięć nieulotna, niemożliwa do ponownego zapisu (nie jest dostępna metoda aktualizacji) zawierająca kod startowy oraz skrót SHA256 klucza publicznego RSA, który weryfikuje sygnaturę oprogramowania sprzętowego Intel ME;
• Klucz AES do przechowywania tajnych informacji;
• dostęp do zestawu bezpieczników (FPF, Field Programmable Fuse) zintegrowanych z chipsetem w celu trwałego przechowywania niektórych informacji, w tym tych określonych przez dostawcę systemu komputerowego.

Intel Boot Guard 1.x

Małe zastrzeżenie. Numery wersji technologii Intel Boot Guard, których używamy w tym artykule, są arbitralne i mogą nie mieć nic wspólnego z numeracją stosowaną w wewnętrznej dokumentacji firmy Intel. Ponadto podane tutaj informacje na temat wdrożenia tej technologii zostały uzyskane w trakcie inżynierii wstecznej i mogą zawierać nieścisłości w porównaniu ze specyfikacją Intel Boot Guard, która prawdopodobnie nigdy nie zostanie opublikowana.

Tak więc Intel Boot Guard (BG) to obsługiwana sprzętowo technologia weryfikacji uwierzytelniania UEFI BIOS. Sądząc po krótkim opisie w książce [Platform Embedded Security Technology Revealed, rozdział Boot with Integrity or Not Boot], działa on jako zaufany łańcuch rozruchowy. Pierwszym łączem jest kod rozruchowy (mikrokod) wewnątrz procesora, który jest wyzwalany przez zdarzenie RESET (nie mylić z wektorem RESET w BIOS-ie!). Procesor znajduje moduł kodu opracowany i podpisany przez firmę Intel (startup ACM Intel BG) w pamięci flash SPI, ładuje go do swojej pamięci podręcznej, weryfikuje (już zauważono powyżej, że procesor ma hash klucza publicznego, który weryfikuje ACM podpis) i zaczyna się.

Ten moduł kodu jest odpowiedzialny za weryfikację małej początkowej części UEFI BIOS - początkowego bloku rozruchowego (IBB), który z kolei zawiera funkcjonalność weryfikacji głównej części UEFI BIOS. Tym samym Intel BG umożliwia weryfikację autentyczności BIOS-u przed załadowaniem systemu operacyjnego (co można wykonać pod nadzorem technologii Secure Boot).

Technologia Intel BG zapewnia dwa tryby pracy (przy czym jeden nie koliduje z drugim, czyli oba tryby można włączyć w systemie lub oba można wyłączyć).

Zmierzony but

W trybie Measured Boot (MB) każdy komponent rozruchowy (począwszy od rozruchowej pamięci ROM procesora) „mierzy” następny, korzystając z możliwości modułu TPM (Trusted Platform Module). Dla tych, którzy nie są obeznani, spieszę z wyjaśnieniem.

TPM posiada PCR (Platform Configuration Registers), do których zapisywany jest wynik operacji hashowania według wzoru:

Te. bieżąca wartość PCR zależy od poprzedniej, a rejestry te są resetowane tylko wtedy, gdy system jest RESETOWANY.

Zatem w trybie MB w pewnym momencie reakcje PCR odzwierciedlają unikalny (w ramach możliwości operacji mieszania) identyfikator kodu lub danych, które zostały „zmierzone”. Wartości PCR można wykorzystać w niektórych operacjach szyfrowania danych (TPM_Seal). Następnie ich odszyfrowanie (TPM_Unseal) będzie możliwe tylko wtedy, gdy wartości PCR nie uległy zmianie w wyniku ładowania (tj. nie zmodyfikowano ani jednego „mierzonego” składnika).

Zweryfikowany rozruch

Najgorszą rzeczą dla tych, którzy lubią modyfikować UEFI BIOS, jest tryb Verified Boot (VB), w którym każdy komponent startowy kryptograficznie weryfikuje integralność i autentyczność kolejnego. A w przypadku błędu weryfikacji (jeden z) ma miejsce:

• zamknięcie przez limit czasu od 1 minuty do 30 minut (aby użytkownik miał czas zrozumieć, dlaczego jego komputer nie uruchamia się i, jeśli to możliwe, próbuje przywrócić BIOS);
• natychmiastowe wyłączenie (aby użytkownik nie miał czasu na zrozumienie, a tym bardziej na zrobienie czegokolwiek);
• kontynuowanie pracy ze spokojem na twarzy (ten przypadek, gdy nie ma czasu na bezpieczeństwo, bo są ważniejsze rzeczy do zrobienia).

Wybór działania zależy od określonej konfiguracji Intel BG (czyli od tzw. polityki egzekwowania prawa), która jest trwale zapisywana przez dostawcę platformy komputerowej w specjalnie zaprojektowanej pamięci masowej – bezpiecznikach chipsetu (FPF). Zastanowimy się nad tym punktem bardziej szczegółowo później.

Oprócz konfiguracji sprzedawca generuje dwa klucze RSA 2048 i tworzy dwie struktury danych (pokazane na rysunku):

1. Manifest klucza głównego dostawcy (KEYM, OEM Root Key Manifest), który zawiera SVN (numer wersji zabezpieczeń) tego manifestu, skrót SHA256 klucza publicznego następnego manifestu, klucz publiczny RSA (tj. publiczną część klucz główny dostawcy) w celu sprawdzenia podpisu tego manifestu i samego podpisu;
2. Manifest IBB (IBBM, Manifest początkowego bloku rozruchowego), który zawiera SVN tego manifestu, skrót SHA256 IBB, klucz publiczny do weryfikacji podpisu tego manifestu i sam podpis.

Hash SHA256 klucza publicznego klucza głównego OEM jest trwale zapisany w bezpiecznikach chipsetu (FPF), podobnie jak konfiguracja Intel BG. Jeśli konfiguracja Intel BG przewiduje włączenie tej technologii, to odtąd tylko właściciel prywatnej części klucza głównego OEM będzie mógł zaktualizować BIOS w tym systemie (czyli móc przeliczyć te manifesty), tj. sprzedawca.

Patrząc na zdjęcie, od razu pojawiają się wątpliwości, czy potrzebny jest tak długi łańcuch weryfikacji – można było posłużyć się jednym manifestem. Po co komplikować rzeczy?

W rzeczywistości Intel zapewnia dostawcy możliwość używania różnych kluczy IBB dla różnych linii swoich produktów i jednego jako klucza głównego. W przypadku wycieku prywatnej części klucza IBB (za pomocą którego podpisany jest drugi manifest) incydent będzie dotyczył tylko jednej linii produktów i tylko do czasu, gdy sprzedawca wygeneruje nową parę i uwzględni ponownie obliczone manifesty w następnej aktualizacji BIOS-u.

Jeśli jednak klucz główny (za pomocą którego podpisany jest pierwszy manifest) zostanie naruszony, jego zastąpienie nie będzie możliwe; nie jest przewidziana procedura unieważnienia. skrót publicznej części tego klucza jest raz na zawsze zaprogramowany w FPF.

Konfiguracja Intel Boot Guard

Przyjrzyjmy się teraz bliżej konfiguracji Intel BG i procesowi jej tworzenia. Jeśli spojrzysz na odpowiednią kartę w interfejsie GUI narzędzia Flash Image Tool z zestawu Intel System Tool Kit (STK), zauważysz, że konfiguracja Intel BG zawiera skrót publicznej części klucza głównego dostawcy, kilka niejasne wartości itp. Profil Intel BG.

Struktura tego profilu:

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

Ogólnie rzecz biorąc, konfiguracja Intel BG jest jednostką bardzo elastyczną. Rozważmy na przykład flagę Force_Boot_Guard_ACM. Po jego usunięciu, jeśli moduł ACM uruchamiania BG w pamięci flash SPI nie zostanie znaleziony, nie nastąpi zaufany rozruch. Nie będzie jej ufać.

Pisaliśmy już powyżej, że politykę egzekwowania dla trybu VB można skonfigurować tak, aby w przypadku błędu weryfikacji nastąpiło niezaufane pobieranie.

Zostawmy takie rzeczy w gestii sprzedawców...

Narzędzie GUI udostępnia następujące „gotowe” profile:

liczba
Tryb
Opis

0
Nie_FVME
Technologia Intel BG wyłączona

1
VE
Tryb VB jest włączony, wyłączenie po przekroczeniu limitu czasu

2
VME
oba tryby są włączone (VB i MB), wyłączenie po przekroczeniu limitu czasu

3
VM
oba tryby są włączone, bez wyłączania systemu

4
FVE
Włączony tryb VB, natychmiastowe wyłączenie

5
FVME
oba tryby włączone, natychmiastowe wyłączenie

Jak już wspomniano, konfiguracja Intel BG musi zostać raz na zawsze wpisana przez dostawcę systemu do bezpieczników chipsetu (FPF) - małego (według niezweryfikowanych informacji, tylko 256 bajtów) sprzętowego magazynu informacji wewnątrz chipsetu, który można zaprogramować poza zakładami produkcyjnymi Intela (dlatego właśnie Programowalny w terenie Bezpieczniki).

Świetnie nadaje się do przechowywania konfiguracji, ponieważ:

• posiada jednorazowo programowalny obszar do przechowywania danych (dokładnie tam, gdzie zapisana jest konfiguracja Intel BG);
• Tylko Intel ME może go czytać i programować.

Zatem, aby ustawić konfigurację technologii Intel BG w konkretnym systemie, sprzedawca wykonuje podczas produkcji następujące czynności:

1. Za pomocą narzędzia Flash Image Tool (od Intel STK) tworzy obraz oprogramowania sprzętowego z zadaną konfiguracją Intel BG w postaci zmiennych w obrębie regionu Intel ME (tzw. tymczasowe lustro dla FPF);
2. Korzystając z narzędzia Flash Programming Tool (od Intel STK), zapisuje ten obraz do pamięci flash SPI systemu i zamyka tzw. tryb produkcyjny (w tym przypadku odpowiednie polecenie jest wysyłane do Intel ME).

W wyniku tych operacji Intel ME przekaże określone wartości z kopii lustrzanej dla FPF w regionie ME do FPF, ustawi rozdzielczości w deskryptorach flash SPI na wartości zalecane przez firmę Intel (opisane na początku artykuł) i wykonaj RESET systemu.

Analiza wdrożenia Intel Boot Guard

Aby przeanalizować wdrożenie tej technologii na konkretnym przykładzie, sprawdziliśmy następujące systemy pod kątem śladów technologii Intel BG:

System
Operacja

Gigabyte GA-H170-D3H
Skylake, jest wsparcie

Gigabyte GA-Q170-D3H
Skylake, jest wsparcie

Gigabyte GA-B150-HD3
Skylake, jest wsparcie

MSI H170A Gaming Pro
Skylake, brak wsparcia

Lenovo ThinkPad 460
Skylake, obsługiwany, z włączoną technologią

Lenovo Yoga 2 Pro
Haswell, żadnego wsparcia

Lenovo U330p
Haswell, żadnego wsparcia

Przez „wsparcie” rozumiemy obecność startowego modułu ACM Intel BG, wspomnianych wyżej manifestów oraz odpowiadający im kod w BIOS-ie, tj. wdrożenie do analizy.

Jako przykład weźmy ten pobrany z biura. obraz strony internetowej dostawcy pamięci flash SPI dla Gigabyte GA-H170-D3H (wersja F4).

Boot ROM procesora Intel

Przede wszystkim porozmawiajmy o działaniach procesora, jeśli włączona jest technologia Intel BG.

Nie udało się znaleźć próbek odszyfrowanego mikrokodu, zatem kwestią otwartą pozostaje sposób realizacji opisanych poniżej działań (w mikrokodzie lub sprzęcie). Faktem jest jednak, że nowoczesne procesory Intela „mogą” wykonywać te czynności.

Po wyjściu ze stanu RESET procesor (zawartość pamięci flash została już zmapowana do przestrzeni adresowej) odnajduje tablicę FIT (Firmware Interface Table). Łatwo go znaleźć, wskaźnik do niego zapisany jest pod adresem FFFF FFC0h.

W rozpatrywanym przykładzie pod tym adresem znajduje się wartość FFD6 9500h. Uzyskując dostęp do tego adresu, procesor widzi tablicę FIT, której zawartość jest podzielona na rekordy. Pierwszy wpis jest nagłówkiem następującej struktury:

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

Z nieznanego powodu suma kontrolna nie zawsze jest obliczana w tych tabelach (pole pozostaje zerowe).

Pozostałe wpisy wskazują różne pliki binarne, które należy przeanalizować/wykonać przed wykonaniem BIOS-u, tj. przed przełączeniem na starszy wektor RESET (FFFF FFF0h). Struktura każdego takiego wpisu jest następująca:

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

Pole EntryType informuje o typie bloku, na który wskazuje to wejście. Znamy kilka typów:

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

Teraz jest oczywiste, że jeden z wpisów wskazuje lokalizację pliku binarnego ACM startowego Intel BG. Struktura nagłówka tego pliku binarnego jest typowa dla modułów kodu opracowanych przez firmę Intel (ACM, aktualizacje mikrokodu, sekcje kodu 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];
};

Procesor ładuje ten plik binarny do swojej pamięci podręcznej, sprawdza go i uruchamia.

Intel BG startup ACM

W wyniku analizy pracy tego ACM stało się jasne, że wykonuje on następujące czynności:

• otrzymuje konfigurację Intel BG z Intel ME, zapisaną w bezpiecznikach chipsetu (FPF);
• znajduje manifesty KEYM i IBBM i je weryfikuje.

Aby znaleźć te manifesty, ACM używa również tabeli FIT, która ma dwa typy wpisów wskazujących dane struktury (patrz FIT_ENTRY_TYPES powyżej).

Przyjrzyjmy się bliżej manifestom. W strukturze pierwszego manifestu widzimy kilka niejasnych stałych, skrót klucza publicznego z drugiego manifestu oraz publiczny klucz główny OEM podpisany jako struktura zagnieżdżona:

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

Aby zweryfikować klucz publiczny OEM Root Key, przypominamy, że używamy skrótu bezpieczników SHA256, który w tym momencie został już otrzymany od Intel ME.

Przejdźmy do drugiego manifestu. Składa się z trzech struktur:

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

Pierwsza zawiera pewne stałe:

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

Drugi zawiera hash SHA256 IBB i liczbę deskryptorów opisujących zawartość IBB (tzn. z czego obliczany jest hash):

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

Deskryptory IBB mają tę strukturę, jeden po drugim. Ich zawartość ma następujący format:

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

To proste: każdy deskryptor zawiera adres/rozmiar fragmentu IBB. Zatem konkatenacja bloków wskazanych przez te deskryptory (w kolejności samych deskryptorów) to IBB. I z reguły IBB to zbiór wszystkich modułów faz SEC i PEI.

Drugi manifest uzupełnia struktura zawierająca klucz publiczny IBB (weryfikowany hashem SHA256 z pierwszego manifestu) oraz podpis tego manifestu:

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

Zatem jeszcze przed rozpoczęciem wykonywania UEFI BIOS procesor uruchomi ACM, który zweryfikuje autentyczność zawartości sekcji z kodem fazy SEC i PEI. Następnie procesor wychodzi z ACM, podąża za wektorem RESET i rozpoczyna wykonywanie BIOS-u.

Zweryfikowana partycja PEI musi zawierać moduł, który sprawdzi resztę BIOS-u (kod DXE). Moduł ten jest już rozwijany przez IBV (niezależnego dostawcę BIOS-u) lub przez samego dostawcę systemu. Ponieważ Do naszej dyspozycji były jedynie systemy Lenovo i Gigabyte, które miały wsparcie Intel BG; przyjrzyjmy się kodowi wydobytemu z tych systemów.

Moduł UEFI BIOS LenovoVerifiedBootPei

W przypadku Lenovo okazał się to moduł LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, opracowany przez firmę Lenovo.

Jego zadaniem jest sprawdzenie (według identyfikatora GUID) tablicy skrótów dla DXE i weryfikacja 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;
};

Moduł UEFI BIOS BootGuardPei

W przypadku Gigabyte okazało się, że jest to moduł BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, opracowany przez AMI, dlatego jest obecny w każdym BIOSie AMI z obsługą Intel BG.

Jego algorytm działania jest nieco inny, jednak sprowadza się do tego samego:

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

Szukana tabela mieszająca {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} ma następujący format:

typedef HASH_TABLE DXE_DESCRIPTORS[];

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long BaseAddress;
	unsigned long Size;
};

Intel Boot Guard 2.x

Porozmawiajmy pokrótce o kolejnej implementacji Intel Boot Guard, która znalazła się w nowszym systemie opartym na Intel SoC z mikroarchitekturą Apollo Lake – ASRock J4205-IT.

Choć ta wersja będzie używana tylko w SoC (nowe systemy z mikroarchitekturą procesora Kaby Lake w dalszym ciągu korzystają z Intel Boot Guard 1.x), dużym zainteresowaniem cieszy się przestudiowanie nowej opcji architektury dla platform Intel SoC, w których zaszły istotne zmiany, na przykład:

• regiony BIOS i Intel ME (a raczej Intel TXE, zgodnie z terminologią dotyczącą Intel SoC) są teraz jednym regionem IFWI;
• chociaż na platformie włączono technologię Intel BG, w pamięci flash nie znaleziono struktur takich jak FIT, KEYM, IBBM;
• oprócz rdzeni TXE i ISH (x86) do chipsetu dodano trzeci rdzeń (nawiasem mówiąc, znowu ARC) - PMC (kontroler zarządzania energią), związany z zapewnieniem funkcjonalności podsystemu zasilania i monitorowaniem wydajności.

Zawartość nowego regionu IFWI stanowi zestaw następujących modułów:

Offset
nazwa
Opis

0000 2000H
SMIP
określoną konfigurację platformy, podpisaną przez dostawcę

0000 6000H
RBEP
Sekcja kodu oprogramowania układowego Intel TXE, x86, podpisana przez firmę Intel

0001 0000H
PMCP
Sekcja kodu oprogramowania sprzętowego Intel PMC, ARC, podpisana przez firmę Intel

0002 0000H
FTPR
Sekcja kodu oprogramowania układowego Intel TXE, x86, podpisana przez firmę Intel

0007 B000h
UCOD
aktualizacje mikrokodu dla procesora, podpisane przez firmę Intel

0008 0000H
IBBP
UEFI BIOS, fazy SEC/PEI, x86, podpisane przez dostawcę

0021 8000H
ISHC
Sekcja kodu oprogramowania układowego Intel ISH, x86, podpisana przez dostawcę

0025 8000H
FTP
Sekcja kodu oprogramowania układowego Intel TXE, x86, podpisana przez firmę Intel

0036 1000H
IUNP
nieznany

0038 1000H
OBBP
UEFI BIOS, faza DXE, x86, bez znaku

Podczas analizy oprogramowania sprzętowego TXE stało się oczywiste, że po RESETIE TXE utrzymuje procesor w tym stanie, dopóki nie przygotuje podstawowej zawartości przestrzeni adresowej dla procesora (FIT, ACM, wektor RESET...). Co więcej, TXE umieszcza te dane w swojej SRAM, po czym tymczasowo udostępnia tam procesorowi dostęp i „zwalnia” go z RESETU.

Na straży przed rootkitami

Cóż, przejdźmy teraz do „gorących” rzeczy. Kiedyś odkryliśmy, że w wielu systemach deskryptory flash SPI zawierają uprawnienia dostępu do obszarów pamięci flash SPI, dzięki czemu wszyscy użytkownicy tej pamięci mogą zapisywać i czytać dowolne obszary. Te. nie ma mowy.

Po sprawdzeniu za pomocą narzędzia MEinfo (z Intel STK) stwierdziliśmy, że tryb produkcyjny w tych systemach nie jest zamknięty, dlatego bezpieczniki chipsetu (FPF) pozostają w niezdefiniowanym stanie. Tak, w takich przypadkach Intel BG nie jest ani włączany, ani wyłączany.

Mówimy o następujących systemach (w odniesieniu do Intel BG i co zostanie opisane w dalszej części artykułu, będziemy mówić o systemach z mikroarchitekturą procesorów Haswell i wyższych):

• wszystkie produkty Gigabyte;
• wszystkie produkty MSI;
• 21 modeli laptopów Lenovo i 4 modele serwerów Lenovo.

Oczywiście zgłosiliśmy to odkrycie tym dostawcom, a także firmie Intel.

Dopiero przyszła adekwatna reakcja Lenovokto rozpoznał problem i wydał łatkę.

Gigabyte Wydawało się, że zaakceptowali informację o luce, jednak nie skomentowali tego w żaden sposób.

Komunikacja z MSI całkowicie utknęły w martwym punkcie na naszą prośbę o przesłanie publicznego klucza PGP (aby wysłać im informację dotyczącą bezpieczeństwa w zaszyfrowanej formie). Oświadczyli, że „są producentem sprzętu i nie produkują kluczy PGP”.

Ale przejdźmy do rzeczy. Ponieważ bezpieczniki pozostają w nieokreślonym stanie, użytkownik (lub atakujący) może je samodzielnie zaprogramować (najtrudniej jest znajdź Intel STK). Aby to zrobić, musisz wykonać następujące kroki.

1. Uruchom system operacyjny Windows (ogólnie czynności opisane poniżej można również wykonać w systemie Linux, jeśli opracujesz analog Intel STK dla żądanego systemu operacyjnego). Korzystając z narzędzia MEinfo, upewnij się, że w systemie nie są zaprogramowane bezpieczniki.

2. Odczytaj zawartość pamięci flash za pomocą narzędzia Flash Programming Tool.

3. Otwórz odczytany obraz za pomocą dowolnego narzędzia do edycji UEFI BIOS, dokonaj niezbędnych zmian (na przykład wprowadź rootkita), utwórz/edytuj istniejące struktury KEYM i IBBM w regionie ME.

Zdjęcie przedstawia publiczną część klucza RSA, którego skrót zostanie zaprogramowany w bezpiecznikach chipsetu wraz z resztą konfiguracji Intel BG.

4. Za pomocą narzędzia Flash Image Tool utwórz nowy obraz oprogramowania sprzętowego (poprzez ustawienie konfiguracji Intel BG).

5. Zapisz nowy obraz w pamięci flash za pomocą narzędzia Flash Programming Tool i sprawdź za pomocą MEinfo, czy region ME zawiera teraz konfigurację Intel BG.

6. Użyj narzędzia Flash Programming Tool, aby zamknąć tryb produkcyjny.

7. System uruchomi się ponownie, po czym będziesz mógł użyć MEinfo do sprawdzenia, czy FPF są teraz zaprogramowane.

Te działania na zawsze włącz Intel BG w tym systemie. Czynności nie można cofnąć, co oznacza:

• Tylko właściciel prywatnej części klucza root (tj. ten, który włączył technologię Intel BG) będzie mógł zaktualizować UEFI BIOS w tym systemie;
• jeśli zwrócisz do tego systemu oryginalne oprogramowanie, np. za pomocą programatora, to nawet się nie włączy (konsekwencja polityki egzekwowania w przypadku błędu weryfikacji);
• aby pozbyć się takiego UEFI BIOS-u, należy wymienić chipset z zaprogramowanymi FPF na „czysty” (czyli przelutować chipset, jeśli masz dostęp do stacji lutowniczej na podczerwień za cenę samochodu, lub po prostu wymienić płytę główną) ).

Aby zrozumieć, co potrafi taki rootkit, należy ocenić, co umożliwia wykonanie kodu w środowisku UEFI BIOS. Powiedzmy w najbardziej uprzywilejowanym trybie procesora - SMM. Taki rootkit może mieć następujące właściwości:

• wykonywane równolegle z systemem operacyjnym (można skonfigurować przetwarzanie tak, aby generowało przerwanie SMI, które zostanie wyzwolone przez timer);
• mieć wszystkie zalety bycia w trybie SMM (pełny dostęp do zawartości pamięci RAM i zasobów sprzętowych, tajemnica przed systemem operacyjnym);
• Kod programu rootkita można zaszyfrować i odszyfrować po uruchomieniu w trybie SMM. Jako klucz szyfrujący można wykorzystać dowolne dane dostępne wyłącznie w trybie SMM. Na przykład skrót z zestawu adresów w SMRAM. Aby zdobyć ten klucz, musisz dostać się do SMM. Można to zrobić na dwa sposoby. Znajdź RCE w kodzie SMM i wykorzystaj go lub dodaj własny moduł SMM do BIOS-u, co jest niemożliwe, ponieważ włączyliśmy Boot Guard.

Zatem luka ta umożliwia osobie atakującej:

• utworzyć w systemie ukryty, nieusuwalny rootkit o nieznanym przeznaczeniu;
• wykonaj swój kod na jednym z rdzeni chipsetu wewnątrz Intel SoC, a mianowicie na Intel ISH (przyjrzyj się uważnie zdjęciu).

Chociaż możliwości podsystemu Intel ISH nie zostały jeszcze zbadane, wydaje się, że jest to interesujący wektor ataku dla Intel ME.

odkrycia

1. Badania pozwoliły uzyskać opis techniczny działania technologii Intel Boot Guard. Minus kilka sekretów bezpieczeństwa Intela poprzez model niejasności.
2. Przedstawiony jest scenariusz ataku, który pozwala na utworzenie w systemie rootkita, którego nie można odinstalować.
3. Widzieliśmy, że nowoczesne procesory Intel są w stanie wykonać wiele zastrzeżonego kodu jeszcze przed uruchomieniem BIOS-u.
4. Platformy z architekturą Intel 64 coraz mniej nadają się do uruchamiania wolnego oprogramowania: weryfikacja sprzętowa, coraz większa liczba autorskich technologii i podsystemów (trzy rdzenie w chipsecie SoC: x86 ME, x86 ISH i ARC PMC).

Łagodzenia

Dostawcy, którzy celowo pozostawiają otwarty tryb produkcyjny, powinni go zamknąć. Na razie tylko oczy mają zamknięte i nowe systemy Kaby Lake to pokazują.

Użytkownicy mogą wyłączyć technologię Intel BG w swoich systemach (które są podatne na opisaną lukę), uruchamiając narzędzie Flash Programming Tool z parametrem -closemnf. Na początek należy upewnić się (używając MEinfo), że konfiguracja Intel BG w regionie ME przewiduje wyłączenie tej technologii po zaprogramowaniu w FPF.

Źródło: www.habr.com