Contexte de Secure Boot

Secure Boot repose sur une chaîne de confiance stockée dans le firmware UEFI. La plupart des BIOS modernes intègrent le certificat Microsoft Corporation UEFI CA 2011, qui signe les chargeurs de démarrage autorisés. Lors du démarrage, le firmware vérifie la signature du fichier EFI ; si la signature correspond à un certificat présent dans la base de données, le chargeur est exécuté, sinon le processus s’arrête. Cette vérification vise principalement à empêcher l’injection de EFI malware persistant, pas à protéger contre un accès physique au système.

Mécanisme du shim et de l’enrôlement MOK

Le shim est un petit chargeur signé par Microsoft qui agit comme intermédiaire entre le firmware et le chargeur de distribution Linux (GRUB). Si le shim détecte une signature de chargeur non reconnue, il lance le module MOK (Machine Owner Key) qui permet à l’utilisateur d’enregistrer une clé publique supplémentaire dans le firmware. Cette étape nécessite d’accéder à l’utilitaire mokutil ou à l’interface de configuration du BIOS, mais aucune restriction technique n’empêche l’enregistrement d’une clé contrôlée par l’attaquant.

Exploitation avec un shim Microsoft signé

L’auteur du blog montre qu’il suffit de récupérer le paquet shim‑signed depuis un dépôt Linux, puis de vérifier qu’il porte bien la signature Microsoft avec la commande :

sbverify --list your_shim_file.efi

Le résultat affiche le certificat Microsoft, confirmant la validité du shim. L’étape suivante consiste à créer une paire de clés propriétaire :

openssl req -newkey rsa:4096 -nodes -keyout "./MOK.key" -new -x509 -sha256 -days 3650 -subj "/CN=attacker/" -out "./MOK.crt"

Après avoir monté la partition EFI (mount /dev/sdX1 /mnt/efi), l’attaquant copie le shim signé dans /mnt/efi/EFI/Boot/bootx64.efi, puis utilise l’utilitaire MOK pour inscrire MOK.crt comme clé de confiance. Au prochain redémarrage, le shim Microsoft signé charge le chargeur modifié (par exemple un GRUB contenant un payload) qui s’exécute avec les privilèges du firmware, contournant ainsi la protection initiale de Secure Boot.

Limites et contre‑mesures

Cette technique dépend de deux conditions essentielles : la présence du certificat Microsoft dans le firmware et la possibilité d’enrôler des clés via MOK. Les politiques d’entreprise qui désactivent l’accès à l’interface de gestion du firmware ou qui verrouillent la base de données de clés (Secure Boot en mode « Lockdown ») neutralisent l’attaque. De plus, la mise à jour du firmware avec une version qui supprime le certificat Microsoft ou qui impose la signature de chargeurs uniquement provenant du fabricant élimine le vecteur d’abus. Enfin, la surveillance des modifications de la partition EFI et la validation de l’intégrité du shim au démarrage permettent de détecter une substitution non autorisée.