Secure boot compromis sur plus de 200 modèles d'appareils, voire 500, de cinq grands fabricants
-
Jeudi, des chercheurs de la société de sécurité Binarly ont révélé que Secure Boot était complètement compromis sur plus de 200 modèles d’appareils vendus par Acer, Dell, Gigabyte, Intel et Supermicro. La cause : une clé cryptographique à la base du démarrage sécurisé sur ces modèles qui a été compromise en 2022. Dans un référentiel GitHub public validé en décembre de la même année, une personne travaillant pour plusieurs fabricants d’appareils basés aux États-Unis a publié ce que l’on appelle une clé de plate-forme, la clé cryptographique. qui constitue l’ancre racine de confiance entre le périphérique matériel et le micrologiciel qui s’y exécute. Le référentiel se trouvait sur https://github.com/raywu-aaeon/Ryzen2000_4000.git, et on ne sait pas quand il a été supprimé.
Le référentiel comprenait la partie privée de la clé de la plateforme sous forme cryptée. Le fichier crypté, cependant, était protégé par un mot de passe à quatre caractères, une décision qui rendait trivial pour Binarly, et pour toute autre personne même un peu curieuse, de déchiffrer le mot de passe et de récupérer le texte brut correspondant. La divulgation de la clé est passée largement inaperçue jusqu’en janvier 2023, lorsque les chercheurs de Binarly l’ont trouvée alors qu’ils enquêtaient sur un incident dans la chaîne d’approvisionnement. Maintenant que la fuite a été révélée, les experts en sécurité affirment qu’elle torpille effectivement les garanties de sécurité offertes par Secure Boot.
“C’est un gros problème”, a déclaré Martin Smolár, un analyste de logiciels malveillants spécialisé dans les rootkits, qui a examiné l’étude Binarly et m’en a parlé. « Il s’agit essentiellement d’un contournement sécurisé du démarrage illimité pour les appareils qui utilisent cette clé de plate-forme. Ainsi, jusqu’à ce que les fabricants d’appareils ou les OEM fournissent des mises à jour du micrologiciel, n’importe qui peut essentiellement… exécuter n’importe quel logiciel malveillant ou code non fiable lors du démarrage du système. Bien sûr, un accès privilégié est requis, mais dans de nombreux cas, ce n’est pas un problème.
Les chercheurs de Binarly ont déclaré que leurs analyses des images du micrologiciel ont découvert 215 appareils utilisant la clé compromise, qui peuvent être identifiés par le numéro de série du certificat 55:fb:ef:87:81:23:00:84:47:17:0b:b3 : cd:87:3a:f4. Un tableau apparaissant à la fin de cet article répertorie chacun d’entre eux.
Les chercheurs ont rapidement découvert que la compromission de la clé n’était que le début d’une rupture beaucoup plus importante de la chaîne d’approvisionnement qui soulève de sérieux doutes sur l’intégrité du démarrage sécurisé sur plus de 300 modèles d’appareils supplémentaires provenant de pratiquement tous les principaux fabricants d’appareils. Comme c’est le cas avec la clé de plate-forme compromise dans la fuite GitHub de 2022, 21 clés de plate-forme supplémentaires contiennent les chaînes « NE PAS EXPÉDIER » ou « NE PAS FAIRE CONFIANCE ».
Certificat de test fourni par AMI.Ces clés ont été créées par 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. Comme le suggèrent les chaînes, les clés n’ont jamais été destinées à être utilisées dans des systèmes de production. Au lieu de cela, AMI les a fournis à des clients ou des clients potentiels pour les tester. Pour des raisons qui ne sont pas claires, les clés de test ont été intégrées dans les appareils d’une liste presque inexhaustive de fabricants. Outre les cinq fabricants mentionnés précédemment, ils incluent Aopen, Foremelife, Fujitsu, HP, Lenovo et Supermicro.
Les meilleures pratiques de gestion des clés cryptographiques exigent que les informations d’identification telles que les clés de plate-forme de production soient uniques pour chaque ligne de produits ou, au minimum, soient uniques pour un fabricant d’appareil donné. Les meilleures pratiques imposent également que les clés soient alternées périodiquement. En revanche, les clés de test découvertes par Binarly ont été partagées pendant plus d’une décennie par plus d’une douzaine de fabricants d’appareils indépendants. Le résultat est que les clés ne sont plus fiables car la partie privée de celles-ci est un secret industriel de polichinelle.
Dans une interview, le fondateur et PDG de Binarly, Alex Matrosov, a écrit :
« Imaginez que tous les habitants d’un immeuble aient la même serrure et la même clé de porte d’entrée. Si quelqu’un perd la clé, cela pourrait poser un problème pour tout le bâtiment. Mais que se passerait-il si les choses étaient encore pires et que d’autres bâtiments avaient la même serrure et les mêmes clés ?
Matrosov a déclaré que son équipe avait trouvé des clés de plate-forme de test identiques sur les produits liés au client et au serveur. Les membres de l’équipe ont également déterminé qu’au moins une clé de test était utilisée dans des appareils vendus par trois fabricants distincts.
« Si la clé est divulguée, cela aura un impact sur l’écosystème », a-t-il expliqué. “Cela n’affecte pas un seul appareil.”
Binarly a nommé sa découverte PKfail en reconnaissance du problème massif de la chaîne d’approvisionnement résultant de l’incapacité de l’ensemble de l’industrie à gérer correctement les clés de la plate-forme. Le rapport est disponible ici . Les vidéos de preuve de concept sont ici et ici . Binarly a fourni un outil d’analyse ici .
Source et beaucoup plus: https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/
Encore un truc aussi foireux que BitLocker et une bonne raison de ne pas exiger ça de windows 11/12