Getty Images
Une défaillance de la chaîne d’approvisionnement qui compromet les protections Secure Boot sur les appareils informatiques de l’ensemble de l’industrie de fabrication d’appareils s’étend à un nombre beaucoup plus grand de modèles que ce que l’on connaissait auparavant, y compris ceux utilisés dans les distributeurs automatiques de billets, les terminaux de point de vente et les machines à voter.
Cette débâcle est le résultat de clés de plateforme de test non destinées à la production, utilisées dans des centaines de modèles d’appareils depuis plus d’une décennie. Ces clés cryptographiques constituent l’ancrage de la racine de confiance entre le périphérique matériel et le micrologiciel qui l’exécute. Les clés de production de test, estampillées de phrases telles que « NE PAS FAIRE CONFIANCE » dans les certificats, n’étaient pas destinées à être utilisées dans des systèmes de production. Une liste de fabricants d’appareils, dont Acer, Dell, Gigabyte, Intel, Supermicro, Aopen, Foremelife, Fujitsu, HP et Lenovo, les ont quand même utilisées.
Appareils médicaux, consoles de jeux, distributeurs automatiques de billets, terminaux de point de vente
Les clés de plate-forme fournissent l’ancre de confiance sous la forme d’une clé cryptographique intégrée au micrologiciel du système. Elles établissent la confiance entre le matériel de la plate-forme et le micrologiciel qui s’exécute dessus. Cela, à son tour, fournit la base de Secure Boot, une norme industrielle pour l’application cryptographique de la sécurité dans l’environnement de pré-démarrage d’un appareil. Intégré à l’UEFI (Unified Extensible Firmware Interface), Secure Boot utilise la cryptographie à clé publique pour bloquer le chargement de tout code qui n’est pas signé avec une signature numérique pré-approuvée.
L’utilisation des clés de la plateforme de test compromet l’ensemble de la chaîne de sécurité établie par Secure Boot, car la partie privée qui sous-tend leur sécurité est un secret de polichinelle connu de centaines, voire de milliers de personnes différentes. Pire encore, la partie privée de l’une des clés de test a été publiée dans un article de 2022 sur GitHub. Ces informations secrètes sont un élément nécessaire dans une classe d’attaques très sophistiquées qui implantent des rootkits qui infectent l’UEFI des appareils protégés par Secure Boot.
Depuis la publication des résultats en juillet, les chercheurs de la société de sécurité Binarly ont appris que le nombre de modèles d’appareils utilisant les clés de test est bien plus important que ce que l’on pensait auparavant. Alors qu’ils connaissaient auparavant environ 513 modèles utilisant une clé de test, ils en connaissent désormais 972. De plus, ils savaient auparavant qu’environ 215 des modèles concernés utilisaient la clé compromise sur GitHub ; ils en connaissent désormais environ 490. Enfin, ils ont découvert quatre nouvelles clés de test qu’ils n’avaient pas identifiées auparavant, ce qui porte le nombre total à environ 20. Les chercheurs ont surnommé cette défaillance à l’échelle de l’industrie PKfail, car elle implique des PK (clés de plate-forme).
« La complexité de la chaîne d’approvisionnement dépasse notre capacité à gérer efficacement les risques associés aux fournisseurs tiers », a écrit lundi Fabio Pagani, chercheur chez Binarly. « PKfail est un excellent exemple de défaillance de la sécurité de la chaîne d’approvisionnement qui affecte l’ensemble du secteur. Cependant, ces risques pourraient être atténués et totalement évitables si nous nous concentrons davantage sur la mise en œuvre d’une philosophie de sécurité dès la conception. »
Jusqu’à présent, toutes les clés découvertes provenaient d’AMI, l’un des trois principaux fournisseurs de kits de développement de logiciels que les fabricants d’appareils utilisent pour personnaliser leur micrologiciel UEFI afin qu’il fonctionne sur leurs configurations matérielles spécifiques. Depuis juillet, Binarly a trouvé des clés provenant des concurrents d’AMI, Insyde et Phoenix.
Binarly a également découvert que les trois fournisseurs suivants vendent également des appareils affectés par PKfail :
Le message de lundi continuait ainsi : « Sur la base de nos données, nous avons trouvé des clés PKfail et des clés non productives sur des appareils médicaux, des ordinateurs de bureau, des ordinateurs portables, des consoles de jeu, des serveurs d’entreprise, des distributeurs automatiques de billets, des terminaux de point de vente et des endroits étranges comme des machines à voter. »
Les responsables de Binarly ont refusé d’identifier des modèles spécifiques, invoquant des accords de confidentialité, car aucun correctif n’est encore disponible. Les chiffres mis à jour seront discutés lors de la conférence sur la sécurité LABScon prévue la semaine prochaine.
La découverte de modèles d’appareils supplémentaires et de clés de plateforme a été réalisée grâce à des soumissions à un outil de détection gratuit fourni par Binarly. Dans les mois qui ont suivi la publication de l’étude PKfail, l’outil a reçu des soumissions de 10 095 images de firmware uniques. Parmi celles-ci, 791, soit 8 %, contenaient des clés non productives.
PKfail porte atteinte aux garanties fournies par Secure Boot, une protection obligatoire pour certains sous-traitants gouvernementaux et requise dans de nombreux environnements d’entreprise. Secure Boot est également considéré comme une bonne pratique pour ceux qui sont confrontés à des menaces à haut risque. Pour les personnes ou les appareils qui n’utilisent pas Secure Boot, PKfail ne présente aucune menace supplémentaire. Le mois dernier, PKfail a reçu les désignations CVE-2024-8105 et VU#455367.