Un clé de test permettant de contourner le UEFI Secure Boot a été découverte dans 806 modèles de cartes mères.

Les chercheurs en sécurité de l'entreprise Binarly ont identifié une possibilité de contournement du mode de vérification de démarrage UEFI Secure Boot sur plus de 800 produits fabriqués par Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo et Supermicro. Le problème a été surnommé PKfail et est lié à l'utilisation dans les firmwares d'une clé de plateforme (PK, Platform Key) non fiable, générée par AMI (American Megatrends International) et fournie comme un échantillon de test. Les firmwares les plus anciens utilisant cette clé de test ont été publiés en 2012, tandis que les plus récents sont datés de juin 2024. Selon les chercheurs, plus de 10 % de tous les firmwares vérifiés sont concernés par ce problème.

Dans les paramètres de la clé, il était indiqué qu'elle n'était pas fiable et ne devait pas être fournie dans ses produits. Il était prévu que cette clé de test soit remplacée par une clé propre, mais les fabricants n'ont pas tenu compte de l'avertissement et ont utilisé dans les firmwares finaux une clé générique standard, envoyée à tous les partenaires et clients d'AMI.

La partie privée de la clé de test AMI, nécessaire à la création de signatures numériques, a été rendue accessible au public après une fuite d'informations chez l'un des fabricants de matériel, dont un employé a par erreur publié dans un dépôt public sur GitHub un code contenant cette clé. La clé privée a été placée dans un fichier chiffré, dont le chiffrement a utilisé un mot de passe simple de 4 caractères, facilement devinable par méthode de brute force.

La clé de plateforme est utilisée comme racine de confiance pour certifier les bases de données de clés pour Secure Boot. L'acquisition de la partie privée de la clé de plateforme compromet toute la chaîne de confiance impliquée dans la vérification de la validité des composants du système de démarrage - en connaissant la clé de plateforme, il est possible de contourner la protection Secure Boot et de substituer ses propres composants lors du démarrage via la manipulation de la clé KEK (Key Exchange Key) et des bases de données "db" (Signature Database) et "dbx" (Forbidden Signature Database). La KEK est responsable de l'établissement de la chaîne de confiance entre le firmware et le système d'exploitation, la "db" contient les certificats et signatures pour le chargeur de démarrage et les composants UEFI tiers, tandis que la "dbx" inclut les signatures révoquées de composants malveillants connus.

Pour mener une attaque, il suffit de générer de nouvelles clés et certificats pour KEK et db, puis d'utiliser la clé de test de la plateforme, rendue publique, pour charger le certificat KEK créé dans le firmware UEFI. Une fois le certificat KEK chargé dans le firmware, on peut utiliser la clé privée associée pour charger dans la base de données db le nouveau certificat. Après le chargement du certificat db, la clé privée qui lui est associée peut être utilisée pour signer les composants EFI chargés. 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

Pour vérifier la validité de la clé de la plateforme, il suffit de lancer l'utilitaire « efi-readvar -v PK » du paquet efitools et de s'assurer que la clé de la plateforme n'est pas un test : efi-readvar -v PK Variable PK, length 862 PK: List 0, type X509 Signature 0, size 834, owner 26dc4851-195f-4ae1-9a19-fbf883bbb35e Subject: CN=DO NOT TRUST — AMI Test PK Issuer: CN=DO NOT TRUST — AMI Test PK

Source : opennet.ru