Contexte et découverte

En 2023, les chercheurs ont identifié le premier bootkit UEFI fonctionnant en conditions réelles, nommé BlackLotus. Ce logiciel malveillant a démontré la capacité de contourner Secure Boot sur des machines Windows 11 entièrement à jour, prouvant que la chaîne de confiance pouvait être compromise même après l’application de tous les correctifs publiés par Microsoft.

Mécanisme de la faille « Baton Drop »

BlackLotus et son successeur BlackX s’appuient sur la vulnérabilité désignée CVE‑2022‑21894, qualifiée de « Baton Drop ». Cette faiblesse réside dans le gestionnaire de démarrage Windows, stocké sur une partition dédiée et signé numériquement. Le défaut logique permet à un attaquant de substituer le gestionnaire de démarrage sans que la vérification de signature de Secure Boot ne le détecte, ouvrant ainsi la possibilité d’exécuter du code kernel‑mode avant le chargement complet du système d’exploitation. Dans certains scénarios, la même faille peut être exploitée pour extraire les clés de chiffrement BitLocker.

Chaîne de confiance et correctifs Microsoft

Microsoft a publié le correctif initial de la vulnérabilité en 2022, modifiant le code du gestionnaire de démarrage pour éliminer le point d’injection. En 2023, un nouveau certificat a été introduit afin d’exclure les gestionnaires de démarrage vulnérables de la liste de confiance. En 2024, la société a ajouté une procédure de révocation du certificat utilisé pour signer les anciennes versions du gestionnaire. Ces deux mises à jour ont été largement déployées, et les organisations étudiées avaient installer l’ensemble de ces correctifs avant l’apparition de BlackX.

Analyse des raisons d’infection malgré les correctifs

La persistance de l’infection suggère plusieurs scénarios techniques. Premièrement, la révocation du certificat ne s’est pas propagée de façon homogène : certains systèmes peuvent ne pas avoir reçu la mise à jour de la base de révocation ou l’avoir appliquée après le premier démarrage du bootkit. Deuxièmement, le processus de validation du certificat dans le firmware UEFI dépend de la version du microcode et de la configuration du BIOS/UEFI ; des implémentations plus anciennes peuvent ignorer les listes de révocation, maintenant ainsi la confiance dans un gestionnaire de démarrage déjà compromis. Troisièmement, la présence de copies résiduelles du gestionnaire de démarrage sur des partitions de récupération ou de secours peut permettre au bootkit de réinjecter le code malveillant même après la mise à jour du gestionnaire principal. Enfin, la capacité de BlackX à s’exécuter avant l’activation des protections logicielles (antivirus, EDR) signifie que les mécanismes de détection post‑boot sont inefficaces pour empêcher le chargement initial.

En l’absence de données publiques détaillant la distribution exacte des certificats révoqués, il reste difficile de quantifier la part de chaque facteur. Néanmoins, l’incident montre que la simple correction d’une vulnérabilité au niveau du code ne suffit pas à garantir la sécurité de la chaîne de confiance si les mécanismes de gestion des certificats ne sont pas uniformément appliqués à l’ensemble du matériel.