PKfail, la faille qui met KO Secure Boot

Des chercheurs en sécurité avertissent que certains fabricants de PC et de serveurs utilisent des clés cryptographiques non sécurisées comme base de confiance pour Secure Boot, une fonction de sécurité importante dans les ordinateurs modernes qui empêche les malwares de s'activer au début du processus de démarrage. L'une de ces clés a fait l'objet d'une fuite accidentelle, ce qui risque de rompre les garanties de démarrage sécurisé pour des centaines de modèles d'ordinateurs provenant de sept fabricants. Cependant, près de 900 modèles au cours des 12 dernières années utilisent des clés qui ont probablement été générées à des fins de test et qui n'auraient jamais dû être utilisées en production, selon un rapport de la société de sécurité Binarly, qui a baptisé ce problème PKfail. Au début de l'année, nous avons remarqué que la clé privée d'American Megatrends International (AMI) liée à la « clé principale » de Secure Boot, appelée Platform Key (PK), avait été exposée publiquement dans une fuite de données », écrivent les chercheurs. « L'incident s'est produit chez un ODM [original design manufacturer] responsable du développement de microprogrammes pour de nombreux fournisseurs de terminaux, y compris un basé aux États-Unis. Ces équipements correspondant à cette clé sont toujours déployés sur le terrain, et la clé est également utilisée dans des terminaux d'entreprise récemment mis sur le marché. »

Secure Boot est une fonctionnalité de l’UEFI (Unified Extensible Firmware Interface), qui a succédé au BIOS (Basic Input/Output System) traditionnel présent sur les anciens ordinateurs. En principe, le Secure Boot garantit que le système ne démarre qu'avec des logiciels et des firmwares fiables. Il est essentiel de garantir l'intégrité du processus de démarrage, car les codes malveillants qui s'exécutent à ce stade précoce prennent le contrôle total du système d'exploitation, en désactivant ou en contournant ses fonctions de sécurité. Avant que le système Secure Boot ne soit largement adopté, de nombreux malwares injectaient du code dans le chargeur de démarrage des ordinateurs compromis ou dans le BIOS/UEFI lui-même. Ces bootkits - rootkits au niveau du démarrage - donnent aux attaquants une persistance de haut niveau sur les systèmes compromis et la possibilité de cacher des fichiers et des processus à tous les produits de sécurité des points finaux fonctionnant sur ces systèmes. Secure Boot utilise le chiffrement à clé publique, celles-ci sont stockées dans l'UEFI étant utilisées pour valider les composants signés avec les clés privées correspondantes. Au cœur du système se trouve une clé publique appelée « Platform Key » : cette dernière est censée être générée par le fabricant de l'ordinateur et, selon les chercheurs de Binarly, devrait être renouvelée périodiquement et, idéalement, ne pas être réutilisée d'une ligne de produits à l'autre afin de limiter l'impact d'une compromission. En outre, la clé privée doit être stockée en toute sécurité dans des modules de sécurité matériels (HSM), d'où elle ne peut pas être facilement volée ou divulguée.

Une clé privée racine qui n'a rien à faire dans un dépôt public GitHub

En aucun cas la clé privée racine d'un dispositif de sécurité aussi important ne devrait se retrouver dans un dépôt public sur GitHub, comme l'a fait la clé de la plateforme AMI trouvée par Binarly. Ce n'est pas le seul problème. AMI est l'un des trois fournisseurs de BIOS indépendants (IBV) qui produisent des implémentations UEFI de référence pour les fabricants de PC et les OEM, qui personnalisent ensuite ces implémentations pour leurs produits. Binarly estime que la génération de nouvelles clés de plateforme devrait faire partie de ce processus de personnalisation, car ce sont les fabricants de PC qui devraient être responsables de leurs « plateformes », et non une tierce partie. Le certificat de clé publique de la clé privée qui a fait l'objet d'une fuite comporte un champ Common Name qui indique « DO NOT TRUST - AMI Test PK » (ne pas faire confiance - AMI Test PK). Pourtant, il a été utilisé dans des centaines de modèles de sept fournisseurs différents.

« Cette clé a probablement été incluse dans leur implémentation de référence en espérant qu'elle serait remplacée par une autre clé générée en toute sécurité par les entités en aval de la chaîne d'approvisionnement », écrivent les chercheurs. « Les clés de test sont partagées avec des partenaires commerciaux et des fournisseurs en espérant qu'elles soient traitées comme des clés non fiables. En outre, la clé AMI qui a fait l'objet d'une fuite a été utilisée dans de nombreuses gammes de produits, des ordinateurs portables de jeu aux cartes mères de serveurs, ce qui accroît considérablement l'impact de la fuite dans tous les secteurs et pour tous les types d'utilisateurs.

Comment les attaquants peuvent-ils abuser de la clé divulguée ?

Secure Boot dispose de quatre emplacements de clés et de bases de données dans l'UEFI. La clé de plateforme, utilisée pour valider tous les composants du microprogramme, et une autre clé, appelée clé d'échange de clés (KEK), sont au cœur de ce système. La KEK peut servir pour mettre à jour une base de données appelée db, qui contient les signatures des chargeurs d'amorçage et d'autres composants EFI tiers autorisés à être exécutés, par exemple le chargeur d'amorçage Windows ou celui de Linux. Il peut également actualiser dbx, une base de données qui contient une liste noire de signatures, par exemple pour les bootloader vulnérables. Un attaquant disposant d'un accès privilégié au système d'exploitation d'un ordinateur qui exploite la fuite de PK peut générer une autre KEK, puis la signer et l'insérer dans l'emplacement KEK à l'aide d'outils tels que efi-updatevar. Il peut ensuite se servir de sa nouvelle clé pour modifier la base de données de signatures db afin d'y ajouter la signature d'un module .efi malveillant qu'il a créé et placé dans la partition EFI sur le disque. Ce module sera alors exécuté à l'amorçage, ce qui lui permettra de contrôler le démarrage et le noyau de Windows.

Les attaquants exploitent déjà les vulnérabilités connues de Secure Boot pour déployer des bootkits. L'année dernière, des chercheurs d'ESET ont mis en garde contre un nouveau bootkit UEFI appelé BlackLotus qui exploite une vulnérabilité de Windows connue sous le nom de Baton Drop (CVE-2022-21894) pour contourner la fonction via des composants de chargeur d'amorçage vulnérables. Il ne serait donc pas surprenant que des attaquants commencent à exploiter une fuite de la clé de plateforme. Il y a deux ans, des chercheurs d'Eclypsium ont découvert des vulnérabilités qui pouvaient être utilisées pour contourner Secure Boot, tandis que Binarly a présenté 12 autres failles qui pouvaient conduire à l'exécution de code à distance avant le démarrage dans les implémentations UEFI. La possibilité que le PK de test AMI soit tombé entre de mauvaises mains n'est pas à exclure. Selon les chercheurs de Binarly, le dépôt contenant la clé a été supprimé au bout de quatre mois, mais il a fallu cinq mois pour supprimer tous les forks. La clé privée n'était pas stockée en clair et était chiffrée, mais protégée uniquement par un mot de passe de quatre caractères qui pouvait être déchiffré en quelques secondes à l'aide d'outils de reconnaissance de mot de passe basique.

L'utilisation de clés de plateforme AMI de test dans les binaires des microprogrammes est courante.

Après avoir trouvé la clé divulguée, les experts ont découvert des rapports datant de 2016 selon lesquels certaines clés de plateforme contiennent des mots tels que « NE PAS FAIRE CONFIANCE » et « clé de test. » Il y avait même un identifiant de vulnérabilité (CVE-2016-5247) généré à l'époque pour plusieurs modèles Lenovo utilisant des clés de test AMI. Mais la clé qui a fait l'objet d'une fuite a été trouvée dans des micrologiciels publiés dès 2018 et plus récemment cette année. Pour savoir si la pratique est encore courante, les spécialistes de Binarly ont analysé leur base de données de dizaines de milliers de binaires de micrologiciels collectés au fil des ans et ont identifié 22 PK de test AMI différentes avec des avertissements « DO NOT TRUST » ou « DO NOT SHIP ». Ces clés ont été trouvées dans des binaires de microprogrammes UEFI pour près de 900 cartes mères d'ordinateurs et de serveurs différents provenant de plus de 10 fournisseurs, dont Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo et Supermicro. Ensemble, ils représentaient plus de 10 % des images de microprogrammes de l'ensemble de la base.

Ces clés ne sont pas fiables, car elles ont probablement été partagées avec de nombreux fournisseurs, OEM, ODM et développeurs - et ont probablement été stockées de manière non sécurisée. Il est possible que certaines d'entre elles aient déjà fait l'objet d'une fuite ou d'un vol dans le cadre d'incidents non découverts. L'année dernière, un dump de données publié par un cybergang relatif au fabricant de cartes mères et d'ordinateurs Micro-Star International (MSI) comprenait une clé privée OEM d'Intel et, un an plus tôt, une fuite de données de Lenovo comprenait le code source d'un micrologiciel et les clés de signature Intel Boot Guard.

Binarly a mis en place un scanner en ligne permettant aux utilisateurs de soumettre des copies du micrologiciel de leur carte mère afin de vérifier s'il utilise une clé de test, et une liste des modèles de cartes mères concernés est incluse dans le bulletin de l'entreprise. Malheureusement, les utilisateurs ne peuvent pas faire grand-chose tant que les vendeurs n'ont pas fourni de mises à jour du micrologiciel avec de nouvelles clés de test générées de manière sécurisée, en supposant que les modèles de leurs cartes mères soient encore pris en charge. La première utilisation de ces clés de test trouvée par Binarly remonte à 2012.