Malgré une baisse des ventes globales d’ordinateurs, un chiffre stupéfiant 286,2 millions de PC Windows ont été vendus en 2022. Chacun de ces ordinateurs a été commercialisé avec un micrologiciel basé sur le Interface de micrologiciel extensible unifiée (UEFI), une alternative à l’héritage Système d’entrée/sortie de base (BIOS), qui fournit une intersection extensible entre le matériel et le système d’exploitation lui-même. La norme UEFI identifie également des moyens fiables de mettre à jour ce firmware à partir du système d’exploitation. Malgré son rôle omniprésent et indispensable, ce logiciel reste invisible pour la plupart des utilisateurs. Mais les attaquants ne l’ont pas oublié.
L’attaque baptisée Lotus Noir a d’abord exposé un kit de démarrage (forme avancée de logiciel malveillant) qui ne peut pas être facilement détecté ou supprimé. De nombreux fournisseurs, dont Microsoft, sont toujours dans une impasse avec ce bootkit car ils sont incapables de le détecter de manière fiable ou de protéger même les machines actuelles entièrement corrigées contre ce type d’attaque. Dans la foulée de cette attaque, un autre bientôt Il s’en est suivi une fuite d’informations sensibles, telles que des clés privées de plusieurs fabricants de PC. Ces clés privées, généralement utilisées pour signer cryptographiquement des logiciels basés sur UEFI, pourraient potentiellement être utilisées pour créer des logiciels malveillants pouvant obtenir un accès très privilégié au processeur. Les bootkits installent du code malveillant sur les logiciels qui sont à la fois essentiels et hautement fiables pour le fonctionnement normal de ces appareils.
Dans cet article de blog, que j’ai adapté de mon récent papier blanc, je développerai les préoccupations mises en lumière par ces attaques et soulignerai nos recommandations pour sécuriser l’écosystème UEFI et restaurer la confiance dans ce micrologiciel. Ces recommandations contribueront à la fois à sensibiliser les gens et à orienter les efforts à venir visant à créer un environnement informatique plus sûr.
Double problème : Baton Drop et Alder Lake
En octobre 2022, Kaspersky et SecurityWeek a eu vent très tôt de l’attaque BlackLotus utilisant UEFI pour créer des kits de démarrage. Au cours de ces premières étapes, de nombreux critiques, moi y compris, ont d’abord considéré ces [rumblings] comme comptes non confirmés sans suffisamment de preuves pour être considérés comme des menaces pour le micrologiciel basé sur UEFI. Cependant, ESET a ensuite fourni une explication détaillée de l’attaque et de ses ramifications. Puis, le même mois, le code source du processeur Intel Alder Lake, contenant certaines clés de la plateforme BootGuard d’Intel, a été divulgué. Ces attaques ont mis en lumière certains des défis de la confiance transitive que nous confèrent les logiciels signés numériquement. Examinons ces attaques plus en détail.
Lâcher le bâton
En janvier 2022, Microsoft a publié une vulnérabilité CVE-2022-21894, qui s’appelle désormais Baton Drop. La vulnérabilité provient du logiciel de démarrage signé de Microsoft, un petit logiciel qui aide le système d’exploitation à charger les données pendant le processus de démarrage. Le chargeur de démarrage a autorisé la troncature de la mémoire qui pourrait être utilisée de manière abusive pour contourner le démarrage sécurisé de la fonctionnalité UEFI. Cet exploit a rompu l’un des maillons importants de la chaîne de confiance qui passe des premières étapes de démarrage au système d’exploitation. Idéalement, le chargeur de démarrage vulnérable ne devrait plus être fiable. Cependant, plusieurs implémentations ont rendu cet élément du chargeur de démarrage essentiel au processus de démarrage, le rendant peu pratique à remplacer ou à supprimer.
Pour ajouter aux malheurs, un logiciel d’attaque de preuve de concept a été fourni pour Baton Drop dans un Dépôt GitHub. Microsoft n’avait aucun moyen de bloquer ce logiciel signé sans mettre en danger les machines fonctionnelles qui dépendaient du chargeur de démarrage vulnérable. Avec un exploit accessible au public, Microsoft a dû essayer de bloquer l’utilisation de ce chargeur de démarrage vulnérable à l’aide de l’UEFI. liste interdite. Cette approche s’est avérée difficile, car l’impact opérationnel du blocage de plusieurs versions de chargeurs de démarrage vulnérables aura un impact sur de nombreux appareils actuellement fonctionnels, tels que les ordinateurs portables, les ordinateurs de bureau et même les serveurs d’entreprise.
Cet événement a laissé une faille qui n’est pas passée inaperçue auprès des assaillants. Avec le bootkit BlackLotus, ils ont rapidement profité de la vulnérabilité et ont utilisé le propre référentiel de confiance de Microsoft pour télécharger des logiciels signés vulnérables. Ils ont ensuite construit une série d’attaques pour saper la validation logicielle fiable. Un bootkit résident pourrait alors être utilisé pour contourner la chaîne de confiance de sécurité et exécuter des logiciels arbitraires.
Une clé privée est volée, et maintenant ?
La fuite du code source du processeur Alder Lake a révélé que certaines clés privées utilisées pour signer numériquement les logiciels étaient fiables. Les clés privées présentes dans le référentiel pouvant être utilisées pour le débogage et des tâches spécifiques étaient désormais disponibles. En avril 2023, il a été signalé que le fournisseur de PC Micro-Star International (MSI), à la suite d’une attaque de ransomware, a vu son code source divulgué et son réseau violé, ajoutant encore plus de clés privées à la précieuse collection de l’attaquant. Il était désormais possible d’utiliser certaines de ces clés privées et de créer des logiciels malveillants signés qui auraient accès à un mode très privilégié du CPU.
La solution pour une telle clé volée dans la norme UEFI ressemblait étrangement au cas précédent du chargeur de démarrage vulnérable : ajoutez-la à l’UEFI. Liste de révocation, bloquant ainsi tous les logiciels du fournisseur compromis. Cependant, l’ajout d’une clé privée à une liste de révocation a un large éventail d’impacts, notamment la désactivation potentielle d’un module ou d’un périphérique matériel fonctionnel ou critique provenant du fournisseur interdit. Ce blocage pourrait potentiellement affecter tout ordinateur ayant une relation de chaîne d’approvisionnement avec le fournisseur interdit. En termes pratiques, il n’est pas facile d’auditer de nombreux ordinateurs actuels qui ne disposent pas d’une nomenclature permettant d’identifier ces fournisseurs et leurs composants.
Un dilemme logiciel interdit
La norme UEFI a développé des défenses contre les menaces posées par les clés privées volées qui peuvent miner la confiance dans le micrologiciel basé sur l’UEFI. Cependant, ces défenses étaient désormais testées dans des défis réels pour protéger les PC Windows contre les attaques. Permettez-moi d’explorer rapidement deux problèmes majeurs mettant en évidence la complexité de ces défenses.
UEFI Liste de révocation peut contenir plusieurs entrées de différents types, tels qu’un logiciel interdit, une clé de signature interdite et un périphérique interdit. Cependant, les logiciels essentiels à l’ordinateur, tels que les chargeurs de démarrage, ne peuvent pas être bloqués tant que chaque instance n’est pas remplacée. Plus le logiciel est répandu, comme chez les principaux fournisseurs de systèmes d’exploitation ou de matériel, plus il est difficile à remplacer.
La liste de révocation est également tout ou rien. Il n’existe aucun numéro de révision ni version de la liste de révocation, et il n’existe aucun moyen de la personnaliser. Dans presque toutes ses implémentations, il n’existe aucun moyen de vérifier dynamiquement la liste de révocation en utilisant le réseau ou tout autre moyen pour désactiver sélectivement un logiciel. Ce manque de personnalisation signifie que les responsables informatiques hésiteront pendant longtemps à ajouter tout logiciel signé par un fournisseur à grande échelle à la liste de révocation. Pour aggraver les problèmes, la liste de révocation est également limitée en taille en raison du petit stockage disponible dans le stockage non volatile du micrologiciel appelé PCI Flash. Cette limitation rend difficile la croissance de cette liste, car les logiciels signés sont considérés comme vulnérables ou risqués.
L’ajout des informations de clé publique d’un fournisseur à la liste de révocation entraîne de multiples conséquences. C’est estimé que tout fabricant d’équipement d’origine (OEM) qui vend un ordinateur a un contrôle direct sur moins de 10 % du logiciel BIOS. Les ordinateurs sont assemblés avec des pièces provenant de plusieurs fournisseurs qui, dans certains cas, assemblent leurs pièces auprès de plusieurs fournisseurs. Il en va de même pour l’arbre de la chaîne d’approvisionnement, qui devient de plus en plus complexe à mesure que notre économie mondiale trouve le prix le plus bas pour ces appareils. Il est difficile d’ajouter entièrement un fournisseur à la liste de révocation sans affecter certaines parties de l’ordinateur qui pourraient potentiellement devenir inutilisables ou peu fiables. Si un tel fournisseur a fourni des composants critiques, tels que des composants réseau, cela peut rendre le périphérique inutilisable et inutilisable sans accès physique et remontage. Enfin, les propriétaires du système sont désormais confrontés au défi de savoir comment gérer la liste de révocation et comment répondre à un compromis d’un fournisseur international.
Abandonner l’UEFI ou reconstruire ?
Alors, qu’est-ce qui n’a pas fonctionné avec l’UEFI ? Les experts qui ont créé et mis à jour la norme UEFI n’ont-ils pas vu cela venir ? Il est clair que les menaces contre l’UEFI sont, à certains égards, plus importantes que ce que la norme UEFI seule peut résoudre. Heureusement, divers efforts sont déployés pour sécuriser l’écosystème du micrologiciel UEFI. La source d’informations la plus définitive sur l’UEFI se trouve probablement dans le NIST Directives de résilience du micrologiciel de la plate-forme (SP 800-193). Bien qu’il soit difficile de prédire la prochaine menace et les objectifs de l’adversaire, les partenaires de l’écosystème UEFI n’ont qu’à corriger les inconnues connues dans le micrologiciel UEFI.
5 recommandations pour sécuriser l’écosystème UEFI
Ci-dessous, je décris cinq recommandations pour que l’écosystème UEFI réduise les risques et se défende contre les menaces décrites dans cet article. Une récente papier blanc présente ces recommandations plus en détail. Ce travail renvoie également à notre introduction précédente blog sur l’UEFIoù nous avons capturé certaines de nos premières préoccupations sur ce sujet.
- Créez un écosystème de vérification et d’attestation robuste. La vérification actuelle du micrologiciel et attestation devrait s’améliorer avec des technologies plus récentes, telles que la vérification dynamique et l’attestation à distance, pour garantir que la validation du logiciel est suffisamment avancée pour survivre aux nouvelles menaces contre l’UEFI.
- Améliorez la sécurité de la mémoire du code UEFI critique. La sécurité de la mémoire est cruciale dans les logiciels de bas niveau qui interagissent directement avec le matériel. Contrairement au logiciel au niveau de l’application, il n’existe aucun contrôle compensatoire pour les erreurs de mémoire dans le micrologiciel qui présentent un risque pour l’appareil. Il est essentiel que des pratiques de codage sécurisées et des outils permettant de créer des composants de micrologiciel sécurisés en mémoire soient facilement accessibles à la communauté UEFI, qui implique tous les membres de la communauté UEFI. Forum UEFIy compris les membres sans droit de vote.
- Appliquez le moindre privilège et l’isolation des composants pour le code UEFI. Une grande partie de ce que nous avons appris du développement de logiciels au cours des premières années douloureuses des logiciels vulnérables ne semble pas avoir été transférée au développement UEFI. L’isolation des composants et les principes du moindre privilège doivent être appliqués, de sorte que le logiciel UEFI ne dispose pas d’un accès non connecté et soit traité comme n’importe quel autre logiciel.
- Adoptez la transparence et la vérification des composants du micrologiciel. UN nomenclature logicielle (SBOM) est un élément crucial pour identifier les composants et les sources logiciels de manière fiable afin que le micrologiciel UEFI bénéficie également de la clarté indispensable dans cette chaîne d’approvisionnement complexe et connectée de fournisseurs.
- Développez des correctifs robustes et non intrusifs. Les mises à jour et les correctifs logiciels UEFI sont fastidieux et varient considérablement selon les implémentations des fournisseurs. Le processus est fastidieux pour les utilisateurs et les administrateurs de systèmes informatiques, limitant leur capacité à appliquer régulièrement des correctifs, à mettre à jour et à entretenir ces systèmes. Les mises à jour basées sur des normes devraient être possibles, avec le moins d’intrusion possible pour l’utilisateur.
La sécurisation de l’UEFI est l’affaire de tous
La norme UEFI est là pour rester et ne devrait que croître en termes d’utilisation et d’adoption. Il est donc important que les nombreux fournisseurs et parties prenantes qui construisent et créent des logiciels basés sur UEFI relèvent activement ces défis et y répondent collectivement. Les propriétaires et opérateurs de systèmes sont également invités à se renseigner sur ces défis et à attendre de leurs fournisseurs qu’ils protègent l’UEFI contre les attaques. Même si nous ne savons pas comment le paysage des menaces va évoluer, nous connaissons les lacunes et les motivations des menaces qui ont été mises en évidence ici. Il est impératif que la communauté informatique dans son ensemble s’engage dans des efforts visant à réduire continuellement les risques et à supprimer les incertitudes associées à l’utilisation de l’UEFI.
