La botte de confiance de Schrödinger. Garde de démarrage Intel

Nous vous proposons de redescendre au niveau bas et de parler de la sécurité des plateformes informatiques compatibles firmware x86. Cette fois, l'ingrédient principal de la recherche est Intel Boot Guard (à ne pas confondre avec Intel BIOS Guard !) - une technologie de démarrage sécurisée du BIOS prise en charge par le matériel qu'un fournisseur de système informatique peut activer ou désactiver de manière permanente au stade de la production. Eh bien, nous connaissons déjà la recette de la recherche : découper finement la mise en œuvre de cette technologie par rétro-ingénierie, décrire son architecture, la remplir de détails non documentés, l'assaisonner de vecteurs d'attaque au goût et la mélanger. Ajoutons le feu avec une histoire sur la façon dont un bogue cloné dans la production de plusieurs fournisseurs pendant des années permet à un attaquant potentiel d'utiliser cette technologie pour créer un rootkit caché qui ne peut pas être supprimé (même par un programmeur) dans le système.

Soit dit en passant, l'article est basé sur les rapports "On Guard for Rootkits: Intel BootGuard" de la conférence Zéro Nuits 2016 et 29e réunion DefCon Russie (les deux présentations ici).

Firmware pour une plate-forme informatique avec architecture Intel 64

Pour commencer, répondons à la question : qu'est-ce que le firmware d'une plate-forme informatique moderne avec l'architecture Intel 64 ? Bien sûr, le BIOS UEFI. Mais cette réponse ne sera pas exacte. Jetons un coup d'œil à la figure, qui montre la version de bureau (ordinateur portable) de cette architecture.

Le lien est la base :

• Processeur (CPU, Central Processing Unit), qui, en plus des cœurs principaux, possède un cœur graphique intégré (pas dans tous les modèles) et un contrôleur de mémoire (IMC, Integrated Memory Controller);
• Chipset (PCH, Platform Controller Hub), contenant 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 possède également un micrologiciel (micrologiciel Intel ME).

Les ordinateurs portables, en plus de ce qui précède, nécessitent un contrôleur intégré (ACPI EC, Advanced Control and Power Interface Embedded Controller), qui est responsable du fonctionnement du sous-système d'alimentation, du pavé tactile, du clavier, des touches Fn (luminosité de l'écran, volume sonore, clavier rétroéclairage, etc.) et plus encore. Et il a aussi son propre firmware.

Ainsi, la combinaison du micrologiciel ci-dessus est le micrologiciel de la plate-forme informatique (micrologiciel du système), qui est stocké sur une mémoire flash SPI commune. Pour que les utilisateurs de cette mémoire ne se trompent pas sur l'endroit où se trouve quelqu'un, le contenu de cette mémoire est divisé dans les régions suivantes (comme indiqué sur la figure):

• BIOS UEFI ;
• Micrologiciel ACPI EC (une région distincte est apparue avec la microarchitecture du processeur Skylake (2015), mais dans la nature, nous n'avons pas encore vu d'exemples de son utilisation, de sorte que le micrologiciel du contrôleur intégré fait toujours partie du BIOS UEFI);
• micrologiciel Intel ME ;
• configuration (adresse MAC, etc.) de l'adaptateur réseau GbE (Gigabit Ethernet) intégré ;
• descripteurs flash - la région principale de la mémoire flash, qui contient des pointeurs vers d'autres régions, ainsi que des autorisations pour y accéder.

La différenciation de l'accès aux régions (conformément aux autorisations spécifiées) est gérée par le maître de bus SPI - le contrôleur SPI intégré au chipset, à travers lequel cette mémoire est accessible. Si les autorisations sont définies sur les valeurs recommandées (pour des raisons de sécurité) par Intel, alors chaque utilisateur du flash SPI a un accès complet (lecture/écriture) uniquement à sa région. Les autres sont soit en lecture seule, soit inaccessibles. Fait connu : sur de nombreux systèmes, le processeur a un accès complet au BIOS UEFI et au GbE, un accès en lecture uniquement aux descripteurs flash et aucun accès à la région Intel ME. Pourquoi beaucoup et pas tous ? Ce qui est recommandé est facultatif. Nous vous en dirons plus plus loin dans l'article.

Mécanismes de protection du micrologiciel d'une plate-forme informatique contre toute modification

Évidemment, le firmware d'une plate-forme informatique doit être protégé d'une éventuelle compromission, qui permettrait à un attaquant potentiel d'y prendre pied (survivre aux mises à jour/réinstallations d'OS), d'exécuter son code dans les modes les plus privilégiés, etc. Et délimiter l'accès aux régions de mémoire flash SPI, bien sûr, ne suffit pas. Ainsi, différents mécanismes propres à chaque environnement d'exécution sont utilisés pour protéger le firmware des modifications.

Ainsi, le micrologiciel Intel ME est signé pour le contrôle d'intégrité et d'authenticité, et est vérifié par le contrôleur ME chaque fois qu'il est chargé dans la mémoire ME UMA. Ce processus de vérification a déjà été discuté par nous dans l'un des articlesdédié au sous-système Intel ME.

Et le micrologiciel ACPI EC, en règle générale, n'est vérifié que pour son intégrité. Cependant, du fait que ce binaire est inclus dans le BIOS UEFI, il est presque toujours soumis aux mêmes mécanismes de protection que le BIOS UEFI utilise. Parlons d'eux.

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

Protection en écriture dans la région du BIOS UEFI

1. Protection physique du contenu de la mémoire flash SPI avec un cavalier de protection en écriture ;
2. Protection de la projection de la région UEFI BIOS dans l'espace d'adressage CPU à l'aide des registres PRx du chipset ;
3. Bloquer les tentatives d'écriture dans la région BIOS UEFI en générant et en traitant l'interruption SMI correspondante en définissant les bits BIOS_WE / BLE et SMM_BWP dans les registres du chipset ;
4. Une version plus avancée de cette protection est Intel BIOS Guard (PFAT).

En plus de ces mécanismes, les fournisseurs peuvent développer et mettre en œuvre leurs propres mesures de sécurité (par exemple, signer des capsules avec les mises à jour du BIOS UEFI).

Il est important de noter que sur un système spécifique (selon le fournisseur), tous les mécanismes de protection ci-dessus peuvent ne pas être appliqués, ils peuvent ne pas être appliqués du tout ou ils peuvent être mis en œuvre de manière vulnérable. Vous pouvez en savoir plus sur ces mécanismes et la situation de leur mise en œuvre dans cet article. Pour les personnes intéressées, nous vous recommandons de lire toute la série d'articles sur la sécurité du BIOS UEFI à partir de CodeRush.

Vérification de l'authentification BIOS UEFI

Lorsque nous parlons de technologies de démarrage fiables, la première chose qui nous vient à l'esprit est Secure Boot. Cependant, sur le plan architectural, il est conçu pour authentifier les composants externes au BIOS UEFI (pilotes, chargeurs, etc.), et non le micrologiciel lui-même.

Par conséquent, Intel dans les SoC avec la microarchitecture Bay Trail (2012) a implémenté un Secure Boot matériel non commutable (Verified Boot), qui n'a rien à voir avec la technologie Secure Boot susmentionnée. Plus tard (2013), ce mécanisme a été amélioré et, sous le nom d'Intel Boot Guard, a été publié pour les ordinateurs de bureau avec la microarchitecture Haswell.

Avant de décrire Intel Boot Guard, examinons les environnements d'exécution dans l'architecture Intel 64, qui, combinés, sont les racines de la confiance pour cette technologie de démarrage fiable.

Intel CPU

Cap suggère que le processeur est le principal environnement d'exécution dans l'architecture Intel 64. Pourquoi est-il aussi la racine de la confiance ? Il s'avère que c'est la possession des éléments suivants qui fait qu'il en est ainsi :

• Microcode ROM est une mémoire non volatile et non réinscriptible pour stocker le microcode. On pense que le microcode est la mise en œuvre du système d'instructions du processeur sur les instructions les plus simples. Cela se produit aussi dans le microcode insectes. Ainsi, dans le BIOS, vous pouvez trouver des fichiers binaires avec des mises à jour de microcode (ils se superposent au démarrage, car la ROM ne peut pas être écrasée). Le contenu de ces binaires est crypté, ce qui complique grandement l'analyse (par conséquent, le contenu spécifique du microcode n'est connu que de ceux qui le développent), et signé pour en contrôler l'intégrité et l'authenticité ;
• Clé AES pour déchiffrer le contenu des mises à jour du microcode ;
• un hachage de la clé publique RSA qui vérifie la signature des mises à jour du microcode ;
• Hachage de clé publique RSA, qui vérifie la signature des modules de code ACM (Authenticated Code Module) développés par Intel, que le CPU peut exécuter avant le démarrage du BIOS (hello microcode) ou pendant son fonctionnement, lorsque certains événements se produisent.

Intel ME

Ce sous-système de notre blog a été consacré à deux articles. Rappelons que cet environnement exécutable est basé sur le microcontrôleur intégré au chipset et est le plus caché et privilégié du système.

Malgré la furtivité, Intel ME est également la racine de la confiance, car il a :

• ME ROM - mémoire non volatile et non réinscriptible (aucune méthode de mise à jour fournie), contenant le code de démarrage, ainsi que le hachage SHA256 de la clé publique RSA, qui vérifie la signature du micrologiciel Intel ME ;
• Clé AES pour stocker des informations secrètes ;
• accès à un ensemble de fusibles (FPF, Field Programmable Fuses) intégrés au chipset pour le stockage permanent de certaines informations, notamment les informations spécifiées par le fournisseur du système informatique.

Intel BootGuard 1.x

Petit avertissement. Les numéros de version de la technologie Intel Boot Guard que nous utilisons dans cet article sont arbitraires et peuvent n'avoir rien à voir avec la numérotation utilisée dans la documentation interne d'Intel. De plus, les informations sur la mise en œuvre de cette technologie fournies ici ont été obtenues lors de la 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 d'authentification BIOS UEFI prise en charge par le matériel. À en juger par sa petite description dans le livre [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], cela fonctionne comme une chaîne de démarrage de confiance. Et le premier lien qu'il contient est le code de démarrage (microcode) à l'intérieur du CPU, qui est déclenché par l'événement RESET (à ne pas confondre avec le vecteur RESET dans le BIOS !). Le CPU trouve un module de code (Intel BG startup ACM) développé et signé par Intel sur la mémoire flash SPI, le charge dans son cache, le vérifie (il a déjà été noté plus haut que le CPU dispose d'un hash de clé publique qui vérifie la signature ACM ) et démarre.

Ce module de code est chargé de vérifier une petite partie de départ du BIOS UEFI - Initial Boot Block (IBB), qui, à son tour, contient la fonctionnalité de vérification de la partie principale du BIOS UEFI. Ainsi, Intel BG vous permet de vérifier l'authenticité du BIOS avant de démarrer le système d'exploitation (ce qui peut être effectué sous la supervision de la technologie Secure Boot).

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

Botte mesurée

En mode de démarrage mesuré (MB), chaque composant de démarrage (en commençant par la ROM de démarrage du processeur) "mesure" le suivant en utilisant les capacités du module de plateforme sécurisée (TPM). Pour ceux qui ne connaissent pas, je m'explique.

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

Ceux. la valeur PCR actuelle dépend de la précédente, et ces registres ne sont réinitialisés que lorsque le système est RESET.

Ainsi, en mode MB, à un moment donné, 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 PCR peuvent être utilisées dans l'opération de cryptage de certaines données (TPM_Seal). Après cela, leur déchiffrement (TPM_Unseal) ne sera possible que si les valeurs PCR n'ont pas changé à la suite du chargement (c'est-à-dire qu'aucun composant "mesuré" n'a été modifié).

Démarrage vérifié

La chose la plus effrayante pour ceux qui aiment modifier le BIOS UEFI est le mode Verified Boot (VB), dans lequel chaque composant de démarrage vérifie cryptographiquement l'intégrité et l'authenticité du suivant. Et en cas d'erreur de vérification, (l'un des éléments suivants) se produit :

• arrêt par timeout de 1 minute à 30 minutes (afin que l'utilisateur ait le temps de comprendre pourquoi son ordinateur ne démarre pas, et, si possible, essaierait de restaurer le BIOS);
• arrêt immédiat (pour que l'utilisateur n'ait pas le temps de comprendre et, en plus, de faire);
• poursuite du travail avec un visage impassible (le cas où il n'y a pas de temps pour la sécurité, car il y a des choses plus importantes à faire).

Le choix de l'action dépend de la configuration Intel BG spécifiée (à savoir, de la soi-disant politique d'application), qui est enregistrée en permanence par le fournisseur de la plate-forme informatique dans un stockage spécialement conçu - les fusibles du chipset (FPF). Nous reviendrons sur ce point plus en détail ultérieurement.

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 dans la figure) :

1. Le manifeste de la clé racine du fournisseur (KEYM, OEM Root Key Manifest), qui met le SVN (Security Version Number) de ce manifeste, le hachage SHA256 de la clé publique du prochain manifeste, la clé publique RSA (c'est-à-dire la partie publique du clé racine du fournisseur) pour vérifier la signature de ce manifeste et la signature elle-même ;
2. Le manifeste IBB (IBBM, Initial Boot Block Manifest), qui met le SVN de ce manifeste, le hachage SHA256 de l'IBB, la clé publique de vérification de la signature de ce manifeste, et la signature elle-même.

Le hachage SHA256 de la clé racine OEM est écrit en permanence sur les fusibles du chipset (FPF), tout comme la configuration Intel BG. Si la configuration Intel BG prévoit l'inclusion de cette technologie, alors désormais sur ce système seul le propriétaire de la partie privée de la Clé Racine OEM peut mettre à jour le BIOS (c'est-à-dire pouvoir recalculer ces manifestes), c'est-à-dire fournisseur.

Lorsque vous regardez l'image, des doutes surgissent immédiatement quant à la nécessité d'une chaîne de vérification aussi longue - vous auriez pu utiliser un seul manifeste. Pourquoi compliquer ?

En fait, Intel offre ainsi au fournisseur la possibilité d'utiliser différentes clés IBB pour différentes gammes de produits et une en tant que racine. Si la partie privée de la clé IBB (qui signe le deuxième manifeste) est divulguée, l'incident n'affectera qu'une seule ligne de produits et seulement jusqu'à ce que le fournisseur génère une nouvelle paire et active les manifestes recalculés dans la prochaine mise à jour du BIOS.

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

Configuration de la protection de démarrage Intel

Examinons maintenant de plus près la configuration Intel BG et le processus de sa création. Si vous regardez l'onglet correspondant dans l'interface graphique de l'outil d'image Flash du kit d'outils système Intel (STK), vous remarquerez que la configuration Intel BG inclut un hachage de la partie publique de la clé racine du fournisseur, quelques obscurs valeurs, etc. Profil 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 – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

En général, la configuration Intel BG est une entité très flexible. Considérez, par exemple, l'indicateur Force_Boot_Guard_ACM. Lorsqu'il est effacé, si le module ACM de démarrage BG sur le flash SPI n'est pas trouvé, aucun démarrage sécurisé ne se produira. Ce sera indigne de confiance.

Nous avons déjà écrit ci-dessus que la politique d'application pour le mode VB peut être configurée de sorte que si la vérification échoue, encore une fois, un téléchargement non approuvé se produira.

Laissez ce genre de choses aux vendeurs...

L'interface graphique de l'utilitaire fournit les profils "prêts à l'emploi" suivants :

Non.
régime
description

0
Non_FVME
Technologie Intel BG désactivée

1
VE
Mode VB activé, arrêt par timeout

2
VME
les deux modes sont activés (VB et MB), arrêt par timeout

3
VM
les deux modes sont activés, sans éteindre le système

4
FVE
Mode VB activé, arrêt immédiat

5
FVM
les deux modes activés, arrêt immédiat

Comme déjà mentionné, la configuration Intel BG doit être écrite une fois pour toutes par le fournisseur du système dans des fusibles de chipset (FPF) - un petit stockage d'informations matérielles (selon des informations non vérifiées, seulement 256 octets) à l'intérieur du chipset, qui peut être programmé à l'extérieur des installations de production d'Intel (c'est pourquoi Programmable sur le terrain fusibles).

Il est idéal pour stocker la configuration car :

• a une zone de stockage de données programmable une seule fois (juste là où la configuration Intel BG est écrite);
• seul Intel ME peut le lire et le programmer.

Ainsi, afin de définir la configuration de la technologie Intel BG sur un système spécifique, le fournisseur procède comme suit pendant la production :

1. À l'aide de l'utilitaire Flash Image Tool (d'Intel STK), crée une image de micrologiciel avec une configuration Intel BG donnée en tant que variables à l'intérieur de la région Intel ME (le soi-disant miroir temporaire pour les FPF) ;
2. À l'aide de l'outil de programmation Flash (d'Intel STK), écrit cette image dans la mémoire flash SPI du système et ferme le soi-disant. mode de fabrication (dans ce cas, la commande correspondante est envoyée à Intel ME).

À la suite de ces opérations, Intel ME engagera dans les FPF les valeurs données à partir du miroir pour les FPF dans la région ME, définira les autorisations dans les descripteurs flash SPI sur les valeurs recommandées par Intel (décrites au début du article) et effectuez une RÉINITIALISATION du système.

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

Afin d'analyser la mise en œuvre de cette technologie sur un exemple spécifique, nous avons vérifié les systèmes suivants pour les traces de la technologie Intel BG :

Système
Noter

Gigabyte GA-H170-D3H
Skylake, il y a du soutien

Gigaoctet GA-Q170-D3H
Skylake, il y a du soutien

Gigaoctet GA-B150-HD3
Skylake, il y a du soutien

MSI H170A Gaming Pro
Skylake, pas de support

Lenovo ThinkPad 460
Skylake, il y a du soutien, la technologie est en marche

Lenovo Yoga 2 Pro
Haswell, pas de support

Lenovo U330p
Haswell, pas de support

"Support" signifie la présence du module ACM de démarrage Intel BG, des manifestes mentionnés ci-dessus et du code correspondant dans le BIOS, c'est-à-dire implémentations pour l'analyse.

A titre d'exemple, prenons celui téléchargé depuis le bureau. Image du site du fournisseur de la mémoire flash SPI pour Gigabyte GA-H170-D3H (version F4).

ROM de démarrage du processeur Intel

Parlons tout d'abord des actions du processeur si la technologie Intel BG est activée.

Il n'a pas été possible de trouver des échantillons du microcode déchiffré, par conséquent, la manière dont les actions décrites ci-dessous sont mises en œuvre (en microcode ou en matériel) est une question ouverte. Néanmoins, le fait que les processeurs Intel modernes "peuvent" effectuer ces actions est un fait.

Après avoir quitté l'état RESET, le processeur (dans l'espace d'adressage duquel le contenu de la mémoire flash est déjà mappé) trouve le FIT (Firmware Interface Table). Le trouver est facile, le pointeur vers celui-ci est écrit à l'adresse FFFF FFC0h.

Dans cet exemple, cette adresse contient la valeur FFD6 9500h. En se tournant vers cette adresse, le processeur voit la table FIT, dont le contenu est divisé en enregistrements. La première entrée est l'en-tête de la structure suivante :

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

Pour une raison inconnue, la somme de contrôle n'est pas toujours calculée dans ces tables (le champ reste nul).

Les entrées restantes pointent vers divers binaires qui doivent être analysés / exécutés avant l'exécution du BIOS, c'est-à-dire avant de passer au vecteur RESET hérité (FFFF FFF0h). La structure de chacune de ces entrées 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 vers lequel cette entrée pointe. Nous en 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
};

Maintenant, il est évident que l'une des entrées pointe vers l'emplacement du binaire ACM de démarrage Intel BG. La structure d'en-tête de ce binaire est typique des modules de code développés par Intel (ACM, mises à jour de microcode, sections de code 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];
};

Le processeur charge ce binaire dans son cache, vérifie et se lance.

ACM de démarrage Intel BG

À la suite de l'analyse des travaux de cet ACM, il est apparu clairement qu'il fait ce qui suit :

• reçoit d'Intel ME la configuration Intel BG écrite sur les fusibles du chipset (FPF);
• trouve les manifestes KEYM et IBBM, les vérifie.

Pour trouver ces manifestes, ACM utilise également la table FIT, qui comporte deux types d'entrées pour pointer vers ces structures (voir FIT_ENTRY_TYPES ci-dessus).

Examinons de plus près les manifestes. Dans la structure du premier manifeste, nous voyons plusieurs constantes obscures, un hachage de la clé publique du deuxième manifeste et une clé racine OEM publique signée comme une 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 == 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];
};

Pour vérifier la clé publique de la clé racine OEM, nous rappelons que le hachage SHA256 des fusibles est utilisé, qui à ce moment a déjà été reçu d'Intel ME.

Passons au deuxième manifeste. Il se compose de trois structures :

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

Le premier contient 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
};

Le second contient le hachage SHA256 de l'IBB et le nombre de descripteurs qui décrivent le contenu de l'IBB (c'est-à-dire à partir de quoi le hachage est calculé) :

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

Les descripteurs IBB suivent cette structure, l'un après l'autre. 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/taille d'un bloc IBB. Ainsi, la concaténation des blocs pointés par ces descripteurs (dans l'ordre des descripteurs eux-mêmes) est IBB. Et, en règle générale, IBB est une combinaison de tous les modules des phases SEC et PEI.

Le deuxième 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, avant même le début de l'exécution du BIOS UEFI, le processeur lancera ACM, qui vérifiera l'authenticité du contenu des sections avec le code de phase SEC et PEI. Ensuite, le processeur quitte l'ACM, se déplace le long du vecteur RESET et commence à exécuter le BIOS.

La partition vérifiée PEI doit contenir un module qui vérifiera le reste du BIOS (code DXE). Ce module est déjà développé par IBV (Independent BIOS Vendor) ou le fournisseur du système lui-même. Parce que Seuls les systèmes Lenovo et Gigabyte se sont avérés être à notre disposition et ayant le support Intel BG, considérons le code extrait de ces systèmes.

Module BIOS UEFI LenovoVerifiedBootPei

Dans le cas de Lenovo, il s'est avéré être le module LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, développé par Lenovo.

Son travail consiste à rechercher (par GUID) une table de hachage pour le DXE et à vérifier le 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;
};

Module BIOS UEFI BootGuardPei

Dans le cas de Gigabyte, il s'est avéré être le module BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, développé par AMI, et donc présent dans n'importe quel BIOS AMI prenant en charge Intel BG.

Son algorithme de fonctionnement est quelque peu différent, cependant, il revient au même :

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'elle consulte 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 BootGuard 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 Intel SoC avec la microarchitecture Apollo Lake - ASRock J4205-IT.

Bien que cette version ne sera utilisée que dans les SoC (les nouveaux systèmes avec la microarchitecture du processeur Kaby Lake continuent d'utiliser Intel Boot Guard 1.x), il est d'un grand intérêt d'explorer une nouvelle option d'architecture pour les plates-formes basées sur les SoC Intel, qui a vu tangible changements, par exemple :

• Les régions BIOS et Intel ME (ou plutôt Intel TXE, selon la terminologie Intel SoC) forment désormais une seule région IFWI ;
• bien qu'Intel BG ait été activé sur la plate-forme, 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), un troisième cœur (à nouveau ARC, soit dit en passant) a été ajouté au chipset - PMC (Power Management Controller), associé à la garantie de l'opérabilité du sous-système d'alimentation et à la surveillance des performances.

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

Décalage
Prénom
description

0000 2000h
SMIP
une configuration de plate-forme, signée par le fournisseur

0000 6000h
RBEP
Section de code du micrologiciel Intel TXE, x86, signée par Intel

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

0002 0000h
FTPR
Section de code du micrologiciel Intel TXE, x86, signée par Intel

0007B000h
UCOD
Mises à jour du microcode CPU signées par Intel

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

0021 8000h
ISHC
section de code du micrologiciel Intel ISH, x86, signé par le fournisseur

0025 8000h
FTP
Section de code du micrologiciel Intel TXE, x86, signée par Intel

0036 1000h
IUNP
inconnu

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

Lors de l'analyse du firmware TXE, il est devenu évident qu'après 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...). De plus, TXE place ces données dans sa SRAM, après quoi il y fournit temporairement un accès au processeur et les "libère" de RESET.

À l'affût des rootkits

Eh bien, passons maintenant au "chaud". Nous avons découvert une fois que sur de nombreux systèmes, les descripteurs flash SPI ont des autorisations pour accéder aux régions de la mémoire flash SPI afin que tous les utilisateurs de cette mémoire puissent à la fois écrire et lire n'importe quelle région. Ceux. certainement pas.

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

Nous parlons des systèmes suivants (concernant Intel BG et ce qui sera décrit plus loin dans l'article, nous parlerons des systèmes avec microarchitecture de processeur Haswell et supérieur):

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

Bien sûr, nous avons signalé la découverte à ces fournisseurs, ainsi qu'à Intel.

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

Gigabyte Il semble qu'ils aient accepté des informations sur la vulnérabilité, mais n'aient fait aucun commentaire.

Communication avec MSI complètement bloqué à notre demande d'envoi de notre clé publique PGP (afin de leur envoyer un avis de sécurité crypté). Ils ont déclaré qu'ils "sont un fabricant de matériel et ne fabriquent pas de clés PGP".

Mais plus précisément. Comme les fusibles sont laissés dans un état indéfini, l'utilisateur (ou l'attaquant) peut les programmer lui-même (le plus difficile est trouver Intel STK). Cela nécessite les étapes suivantes.

1. Démarrez dans le système d'exploitation Windows (en général, les étapes décrites ci-dessous peuvent également être effectuées sous Linux, si vous développez un analogue d'Intel STK pour le système d'exploitation souhaité). À l'aide de l'utilitaire MEinfo, assurez-vous que les fusibles de ce système ne sont pas programmés.

2. Lisez le contenu de la mémoire flash à l'aide de l'outil de programmation Flash.

3. Ouvrez l'image de lecture à l'aide de n'importe quel outil d'édition du BIOS UEFI, apportez les modifications nécessaires (implémentez un rootkit, par exemple), créez / modifiez les structures KEYM et IBBM existantes dans la région ME.

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

4. À l'aide de Flash Image Tool, créez une nouvelle image de micrologiciel (en définissant la configuration Intel BG).

5. Écrivez une nouvelle image à flasher à l'aide de l'outil de programmation Flash, vérifiez à l'aide de MEinfo que la région ME contient maintenant la configuration Intel BG.

6. Utilisez l'outil de programmation Flash pour fermer le mode de fabrication.

7. Le système redémarrera, après quoi, en utilisant MEinfo, vous pourrez vérifier que les FPF sont maintenant programmés.

Ces gestes pour toujours activer Intel BG sur ce système. Il sera impossible d'annuler l'action, ce qui signifie :

• seul le propriétaire de la partie privée de la clé racine (c'est-à-dire celui qui a activé Intel BG) pourra mettre à jour le BIOS UEFI sur ce système ;
• si vous renvoyez le micrologiciel d'origine à ce système, par exemple à l'aide d'un programmeur, il ne s'allumera même pas (conséquence de la politique d'application en cas d'erreur de vérification);
• pour se débarrasser d'un tel BIOS UEFI, vous devez remplacer le chipset avec des FPF programmés par un "propre" (c'est-à-dire ressouder le chipset si vous avez accès à une station de soudage infrarouge au prix d'une voiture, ou simplement remplacer la carte mère ).

Pour comprendre ce qu'un tel rootkit peut faire, vous devez évaluer ce qui permet d'exécuter votre code dans un environnement BIOS UEFI. Dites, dans le mode le plus privilégié du processeur - SMM. Un tel rootkit peut avoir les propriétés suivantes :

• être exécuté en parallèle avec le système d'exploitation (vous pouvez configurer le traitement en générant une interruption SMI, qui sera déclenchée par une minuterie);
• avoir tous les avantages d'être en mode SMM (accès complet au contenu de la RAM et des ressources matérielles, secret du système d'exploitation);
• Le code du rootkit peut être chiffré et déchiffré lorsqu'il est lancé en mode SMM. Toutes les données disponibles uniquement en mode SMM peuvent être utilisées comme clé de cryptage. Par exemple, un hachage d'un ensemble d'adresses dans la SMRAM. Pour obtenir cette clé, vous devrez monter dans le SMM. Et cela peut se faire de deux manières. Trouvez le RCE dans le code SMM et exploitez-le, ou ajoutez votre propre module SMM au BIOS, ce qui est impossible, puisque nous avons activé Boot Guard.

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

• créer un rootkit caché et inamovible à des fins inconnues dans le système ;
• exécutez votre code sur l'un des cœurs du chipset à l'intérieur du SoC Intel, à savoir sur l'Intel ISH (regardez de plus près l'image).

Bien que les capacités du sous-système Intel ISH n'aient pas encore été explorées, il semble être un vecteur d'attaque intéressant contre Intel ME.

résultats

1. L'étude a fourni une description technique du fonctionnement de la technologie Intel Boot Guard. Moins quelques secrets dans la sécurité d'Intel à travers le modèle d'obscurité.
2. Un scénario d'attaque est présenté qui permet de créer un rootkit inamovible dans le système.
3. Nous avons vu que les processeurs Intel modernes sont capables d'exécuter beaucoup de code propriétaire avant même que le BIOS ne démarre.
4. Les plates-formes à architecture Intel 64 sont de moins en moins adaptées à l'exécution de logiciels libres : vérification matérielle, nombre croissant de technologies propriétaires et de sous-systèmes (trois cœurs dans le chipset SoC : x86 ME, x86 ISH et ARC PMC).

Atténuation

Les fournisseurs qui laissent intentionnellement le mode de fabrication ouvert doivent définitivement le fermer. Jusqu'à présent, ils ne font que fermer les yeux et les nouveaux systèmes de Kaby Lake le montrent.

Les utilisateurs peuvent désactiver Intel BG sur leurs systèmes (qui sont affectés par la vulnérabilité décrite) en exécutant l'outil de programmation Flash avec l'option -closemnf. Tout d'abord, vous devez vous assurer (à l'aide de MEinfo) que la configuration d'Intel BG dans la région ME prévoit la désactivation exacte de cette technologie après la programmation dans les FPF.

Source: habr.com