Chargement de Schrödinger approuvé. Intel Boot Guard

Nous vous proposons de redescendre à un niveau fondamental et de parler de la sécurité des firmwares sur les plateformes informatiques compatibles x86. Cette fois-ci, l'ingrédient principal de notre étude est Intel Boot Guard (à ne pas confondre avec Intel BIOS Guard !) – une technologie de démarrage sécurisé prise en charge par le matériel, que le fabricant du système informatique peut activer ou désactiver de manière permanente lors de la production. Quant à notre recette d'analyse, elle est déjà familière : découper avec précision l'implémentation de cette technologie par le biais de l'ingénierie inverse, décrire sa structure, l'enrichir de détails non documentés, assaisonner avec des vecteurs d'attaques, et mélanger le tout. Ajoutons un peu de piquant avec une discussion sur la manière dont une faille de fabrication clonée pendant des années chez plusieurs fabricants permet à un attaquant potentiel d'utiliser cette technologie pour créer un rootkit caché dans le système, indétectable même par un programmateur.

Au fait, cet article s’inspire des présentations intitulées « À la défense des rootkits : Intel BootGuard » faites lors de la conférence ZeroNights 2016 et de la 29e réunion DefCon Russia (les deux présentations ici).

Firmware de la plateforme informatique avec architecture Intel 64

Pour commencer, répondons à la question : qu'est-ce qui constitue le firmware d'une plateforme informatique moderne avec architecture Intel 64 ? Bien sûr, c'est le BIOS UEFI. Mais cette réponse ne serait pas tout à fait exacte. Regardons plutôt le schéma qui montre la version de bureau (ou portable) de cette architecture.

La base est un ensemble :

• Un processeur (CPU, Unité Centrale de Traitement) qui, en plus des cœurs principaux, intègre un cœur graphique (pas dans tous les modèles), et comprend un contrôleur de mémoire (IMC, Contrôleur de Mémoire Intégré) ;
• Un chipset (PCH, Contrôleur de Plateforme) qui contient divers contrôleurs pour interagir avec les périphériques et gérer les sous-systèmes. Parmi eux se trouve le fameux Intel Management Engine (ME), qui a également son propre firmware (firmware Intel ME).

Les ordinateurs portables, en plus de tout ce qui précède, supposent la présence d'un contrôleur intégré (ACPI EC, Contrôleur Embeddé de l'Interface Avancée de Contrôle et d'Alimentation), qui est responsable du bon fonctionnement des systèmes d'alimentation, du pavé tactile, du clavier, des touches Fn (luminosité de l'écran, volume, rétroéclairage du clavier, etc.) et bien d'autres. Et lui aussi a son propre firmware.

Ainsi, l'ensemble des firmwares mentionnés ci-dessus constitue le firmware de la plate-forme informatique (system firmware), qui est stocké dans une mémoire flash SPI partagée. Pour éviter que les utilisateurs de cette mémoire ne se mélangent les pinceaux, le contenu de cette mémoire est divisé en plusieurs régions (comme indiqué sur l'image) :

• UEFI BIOS ;
• firmware ACPI EC (une région distincte a été introduite avec l'architecture de microprocesseur Skylake en 2015, mais jusqu'à présent, nous n'avons pas vu d'exemples d'utilisation dans la nature, donc le firmware du contrôleur intégré fait toujours partie de l'UEFI BIOS) ;
• firmware Intel ME ;
• configuration (adresse MAC, etc.) de l'adaptateur réseau intégré GbE (Gigabit Ethernet) ;
• descripteurs Flash (Flash Descriptors) – la région principale de la mémoire flash, qui contient des pointeurs vers les autres régions ainsi que des autorisations d'accès à celles-ci.

La gestion de l'accès aux régions (selon les autorisations définies) est assurée par le contrôleur maître du bus SPI – un contrôleur SPI intégré dans le chipset, par lequel l'accès à cette mémoire est effectué. Si les autorisations sont définies aux valeurs recommandées (pour des raisons de sécurité) par Intel, alors chaque utilisateur de la mémoire flash SPI a un accès complet (lecture/écriture) uniquement à sa région. Les autres sont soit en lecture seule, soit inaccessibles. Il est bien connu que sur de nombreux systèmes, le CPU a un accès complet à l'UEFI BIOS et à GbE, un accès en lecture seulement aux descripteurs flash, et il n'y a pas d'accès à la région Intel ME. Pourquoi sur de nombreux systèmes et pas sur tous ? Ce qui est recommandé n'est pas forcément obligatoire. Nous expliquerons cela en détail dans l'article suivant.

Mécanismes de protection du firmware de la plate-forme informatique contre les modifications

Il est évident que le firmware de la plate-forme informatique doit être protégé contre toute compromission, qui permettrait à un potentiel attaquant de s'y ancrer (de survivre aux mises à jour/réinstallations du système d'exploitation), d'exécuter son code dans les modes les plus privilégiés, etc. Et les limites d'accès aux régions de la mémoire flash SPI ne suffisent évidemment pas. Par conséquent, divers mécanismes spécifiques à chaque environnement d'exécution sont utilisés pour protéger le firmware contre les modifications.

Ainsi, le firmware Intel ME est signé pour contrôler l'intégrité et l'authenticité, et est vérifié par le contrôleur ME à chaque chargement en mémoire ME UMA. Ce processus de vérification a déjà été abordé dans l'un de nos articles. articles, dédiée au sous-système Intel ME.

La mise à jour du firmware ACPI EC est généralement contrôlée uniquement pour l'intégrité. Cependant, étant donné que ce binaire est inclus dans le BIOS UEFI, il est presque toujours soumis aux mêmes mécanismes de protection que ceux utilisés par le BIOS UEFI. Discutons-en.

Ces mécanismes peuvent être classés en deux catégories.

Protection en écriture de la région UEFI BIOS

1. Protection physique du contenu de la mémoire flash SPI par un cavalier write-protect;
2. Protection de la projection de la région UEFI BIOS dans l'espace d'adressage du CPU à l'aide des registres PRx du chipset;
3. Blocage des tentatives d'écriture dans la région UEFI BIOS par la génération et le traitement d'une interruption SMI correspondante en activant les bits BIOS_WE/BLE et SMM_BWP dans les registres du chipset;
4. Une variante plus avancée de cette protection est Intel BIOS Guard (PFAT).

En plus de ces mécanismes, les fabricants peuvent développer et appliquer leurs propres mesures de sécurité (par exemple, la signature des capsules de mises à jour UEFI BIOS).

Il est important de noter que certains de ces mécanismes de protection peuvent ne pas être appliqués sur un système particulier (cela dépend du fabricant), peuvent ne pas être appliqués du tout ou peuvent être implémentés de manière vulnérable. Pour plus de détails sur ces mécanismes et la situation de leur mise en œuvre, vous pouvez lire en cet article. Nous recommandons aux intéressés de consulter l'ensemble du cycle d'articles sur la sécurité du BIOS UEFI de CodeRush.

Vérification de l'authenticité du BIOS UEFI

Lorsque nous parlons de technologies de démarrage sécurisé, la première chose qui vient à l'esprit est Secure Boot. Cependant, il est architecturément destiné à vérifier l'authenticité des composants externes par rapport au BIOS UEFI (drivers, chargeurs, etc.), et non du firmware lui-même.

C'est pourquoi Intel a mis en œuvre un Secure Boot matériel non désactivable (Verified Boot) dans ses SoC avec l'architecture Bay Trail (2012), qui n'a rien à voir avec la technologie Secure Boot mentionnée ci-dessus. Plus tard (en 2013), ce mécanisme a été amélioré et lancé sous le nom d'Intel Boot Guard pour les ordinateurs de bureau avec l'architecture Haswell.

Avant de décrire Intel Boot Guard, examinons les environnements d'exécution de l'architecture Intel 64, qui sont par la même occasion les racines de confiance pour cette technologie de démarrage sécurisé.

Intel CPU

Kép suggère que le processeur est le principal environnement d'exécution de l'architecture Intel 64. Pourquoi est-il aussi la racine de confiance ? En fait, c'est parce qu'il possède les éléments suivants :

• Le microcode ROM est une mémoire non volatile et non réinscriptible destinée à stocker le microcode. On considère que le microcode est l'implémentation du système d'instructions du processeur sous forme d'instructions élémentaires. Des bogues peuvent également survenir dans le microcode. . Ainsi, dans le BIOS, on peut trouver des binaires avec des mises à jour de microcode (qui s'appliquent au démarrage, car la ROM ne peut pas être réécrite). Le contenu de ces binaires est chiffré, ce qui complique considérablement l'analyse (c'est pourquoi le contenu spécifique du microcode n'est connu que des développeurs), et il est signé pour garantir l'intégrité et l'authenticité ;la clé AES pour déchiffrer le contenu des mises à jour de microcode ;
• le hash de la clé publique RSA, qui vérifie la signature des mises à jour de microcode ;
• le hash de la clé publique RSA, qui vérifie la signature des modules de code authentifiés ACM (Authenticated Code Module) développés par Intel, que le CPU peut exécuter avant le démarrage du BIOS (salutations au microcode) ou pendant son fonctionnement, en réponse à certains événements.
• Intel ME

Nous avons consacré un article entier à ce sous-système dans notre blog.

Rappelons que cet environnement exécutable est basé sur un microcontrôleur intégré dans le chipset et est le plus caché et privilégié dans le système. deux articleMalgré cette discrétion, Intel ME est également la racine de confiance, car elle possède :

la ROM ME — une mémoire non volatile et non réinscriptible (aucun moyen de mise à jour n'est prévu), contenant le code de démarrage, ainsi qu'un hash SHA256 de la clé publique RSA, qui vérifie la signature du firmware Intel ME ;

• une clé AES pour stocker des informations secrètes ;
• un accès à un ensemble de fusibles programmables sur le terrain (FPFs, Field Programmable Fuses) intégré dans le chipset pour le stockage permanent de certaines informations, y compris celles fournies par le fournisseur du système informatique.
• Intel Boot Guard 1.x

Un petit avertissement. Les numéros de version de la technologie Intel Boot Guard, que nous utilisons dans cet article, sont conditionnels et peuvent n'avoir aucun rapport avec la numérotation utilisée dans la documentation interne d'Intel. De plus, les informations fournies ici sur l'implémentation de cette technologie ont été obtenues par reverse engineering et peuvent contenir des inexactitudes par rapport à la spécification d'Intel Boot Guard, qui ne sera probablement jamais publiée.

Un petit avertissement. Les numéros de version de la technologie Intel Boot Guard mentionnés dans cet article sont provisoires et peuvent ne pas correspondre à ceux utilisés dans la documentation interne d'Intel. De plus, les informations fournies ici sur l'implémentation de cette technologie ont été obtenues par rétro-ingénierie et peuvent contenir des inexactitudes par rapport à la spécification d'Intel Boot Guard, qui ne sera probablement jamais publiée.

Ainsi, Intel Boot Guard (BG) est une technologie de vérification d'authenticité du BIOS UEFI, prise en charge matériellement. D'après sa brève description dans le livre [Platform Embedded Security Technology Revealed, chapitre Boot with Integrity, or Not Boot], elle fonctionne comme une chaîne de confiance pour le démarrage. Le premier maillon de cette chaîne est le code de démarrage (microcode) à l'intérieur du CPU, qui se lance lors d'un événement RESET (à ne pas confondre avec le vecteur RESET dans le BIOS !). Le CPU trouve dans la mémoire flash SPI un module de code (Intel BG startup ACM) conçu et signé par Intel, le charge dans son cache, vérifie (il a été noté que le CPU possède le hachage de la clé publique utilisée pour vérifier la signature de l'ACM) et l'exécute.

Ce module de code est responsable de la vérification d'une petite partie de démarrage du BIOS UEFI — le Initial Boot Block (IBB), qui contient à son tour la fonctionnalité nécessaire à la vérification de la partie principale du BIOS UEFI. Ainsi, Intel BG permet de garantir l'authenticité du BIOS avant le démarrage du système d'exploitation (qui peut être exécuté sous la surveillance de la technologie Secure Boot).

La technologie Intel BG prévoit deux modes de fonctionnement (chaque mode n'interfère pas avec l'autre, c'est-à-dire que les deux modes peuvent être activés sur le système, ou les deux peuvent être désactivés).

Mesured Boot

En mode Measured Boot (MB), chaque composant de démarrage (à partir du CPU boot ROM) "mesure" le suivant, en utilisant les capacités du TPM (Trusted Platform Module). Pour ceux qui ne sont pas familiers, voici une explication.

Le TPM dispose de PCR (Platform Configuration Registers), dans lesquelles est enregistré le résultat de l'opération de hachage selon la formule :

C'est-à-dire que la valeur actuelle des PCR dépend de la précédente, et ces registres ne sont réinitialisés qu'à un RESET du système.

Ainsi, en mode MB, à un certain moment, les PCR reflètent un identifiant unique (dans les limites des capacités de l'opération de hachage) du code ou des données qui ont été "mesurés". Les valeurs des PCR peuvent être utilisées lors de l'opération de chiffrement de certaines données (TPM_Seal). Par la suite, leur déchiffrement (TPM_Unseal) ne sera possible que si les valeurs des PCR n'ont pas changé durant le démarrage (c'est-à-dire qu'aucun composant "mesuré" n'a été modifié).

Verified Boot

Le mode le plus redouté par les amateurs de modifications du BIOS UEFI est le Verified Boot (VB), dans lequel chaque composant de démarrage vérifie cryptographiquement l'intégrité et l'authenticité du suivant. En cas d'erreur de vérification, il se produit (une des):

• arrêt par timeout de 1 à 30 minutes (pour que l'utilisateur puisse comprendre pourquoi son ordinateur ne démarre pas et, si possible, tente de restaurer le BIOS);
• arrêt immédiat (pour que l'utilisateur ne comprenne rien et, encore moins, ne puisse agir);
• continuer à travailler avec un air impassible (ce cas où la sécurité n'est pas une priorité, car il y a des affaires plus importantes).

Le choix de l'action dépend de la configuration Intel BG (c'est-à-dire de la dite enforcement policy), qui est enregistrée de manière permanente par le fournisseur de la plateforme informatique dans un espace de stockage spécialement conçu - les fusions du chipset (FPF). Nous reviendrons sur ce point plus tard.

En plus de la configuration, le fournisseur génère deux clés RSA 2048 et crée deux structures de données (illustrées sur l'image) :

1. Le manifeste de la clé racine du fournisseur (KEYM, OEM Root Key Manifest), qui contient le SVN (Security Version Number) de ce manifeste, le hash SHA256 de la clé publique du manifeste suivant, la clé publique RSA (c'est-à-dire la partie publique de la clé racine du fournisseur) pour vérifier la signature de ce manifeste, ainsi que la propre signature;
2. Le manifeste IBB (IBBM, Initial Boot Block Manifest), qui contient le SVN de ce manifeste, le hash SHA256 de l'IBB, la clé publique pour vérifier la signature de ce manifeste et la propre signature.

Le hash SHA256 de la clé publique de la clé racine OEM est enregistré de manière permanente dans les fusions du chipset (FPF), tout comme la configuration Intel BG. Si la configuration Intel BG prévoit l'activation de cette technologie, alors à partir de ce moment, sur ce système, seul le détenteur de la partie privée de la clé racine OEM peut mettre à jour le BIOS (c'est-à-dire avoir la possibilité de recalculer ces manifestes), c'est-à-dire le fournisseur.

En regardant l'image, on peut douter de la nécessité d'une telle chaîne de vérification prolongée - on aurait pu utiliser un seul manifeste. Pourquoi compliquer les choses?

En réalité, Intel permet ainsi au fournisseur d'utiliser différentes clés IBB pour différentes gammes de ses produits et une seule comme clé racine. Si la partie privée de la clé IBB (qui signe le deuxième manifeste) fuit, l'incident n'affectera qu'une seule gamme de produits et uniquement jusqu'à ce que le fournisseur génère une nouvelle paire et inclue les manifestes recalculés dans la prochaine mise à jour du BIOS.

Mais si la clé racine (avec laquelle le premier manifeste est signé) est compromise, il sera impossible de la remplacer, car il n'existe pas de procédure de révocation, étant donné que le hachage de la partie publique de cette clé est programmé dans les FPF une fois pour toutes.

Configuration d'Intel Boot Guard

Passons maintenant en détail sur la configuration d'Intel BG et le processus de sa création. Si l'on regarde l'onglet correspondant dans l'interface graphique de l'outil Flash Image Tool du kit d'outils Intel System Tool Kit (STK), on peut constater que la configuration d'Intel BG inclut le hachage de la partie publique de la clé racine du fournisseur, une paire de valeurs peu claires et le profil dit Intel BG.

La structure de ce profil :

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 – ne rien faire
                                              // 01b – extinction avec un délai
                                              // 11b – extinction immédiate
	unsigned long : 26;
};

En général, la configuration d'Intel BG est une entité très flexible. Prenons par exemple le drapeau Force_Boot_Guard_ACM. Lorsqu'il est désactivé, si le module BG startup ACM n'est pas trouvé dans la mémoire flash SPI, il n'y aura aucune confiance dans le démarrage. Ce sera un démarrage non sécurisé.

Nous avons déjà mentionné ci-dessus que la politique d'exécution pour le mode VB peut être configurée de sorte qu'en cas d'erreur de vérification, un démarrage non sécurisé se produise à nouveau.

Laisser de telles choses à la discrétion des fournisseurs...

L'interface graphique de l'outil propose les profils « prêts à l'emploi » suivants :

Numéro
Mode
Description

0
No_FVME
la technologie Intel BG est désactivée

1
VE
le mode VB est activé, extinction par délai

2
VME
les deux modes (VB et MB) sont activés, extinction par délai

3
VM
les deux modes sont activés, sans extinction du système

4
FVE
le mode VB est activé, extinction immédiate

5
FVME
les deux modes sont activés, extinction immédiate

Comme déjà mentionné, la configuration d'Intel BG doit être une fois pour toutes écrite par le fournisseur du système dans les fusions du chipset (FPF) – un petit (selon des informations non vérifiées, seulement 256 octets) espace de stockage matériel d'informations à l'intérieur du chipset, qui peut être programmé en dehors des capacités de production de la société Intel (c'est donc Field Programmable Fuses).

Il est parfaitement adapté pour stocker la configuration, car :

• il a une zone programmable une seule fois pour le stockage de données (exactement là où la configuration d'Intel BG est enregistrée);
• seule Intel ME peut le lire et le programmer.

Ainsi, pour configurer la technologie Intel BG sur un système particulier, le fournisseur effectue les étapes suivantes lors de la fabrication :

1. À l'aide de l'outil Flash Image Tool (de Intel STK), il crée une image de firmware avec la configuration Intel BG sous forme de variables dans la région Intel ME (un soi-disant miroir temporaire pour les FPF) ;
2. Avec l'outil Flash Programming Tool (de Intel STK), il écrit cette image sur la mémoire flash SPI du système et ferme le soi-disant mode de fabrication (en envoyant une commande correspondante à Intel ME).

À la suite de ces opérations, Intel ME commite les valeurs spécifiées du miroir pour les FPF dans la région ME, définit les permissions dans les descripteurs de la mémoire flash SPI aux valeurs recommandées par Intel (décrit au début de l'article) et effectue un RESET du système.

Analyse de l'implémentation d'Intel Boot Guard

Pour analyser la mise en œuvre de cette technologie sur un exemple concret, nous avons vérifié les systèmes suivants pour la présence de traces de la technologie Intel BG :

Le système
Remarque

Gigabyte GA-H170-D3H
Skylake, prise en charge

Gigabyte GA-Q170-D3H
Skylake, prise en charge

Gigabyte GA-B150-HD3
Skylake, prise en charge

MSI H170A Gaming Pro
Skylake, pas de prise en charge

Lenovo ThinkPad 460
Skylake, prise en charge, technologie activée

Lenovo Yoga 2 Pro
Haswell, pas de prise en charge

Lenovo U330p
Haswell, pas de prise en charge

Par "prise en charge", nous entendons la présence du module Intel BG startup ACM, des manifestes mentionnés ci-dessus et du code correspondant dans le BIOS, c'est-à-dire l'implémentation pour analyse.

Par exemple, prenons l'image de la mémoire flash SPI téléchargée depuis le site officiel du fournisseur pour le Gigabyte GA-H170-D3H (version F4).

Intel CPU boot ROM

Tout d'abord, parlons des actions du processeur en cas d'activation de la technologie Intel BG.

Aucun échantillon de microcode déchiffré n'a pu être trouvé, donc la manière dont les actions décrites ci-dessous sont réalisées (dans le microcode ou matériellement) reste une question ouverte. Néanmoins, le fait que les processeurs Intel modernes soient capables d'effectuer ces actions est un fait.

Après le passage à l'état RESET, le processeur (dans l'espace d'adressage duquel le contenu de la mémoire flash est déjà mappé) trouve la table FIT (Firmware Interface Table). Il est facile de la trouver, un pointeur vers celle-ci est enregistré à l'adresse FFFF FFC0h.

Dans l'exemple considéré, cette adresse contient la valeur FFD6 9500h. En accédant à cette adresse, le processeur voit la table FIT, dont le contenu est divisé en enregistrements. Le premier enregistrement est l'en-tête de la structure suivante :

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // y compris l'entrée de l'en-tête FIT
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

Pour une raison inconnue, le checksum n'est pas toujours calculé dans ces tableaux (le champ est laissé à zéro).

Les autres enregistrements pointent vers différents binaires qui doivent être analysés/exécutés avant l'exécution du BIOS, c'est-à-dire avant le passage au vecteur RESET hérité (FFFF FFF0h). La structure de chaque enregistrement est la suivante :

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

Le champ EntryType indique le type de bloc auquel cet enregistrement fait référence. Nous connaissons plusieurs types :

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

Il est maintenant évident qu'un des enregistrements indique l'emplacement du binaire Intel BG startup ACM. La structure de l'en-tête de ce binaire est typique des modules de code développés par Intel (ACM, mises à jour du microcode, sections de code Intel ME, …).

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // en dwords
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // au format BCD
	unsigned long  TotalSize;      // en dwords
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // en dwords
	unsigned long  ScratchSize;    // en dwords
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

Le processeur charge ce binaire dans son cache, le vérifie et l'exécute.

Intel BG startup ACM

L'analyse du fonctionnement de cet ACM a révélé qu'il effectue les actions suivantes :

• il reçoit de Intel ME la configuration Intel BG, enregistrée dans les fusions du chipset (FPF) ;
• il localise les manifestes KEYM et IBBM, les vérifie.

Pour localiser ces manifestes, l'ACM utilise également la table FIT, qui prévoit deux types d'enregistrements pour indiquer les données des structures (voir FIT_ENTRY_TYPES ci-dessus).

Concentrons-nous sur les manifestes. Dans la structure du premier manifeste, nous voyons plusieurs constantes peu claires, un hachage de la clé publique du second manifeste et la clé publique OEM Root Key avec une signature sous forme de structure imbriquée :

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 == taille du hachage ?
	unsigned char  IbbmKeyHash[32]; // SHA256 d'une clé publique IBBM
	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];
};

Pour la vérification de la clé publique OEM Root Key, rappelons qu'un hachage SHA256 des fusibles est utilisé, qui a déjà été obtenu de Intel ME.

Passons au second manifeste. Il se compose de trois structures :

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Politiques de démarrage
	IBBS Ibbs;         // Description IBB
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // Signature IBBM
};

Dans le premier, il y a des constantes :

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

Dans le second se trouve le hachage SHA256 de l'IBB et le nombre de descripteurs qui décrivent le contenu de l'IBB (c'est-à-dire ce à quoi le hachage se réfère) :

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 == taille du hachage ?
	unsigned char  IbbHash[32];       // SHA256 d'un IBB
	unsigned char  NumIbbDescriptors;
};

Les descripteurs IBB suivent cette structure, les uns après les autres. Leur contenu a le format suivant :

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

C'est simple : chaque descripteur contient l'adresse/ la taille d'un morceau d'IBB. Par conséquent, la concaténation des blocs que ces descripteurs pointent (dans l'ordre où se trouvent les descripteurs eux-mêmes) constitue l'IBB. En général, l'IBB est un ensemble de tous les modules des phases SEC et PEI.

Le second manifeste se termine par une structure contenant la clé publique IBB (vérifiée par le hachage SHA256 du premier manifeste) et la signature de ce manifeste :

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

Ainsi, même avant le démarrage du BIOS UEFI, le processeur lancera l'ACM, qui vérifiera l'authenticité des contenus des sections de code des phases SEC et PEI. Ensuite, le processeur sort de l'ACM, passe par le vecteur de RESET et commence à exécuter le BIOS.

La section PEI vérifiée doit contenir un module qui vérifiera le reste du BIOS (code DXE). Ce module est déjà développé par l'IBV (Independent BIOS Vendor) ou par le fournisseur du système lui-même. Comme les systèmes compatibles Intel BG à notre disposition étaient uniquement ceux de Lenovo et de Gigabyte, examinons le code extrait précisément de ces systèmes.

Module UEFI BIOS LenovoVerifiedBootPei

Dans le cas de Lenovo, il s'agit du module LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, développé par Lenovo.

Son rôle consiste à rechercher (par GUID) la table de hachage pour DXE et à vérifier DXE.

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

La table de hachage {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} a le format suivant :

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

Module UEFI BIOS BootGuardPei

Dans le cas de Gigabyte, il s'agit du module BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, développé par AMI, ce qui signifie qu'il est présent dans tout BIOS AMI compatible avec Intel BG.

Son algorithme de fonctionnement est quelque peu différent, mais reste similaire :

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

La table de hachage {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, qu'il recherche, a le format suivant :

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

Parlons brièvement d'une autre implémentation d'Intel Boot Guard, qui a été trouvée dans un système plus récent basé sur un SoC Intel avec une microarchitecture Apollo Lake — ASRock J4205-IT.

Bien que cette version ne sera appliquée qu'aux SoC (de nouveaux systèmes avec l'architecture de processeur Kaby Lake continuent d'utiliser Intel Boot Guard 1.x), elle est d'un grand intérêt pour l'étude d'un nouveau variant d'architecture pour les plateformes basées sur Intel SoC, qui ont connu des changements significatifs, par exemple :

• les régions BIOS et Intel ME (plus précisément Intel TXE, selon la terminologie pour Intel SoC) sont désormais une seule région IFWI;
• bien que la plateforme ait inclus Intel BG, des structures telles que FIT, KEYM, IBBM n'ont pas été trouvées dans la mémoire flash;
• en plus des cœurs TXE et ISH (x86), le chipset a ajouté un troisième cœur (encore ARC, d'ailleurs) – PMC (Power Management Controller), lié à l'alimentation et à la surveillance de la performance.

Le contenu de la nouvelle région IFWI est un ensemble des modules suivants :

Décalage
Nom
Description

0000 2000h
SMIP
une certaine configuration de la plateforme, signée par le vendeur

0000 6000h
RBEP
section de code du firmware Intel TXE, x86, signée par Intel

0001 0000h
PMCP
section de code du firmware Intel PMC, ARC, signée par Intel

0002 0000h
FTPR
section de code du firmware Intel TXE, x86, signée par Intel

0007 B000h
UCOD
mises à jour de microcode pour CPU, signées par Intel

0008 0000h
IBBP
UEFI BIOS, phases SEC/PEI, x86, signée par le vendeur

0021 8000h
ISHC
section de code du firmware Intel ISH, x86, signée par le vendeur

0025 8000h
NFTP
section de code du firmware Intel TXE, x86, signée par Intel

0036 1000h
IUNP
inconnu

0038 1000h
OBBP
UEFI BIOS, phase DXE, x86, non signée

L'analyse du firmware TXE a révélé qu'après un RESET, TXE maintient le processeur dans cet état jusqu'à ce qu'il prépare le contenu de base de l'espace d'adressage pour le CPU (FIT, ACM, vecteur RESET …). TXE place ces données dans sa SRAM, puis fournit temporairement un accès au processeur avant de le libérer du RESET.

Sur la garde des rootkits

Et maintenant, parlons de "chaud". Un jour, nous avons découvert que sur de nombreux systèmes, les descripteurs flash SPI contenaient des autorisations d'accès aux régions de la mémoire flash SPI de sorte que tous les utilisateurs de cette mémoire pouvaient écrire et lire n'importe quelle région. Autrement dit, cela ne sert à rien.

Après vérification avec l'utilitaire MEinfo (d'Intel STK), nous avons constaté que le mode de fabrication sur ces systèmes n'était pas désactivé, par conséquent, les fusibles du chipset (FPF) ont été laissés dans un état indéfini. Oui, Intel BG n'est ni activé ni désactivé dans de tels cas.

Il s'agit des systèmes suivants (en ce qui concerne Intel BG et ce qui sera exposé par la suite dans l'article, nous parlerons de systèmes avec une microarchitecture processeur Haswell et supérieure) :

• tous les produits Gigabyte;
• tous les produits MSI;
• 21 modèles de ordinateurs portables Lenovo et 4 modèles de serveurs Lenovo.

Bien sûr, nous avons signalé cette découverte à ces vendeurs ainsi qu'à la société Intel.

Une réponse adéquate n'a suivi que de Lenovo, qui a reconnu le problème et a publié un patch.

Gigabyte semble avoir reçu l'information concernant la vulnérabilité, mais n'a pas commenté.

Communication avec MSI cela a complètement stagné sur notre demande d'envoyer sa clé PGP ouverte (afin d'envoyer la notification de sécurité de manière chiffrée). Ils ont déclaré qu'ils "sont un fabricant de matériel, et ne produisent pas de clés PGP".

Mais passons aux choses sérieuses. Étant donné que les fusibles sont laissés dans un état non défini, l'utilisateur (ou un attaquant) peut les programmer lui-même (la partie la plus complexe est de trouver l'Intel STK). Pour ce faire, il faut effectuer les actions suivantes.

1. Démarrer sous Windows (en fait, les actions décrites ci-dessous peuvent également être effectuées sous Linux, si une alternative à l'Intel STK est développée pour le système d'exploitation requis). En utilisant l'outil MEinfo, s'assurer que les fusibles sur ce système ne sont pas programmés.

2. Lire le contenu de la mémoire flash à l'aide de l'outil Flash Programming Tool.

3. Ouvrir l'image lue avec n'importe quel éditeur de BIOS UEFI, apporter les modifications nécessaires (par exemple, implémenter un rootkit), créer/modifier les structures KEYM et IBBM existantes dans la région ME.

Sur l'image, la partie publique de la clé RSA est mise en surbrillance, dont le hachage sera programmé dans les fusibles du chipset avec le reste de la configuration Intel BG.

4. Utiliser Flash Image Tool pour construire une nouvelle image du firmware (en définissant la configuration Intel BG).

5. Écrire la nouvelle image dans la mémoire flash à l'aide de Flash Programming Tool, s'assurer avec MEinfo que la région ME contient maintenant la configuration Intel BG.

6. Fermer le mode manufacturing mode avec Flash Programming Tool.

7. Le système redémarrera, après quoi MEinfo permettra de s'assurer que les FPF sont maintenant programmés.

Ces actions activeront définitivement Intel BG sur ce système. Cela ne pourra pas être annulé, ce qui signifie que :

• la mise à jour du BIOS UEFI sur ce système ne pourra être effectuée que par le détenteur de la partie privée de la clé racine (c'est-à-dire celui qui a activé Intel BG);
• si on restaure ce système avec le firmware d'origine, par exemple, à l'aide d'un programmateur, il ne s'allumera même pas (résultat de la politique d'application en cas d'erreur de vérification);
• pour se débarrasser de ce BIOS UEFI, il faut remplacer le chipset avec les FPF programmés par un "propre" (c'est-à-dire ressouder le chipset, si vous avez accès à une station de soudage infrarouge coûteuse comme une voiture, ou simplement remplacer la carte mère).

Pour comprendre ce qu'un tel rootkit peut causer, il faut évaluer ce qui permet l'exécution de son propre code dans l'environnement UEFI BIOS. Par exemple, dans le mode le plus privilégié du processeur – SMM. Un tel rootkit peut avoir les propriétés suivantes :

• s'exécuter parallèlement au système d'exploitation (il est possible de configurer un traitement basé sur la génération d'une interruption SMI, qui sera déclenchée par un minuteur) ;
• avoir tous les avantages d'être en mode SMM (accès complet au contenu de la mémoire vive et aux ressources matérielles, invisibilité par rapport au système d'exploitation) ;
• le code logiciel du rootkit peut être en forme chiffrée et être déchiffré lors du lancement en mode SMM. Comme clé pour le chiffrement, on peut utiliser n'importe quelles données accessibles uniquement en mode SMM. Par exemple, le hachage d’un ensemble d’adresses dans le SMRAM. Pour obtenir cette clé, il faudra accéder au SMM. Cela peut être fait de deux manières. Trouver un RCE dans le code SMM et l’exploiter, ou ajouter son propre module SMM dans le BIOS, ce qui est impossible, car nous avons activé Boot Guard.

Ainsi, cette vulnérabilité permet à un attaquant :

• de créer un rootkit caché, indétectable et de destination inconnue dans le système ;
• d'exécuter son code sur l'un des cœurs de la puce à l'intérieur d'Intel SoC, à savoir, sur Intel ISH (jetons un œil à l'image).

Bien que les capacités du sous-système Intel ISH ne soient pas encore pleinement explorées, il représente un vecteur d'attaque intéressant sur Intel ME.

Conclusions

1. L'étude a permis de produire une description technique du fonctionnement de la technologie Intel Boot Guard. Un inconvénient de quelques mystères dans le modèle Intel de sécurité par l'obscurité.
2. Un scénario d'attaque a été présenté, permettant de créer un rootkit indélete dans le système.
3. Nous avons vu que les processeurs Intel modernes peuvent exécuter de nombreux codes propriétaires avant même le démarrage du BIOS.
4. Les plates-formes basées sur l'architecture Intel 64 deviennent de moins en moins adaptées à l'exécution de logiciels libres : vérification matérielle, nombre croissant de technologies et sous-systèmes propriétaires (trois cœurs dans la puce SoC : x86 ME, x86 ISH et ARC PMC).

Atténuations

Les fournisseurs qui laissent intentionnellement le mode manufacturing ouvert doivent impérativement le fermer. Pour l’instant, ils ferment les yeux et les nouveaux systèmes Kaby Lake le montrent.

Les utilisateurs peuvent désactiver eux-mêmes Intel BG sur leurs systèmes (qui sont sujets à cette vulnérabilité) en exécutant l'outil Flash Programming Tool avec le paramètre -closemnf. Au préalable, il convient de s'assurer (à l'aide de MEinfo) que la configuration d'Intel BG dans la région ME prévoit bien la désactivation de cette technologie après programmation dans les FPF.

Source : habr.com