Les chercheurs en s\u00e9curit\u00e9 de l'entreprise Binarly ont identifi\u00e9 une possibilit\u00e9 de contournement du mode de v\u00e9rification de d\u00e9marrage UEFI Secure Boot sur plus de 800 produits fabriqu\u00e9s par Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo et Supermicro. Le probl\u00e8me a \u00e9t\u00e9 surnomm\u00e9 PKfail et est li\u00e9 \u00e0 l'utilisation dans les firmwares d'une cl\u00e9 de plateforme (PK, Platform Key) non fiable, g\u00e9n\u00e9r\u00e9e par AMI (American Megatrends International) et fournie comme un \u00e9chantillon de test. Les firmwares les plus anciens utilisant cette cl\u00e9 de test ont \u00e9t\u00e9 publi\u00e9s en 2012, tandis que les plus r\u00e9cents sont dat\u00e9s de juin 2024. Selon les chercheurs, plus de 10 % de tous les firmwares v\u00e9rifi\u00e9s sont concern\u00e9s par ce probl\u00e8me. <\/p>\n
Dans les param\u00e8tres de la cl\u00e9, il \u00e9tait indiqu\u00e9 qu'elle n'\u00e9tait pas fiable et ne devait pas \u00eatre fournie dans ses produits. Il \u00e9tait pr\u00e9vu que cette cl\u00e9 de test soit remplac\u00e9e par une cl\u00e9 propre, mais les fabricants n'ont pas tenu compte de l'avertissement et ont utilis\u00e9 dans les firmwares finaux une cl\u00e9 g\u00e9n\u00e9rique standard, envoy\u00e9e \u00e0 tous les partenaires et clients d'AMI. <\/p>\n
La partie priv\u00e9e de la cl\u00e9 de test AMI, n\u00e9cessaire \u00e0 la cr\u00e9ation de signatures num\u00e9riques, a \u00e9t\u00e9 rendue accessible au public apr\u00e8s une fuite d'informations chez l'un des fabricants de mat\u00e9riel, dont un employ\u00e9 a par erreur publi\u00e9 dans un d\u00e9p\u00f4t public sur GitHub un code contenant cette cl\u00e9. La cl\u00e9 priv\u00e9e a \u00e9t\u00e9 plac\u00e9e dans un fichier chiffr\u00e9, dont le chiffrement a utilis\u00e9 un mot de passe simple de 4 caract\u00e8res, facilement devinable par m\u00e9thode de brute force. <\/p>\n
La cl\u00e9 de la plateforme est utilis\u00e9e comme racine de confiance pour attester la base de donn\u00e9es des cl\u00e9s pour le Secure Boot. L'obtention de la partie secr\u00e8te de la cl\u00e9 de la plateforme compromet toute la cha\u00eene de confiance impliqu\u00e9e dans la validation des composants du syst\u00e8me au d\u00e9marrage \u2013 conna\u00eetre la cl\u00e9 de la plateforme permet de contourner la protection Secure Boot et d'organiser un remplacement lors du d\u00e9marrage avec des composants personnalis\u00e9s via la manipulation de la cl\u00e9 KEK (Key Exchange Key) et des bases de donn\u00e9es \u00ab db \u00bb (Signature Database) et \u00ab dbx \u00bb (Forbidden Signature Database). KEK est responsable de l'\u00e9tablissement de la cha\u00eene de confiance entre le firmware et le syst\u00e8me d'exploitation, \u00ab db \u00bb contient des certificats et des signatures pour le chargeur et les composants tiers UEFI, tandis que \u00ab dbx \u00bb inclut les signatures r\u00e9voqu\u00e9es de composants malveillants connus. <\/p>\n
Pour ex\u00e9cuter une attaque, il suffit de g\u00e9n\u00e9rer de nouvelles cl\u00e9s et certificats pour KEK et db, puis d'utiliser la cl\u00e9 de plateforme de test devenue publique pour charger le certificat KEK cr\u00e9\u00e9 dans le firmware UEFI. Apr\u00e8s avoir charg\u00e9 le certificat KEK dans le firmware, on peut utiliser la cl\u00e9 secr\u00e8te associ\u00e9e pour charger un nouveau certificat dans la base de donn\u00e9es db. Une fois le certificat db charg\u00e9, la cl\u00e9 secr\u00e8te associ\u00e9e peut \u00eatre utilis\u00e9e pour attester les composants EFI charg\u00e9s. openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj '\/CN=BRLY KEK\/' -out KEK.crt openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj '\/CN=BRLY db\/' -out db.crt efi-updatevar -a -c KEK.crt -k PK.key KEK efi-updatevar -a -c db.crt -k KEK.key db sbsign --key db.key --cert db.crt --output rogue.efi.signed rogue.efi <\/p>\n
Pour v\u00e9rifier la validit\u00e9 de la cl\u00e9 de la plateforme, il suffit d'ex\u00e9cuter l'utilitaire \u00ab efi-readvar -v PK \u00bb du paquet efitools et de s'assurer que la cl\u00e9 de la plateforme n'est pas un certificat de test : efi-readvar -v PK Variable PK, longueur 862 PK : Liste 0, type X509 Signature 0, taille 834, propri\u00e9taire 26dc4851-195f-4ae1-9a19-fbf883bbb35e Sujet : CN=NE PAS FAIRE CONFIANCE \u2013 AMI Test PK \u00c9metteur : CN=NE PAS FAIRE CONFIANCE \u2013 AMI Test PK
![\"Lire](\"https:\/\/img.youtube.com\/vi\/CveWt3gFQTE\/hqdefault.jpg\")
\r\n