« Le fiasco de PKfail et la neutralisation du Secure Boot : une réalité plus répandue qu’on ne le pensait »

Une défaillance dans la chaîne d’approvisionnement compromettant les protections Secure Boot sur divers appareils informatiques s’étend à un plus grand nombre de modèles que ce qui était précédemment connu, y compris ceux utilisés dans les distributeurs automatiques, les terminaux de point de vente et les machines à voter.

Cette débâcle est due à l’utilisation de clés de plateformes de test non destinées à la production, employées dans des centaines de modèles d’appareils depuis plus d’une décennie. Ces clés cryptographiques constituent l’ancre de confiance entre l’appareil matériel et le firmware qui y est exécuté. Les clés de test de production—marquées de phrases telles que « NE PAS FAIRE CONFIANCE » dans les certificats—n’étaient jamais censées être utilisées dans des systèmes de production. Une liste impressionnante de fabricants d’appareils—including Acer, Dell, Gigabyte, Intel, Supermicro, Aopen, Foremelife, Fujitsu, HP et Lenovo—les a tout de même employées.

Dispositifs médicaux, consoles de jeux, distributeurs automatiques, terminaux de point de vente

Les clés de plateforme fournissent l’ancre de confiance sous la forme d’une clé cryptographique intégrée dans le firmware du système. Elles établissent la confiance entre le matériel de la plateforme et le firmware qui y fonctionne. Cela constitue, à son tour, la base du Secure Boot, une norme de l’industrie pour imposer cryptographiquement la sécurité dans l’environnement pré-démarrage d’un appareil. Intégré dans l’UEFI (Interface de Firmware Unifiée), le Secure Boot utilise la cryptographie à clé publique pour bloquer le chargement de tout code qui n’est pas signé par une signature numérique pré-approuvée.

L’utilisation des clés de test compromet toute la chaîne de sécurité établie par Secure Boot, car la portion privée sous-tendant leur sécurité est un secret de polichinelle connu de centaines, voire de milliers de personnes. Pour aggraver les choses, la portion privée de l’une des clés de test a été publiée dans un post sur GitHub en 2022. Cette information secrète est un élément nécessaire dans une classe d’attaques très sophistiquées qui plantent de soi-disant rootkits infectant l’UEFI des appareils protégés par Secure Boot.

Depuis la divulgation des conclusions 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 beaucoup plus élevé que ce qui était précédemment connu. Alors qu’ils connaissaient auparavant environ 513 modèles utilisant une clé de test, ils en comptent maintenant 972. De plus, ils savaient qu’environ 215 modèles affectés utilisaient la clé compromise sur GitHub ; ils en connaissent maintenant environ 490. Enfin, ils ont découvert quatre nouvelles clés de test qu’ils n’avaient pas identifiées auparavant, portant le total à environ 20. Les chercheurs ont surnommé cette défaillance généralisée de l’industrie PKfail, car elle implique des clés de plateforme (PKs).

« 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 le chercheur de Binarly, Fabio Pagani. « PKfail est un excellent exemple d’une défaillance de la sécurité de la chaîne d’approvisionnement impactant l’ensemble de l’industrie. Cependant, ces risques pourraient être atténués et totalement évitables si nous nous concentrions davantage sur la mise en œuvre d’une philosophie de sécurité par conception. »

Auparavant, 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 firmware UEFI afin qu’il fonctionne sur leurs configurations matérielles spécifiques. Depuis juillet, Binarly a trouvé des clés provenant de 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 post de lundi a précisé : « D’après nos données, nous avons trouvé des PKfail et des clés non-production sur des dispositifs médicaux, des ordinateurs de bureau, des ordinateurs portables, des consoles de jeux, des serveurs d’entreprise, des distributeurs automatiques, des terminaux de point de vente, et même des machines à voter. »

Les responsables de Binarly ont décliné de préciser des modèles spécifiques, invoquant des accords de non-divulgation car aucune solution n’est encore disponible. Les chiffres actualisés seront discutés lors de la conférence de sécurité LABScon prévue la semaine prochaine.

La découverte d’autres modèles d’appareils et de clés de plateforme a été réalisée grâce aux soumissions à un outil de détection gratuit proposé par Binarly. Depuis la publication des recherches sur PKfail, l’outil a reçu des 10 095 images de firmware uniques. Parmi celles-ci, 791, soit 8 %, contenaient les clés non production.

PKfail sape les assurances fournies par Secure Boot, une protection exigée par certains sous-traitants gouvernementaux et requise dans de nombreux paramètres d’entreprise. Secure Boot est également considéré comme une bonne pratique pour ceux qui font face à des menaces à haut risque. Pour les personnes ou les dispositifs qui n’utilisent pas Secure Boot, PKfail ne pose aucune menace supplémentaire. Le mois dernier, PKfail a été désigné sous les références CVE-2024-8105 et VU#455367.

En tant que journaliste, cet article m’a ouvert les yeux sur les défis de la sécurité dans la chaîne d’approvisionnement et l’importance cruciale d’une approche proactive pour éviter de telles défaillances à l’avenir. La sécurité numérique ne doit pas être une réflexion après coup, mais un principe fondamental dès la conception des produits.