Secure Boot suffit-il à arrêter BlackLotus ?

Pas à lui seul. BlackLotus exploite un ancien gestionnaire de démarrage Windows, valablement signé, auquel Secure Boot fait toujours confiance. Appliquer les correctifs remplace le gestionnaire de démarrage sur le disque, mais n'empêche pas un attaquant d'apporter l'ancien, vulnérable. La solution est la révocation : ajouter l'ancien certificat de signature à la DBX pour que le micrologiciel refuse les gestionnaires de démarrage signés avec lui, une fois que l'appareil est passé à un gestionnaire de démarrage signé par la Windows UEFI CA 2023.

Que se passe-t-il quand les certificats Secure Boot Microsoft de 2011 expirent ?

Les appareils continuent de démarrer : le micrologiciel UEFI ne vérifie généralement pas l'expiration des certificats lorsqu'il valide les composants de démarrage. Le problème est la maintenance : après l'expiration, Microsoft ne peut plus signer de nouveaux gestionnaires de démarrage ni de mises à jour DB et DBX avec les anciens certificats, et les appareils qui n'ont jamais reçu les certificats 2023 ne reçoivent plus les correctifs de sécurité de la chaîne de démarrage. Faire passer chaque appareil aux certificats KEK et DB 2023 est ce qui le garde maintenable.

Les mises à jour Secure Boot déclenchent-elles la récupération BitLocker ?

En général non, lorsque Windows les applique et que BitLocker utilise la liaison au PCR 7, car Windows anticipe le changement et rescelle la clé. La récupération peut survenir sur les appareils dont le profil PCR n'inclut pas le PCR 7, sur certains micrologiciels, ou quand les modifications sont faites en dehors de Windows. Assurez-vous que chaque clé de récupération est déposée et testez chaque modèle matériel dans un anneau pilote avant un déploiement large.

Secure Boot, UEFI et les atténuations BlackLotus

Tout ce que fait Windows pour se protéger, de BitLocker à Credential Guard, suppose que le code exécuté avant Windows était digne de confiance. Secure Boot impose cette hypothèse : le micrologiciel UEFI n'exécute que les composants de démarrage signés par des clés présentes dans sa base de signatures. Des bootkits comme BlackLotus ont montré que « Secure Boot est activé » ne signifie pas « la chaîne de démarrage est sûre », et les certificats Microsoft qui ancrent tout le système sont en cours de remplacement.

Le guide pilier sur le durcissement de BitLocker vérifie que Secure Boot est activé. Ce guide va plus loin : les bases de clés, les atténuations de CVE-2023-24932, la transition vers les certificats 2023 et le durcissement du micrologiciel. Il fait partie de la série BitLocker & sécurité du démarrage.

Comment Secure Boot décide de ce qui s'exécute

Variable	Contenu	Qui la met à jour
PK (Platform Key)	La clé de l'OEM ; propriétaire de la plateforme	Micrologiciel de l'OEM
KEK (Key Exchange Key)	Clés autorisées à mettre à jour DB et DBX, dont la KEK de Microsoft	L'OEM, ou des mises à jour signées par la PK
DB (signatures autorisées)	Certificats et empreintes du code de démarrage de confiance : Windows CA de Microsoft, UEFI CA tierce de Microsoft	Mises à jour signées par une KEK
DBX (signatures interdites)	Certificats révoqués et empreintes de code de démarrage connu comme vulnérable	Mises à jour signées par une KEK

Le micrologiciel n'exécute un composant de démarrage que si sa signature remonte à DB et qu'il ne figure pas dans DBX. Les gestionnaires de démarrage Windows sont signés par Microsoft Windows Production PCA 2011 ; les shims Linux et de nombreuses ROM optionnelles remontent à Microsoft Corporation UEFI CA 2011 ; les mises à jour DB et DBX de Microsoft sont signées avec Microsoft Corporation KEK CA 2011.

Pourquoi BlackLotus a changé la donne

BlackLotus (CVE-2022-21894, suivie de CVE-2023-24932) abuse d'un gestionnaire de démarrage ancien mais valablement signé par le certificat PCA 2011. Secure Boot l'exécute sans broncher, et l'attaquant exploite sa vulnérabilité pour désactiver les protections et charger un bootkit non signé qui persiste sous le système d'exploitation, même avec BitLocker.

Les correctifs Windows remplacent le gestionnaire de démarrage sur la partition système EFI, mais un attaquant disposant de droits d'administrateur peut y recopier l'ancien, vulnérable. La seule correction durable consiste à retirer la confiance au certificat PCA 2011 dans la DBX, ce qui exige d'abord que chaque appareil démarre avec un gestionnaire de démarrage signé par la nouvelle Windows UEFI CA 2023. Cet ordre imposé, ajouté au risque de rendre des supports de démarrage inutilisables, explique pourquoi Microsoft a rendu les atténuations facultatives (opt-in) et progressives.

Étape 1 : inventorier l'état actuel

Sur chaque appareil :

PowerShell

Confirm-SecureBootUEFI                         # True = enabled; error = legacy BIOS/CSM boot
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes) -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name KEK).Bytes) -match 'KEK 2K CA 2023'

Collectez ces informations avec un script de conformité, avec le modèle et la version du micrologiciel (Get-CimInstance Win32_ComputerSystem, Get-CimInstance Win32_BIOS). Les appareils qui démarrent encore en mode BIOS hérité ou CSM doivent d'abord être convertis : mbr2gpt.exe /validate /allowFullOS puis /convert, avant de passer le micrologiciel en UEFI seul et d'activer Secure Boot.

Les stratégies de conformité Intune peuvent exiger Secure Boot via Device Health > Require Secure Boot to be enabled on the device, qui repose sur l'attestation du journal de démarrage mesuré plutôt que sur le résultat d'un script.

Étape 2 : appliquer les atténuations de CVE-2023-24932

Microsoft documente la procédure complète dans KB5025885 (« How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 »). Lisez la version actuelle avant de commencer ; le calendrier d'application a changé plusieurs fois. Le mécanisme est une valeur de registre qui indique à Windows quelles étapes de maintenance Secure Boot effectuer aux prochains redémarrages :

Text

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Secureboot
Value: AvailableUpdates  (REG_DWORD)

Au moment de la rédaction, les étapes documentées sont :

Étape	AvailableUpdates	Effet	Événement de confirmation (journal Système, source TPM-WMI)
1	`0x5944`	Déployer les certificats Secure Boot 2023 (Windows UEFI CA 2023 dans DB, plus la KEK 2023 et les CA tierces le cas échéant) et le gestionnaire de démarrage signé par Windows UEFI CA 2023	1036 (DB mise à jour)
2	(aucune : vérifier)	Confirmer que `UEFICA2023Status` sous `...\Secureboot\Servicing` vaut `Updated` et que le gestionnaire de démarrage signé 2023 est en place	1799
3	`0x80`	Ajouter Windows Production PCA 2011 à la DBX (la révocation)	1037
4	`0x200`	Appliquer la mise à jour du Secure Version Number (SVN) au micrologiciel	1042

Windows efface chaque bit une fois traité ; la tâche de maintenance s'exécute toutes les 12 heures et certaines étapes nécessitent un ou deux redémarrages. Effectuez d'abord les étapes 1 et 2, largement. Ne passez aux étapes 3 et 4 que lorsque tous les supports de démarrage susceptibles de démarrer l'appareil ont été mis à jour (étape 4 ci-dessous), car après la révocation, tout ce qui n'est signé qu'avec PCA 2011 ne démarre plus. Les échecs apparaissent sous forme d'événements de la même source : 1795 (le micrologiciel a renvoyé une erreur, généralement corrigée par une mise à jour du micrologiciel de l'OEM), 1796 (erreur inattendue, avec le code d'erreur) et 1801 (les nouveaux certificats n'ont pas encore été appliqués au micrologiciel). L'événement 1808 confirme qu'un appareil dispose de tous les nouveaux certificats requis.

Étape 3 : passer aux certificats 2023

Les certificats 2011 expirent en 2026 : la KEK et l'UEFI CA tierce en juin, la Windows Production PCA en octobre. L'expiration n'empêche pas les appareils de démarrer, mais met fin à leur capacité à recevoir de nouvelles mises à jour Secure Boot DB/DBX et de nouveaux gestionnaires de démarrage signés sous l'ancienne chaîne.

L'état cible pour chaque appareil :

KEK : Microsoft Corporation KEK 2K CA 2023
DB : Windows UEFI CA 2023, plus Microsoft UEFI CA 2023 et Microsoft Option ROM UEFI CA 2023 là où du code tiers est approuvé
Gestionnaire de démarrage : signé par Windows UEFI CA 2023

Microsoft déploie ces mises à jour via la maintenance de Windows et documente plusieurs façons de les déployer délibérément :

Registre : AvailableUpdates = 0x5944 sous HKLM\SYSTEM\CurrentControlSet\Control\Secureboot déploie tous les certificats nécessaires et le gestionnaire de démarrage signé 2023. La progression est indiquée sous HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\Servicing : UEFICA2023Status passe de NotStarted à InProgress puis à Updated, et UEFICA2023Error est non nul en cas d'échec. MicrosoftUpdateManagedOptIn = 1 sous la clé Secureboot inscrit plutôt l'appareil au déploiement progressif contrôlé par Microsoft.
Stratégie de groupe : Computer Configuration > Administrative Templates > Windows Components > Secure Boot, notamment Enable Secure Boot Certificate Deployment.
Catalogue de paramètres Intune : Enable Secureboot Certificate Updates, Configure Microsoft Update Managed Opt In et Configure High Confidence Opt-Out.

Les options de stratégie exigent des mises à jour cumulatives récentes : consultez les recommandations actuelles de Microsoft sur la mise à jour des certificats Secure Boot pour connaître la build minimale de chaque version de Windows.

Les mises à jour de la KEK doivent être signées par la Platform Key de l'OEM : certains modèles ont donc besoin d'une mise à jour du micrologiciel avant que Windows puisse les appliquer. Suivez la progression par modèle, pas seulement par appareil.

Étape 4 : mettre à jour les supports de démarrage et les chemins de récupération

Avant toute révocation :

WinPE et PXE : reconstruisez les images de démarrage Configuration Manager et WDS à partir des médias actuels du Windows ADK, pour qu'elles embarquent le gestionnaire de démarrage signé 2023.
Clés USB d'installation et de récupération : recréez-les à partir des médias actuels. Microsoft publie des recommandations et des outils pour mettre à jour les supports amorçables.
Environnement de récupération Windows (WinRE) de chaque appareil : confirmez que WinRE a été mis à jour en même temps que le système.
Machines virtuelles : les VM Hyper-V de génération 2, VMware et cloud ont leur propre micrologiciel virtuel et leurs propres clés de modèle. Consultez les recommandations de l'éditeur de votre hyperviseur pour les mises à jour KEK et DB, et utilisez le modèle Secure Boot Microsoft Windows pour les invités Windows sur Hyper-V.

Étape 5 : durcir le micrologiciel lui-même

Secure Boot peut être désactivé dans la configuration du micrologiciel par toute personne ayant un accès physique, sauf si le micrologiciel est verrouillé :

Paramètre	Valeur
Mode de démarrage	UEFI uniquement ; CSM/hérité désactivé
Secure Boot	Activé, mode standard avec les clés d'usine (pas en mode configuration ni personnalisé)
Mot de passe administrateur du micrologiciel	Défini, unique par appareil ou par modèle, stocké dans votre coffre
Démarrage USB / réseau	Désactivé ou protégé par le mot de passe du micrologiciel là où il n'est pas nécessaire
UEFI CA tierce de Microsoft	Désactivée sur les appareils exclusivement Windows lorsque les ROM optionnelles le permettent (les PC Secured-core sont livrés ainsi)
Ports Thunderbolt / DMA externes	S'appuyer sur Kernel DMA Protection ; voir le guide VBS et DMA

Appliquez ces réglages avec les outils des OEM (les principaux constructeurs fournissent tous des utilitaires de configuration du BIOS en ligne de commande) ou, sur le matériel pris en charge et enregistré dans Windows Autopilot, avec les profils Intune Device Firmware Configuration Interface (DFCI), qui peuvent aussi verrouiller les paramètres du micrologiciel contre toute modification locale. Maintenez le micrologiciel à jour via Windows Update ou le canal de l'OEM : de nombreux correctifs Secure Boot arrivent sous forme de mises à jour du micrologiciel.

Ce qui casse

Les anciens supports de démarrage cessent de fonctionner après la révocation DBX : clés USB dans le tiroir du support, images PXE, supports de récupération de sauvegarde tiers.
Bogues de micrologiciel : certains modèles rejettent les mises à jour DB, KEK ou DBX, ou ne démarrent plus ensuite. Pilotez chaque modèle.
Les systèmes en double démarrage et Linux dépendent de l'UEFI CA tierce ; la désactiver ou révoquer des shims les affecte.
Demandes de récupération BitLocker sur les appareils sans liaison au PCR 7. Confirmez d'abord le dépôt des clés avec le guide sur les clés de récupération, et suspendez BitLocker pour un redémarrage (Suspend-BitLocker -MountPoint C: -RebootCount 1) autour des mises à jour du micrologiciel.
Les ROM optionnelles des cartes graphiques et contrôleurs de stockage additionnels peuvent nécessiter la CA tierce.

Vérifier

Confirm-SecureBootUEFI renvoie True sur chaque appareil.
DB contient Windows UEFI CA 2023, KEK contient Microsoft Corporation KEK 2K CA 2023 (commandes de l'étape 1).
Le journal Système affiche les événements de confirmation de chaque étape appliquée (1808 une fois tous les certificats en place), UEFICA2023Status vaut Updated, et AvailableUpdates ne contient plus les bits que vous avez positionnés (un 0x4000 résiduel est attendu après 0x5944).
Sur les appareils révoqués, un ancien support de démarrage signé PCA 2011 échoue avec une violation Secure Boot. Testez-le une fois par modèle en laboratoire, pas en production.
La conformité Intune indique Secure Boot comme sain ; les journaux de démarrage mesuré sous C:\Windows\Logs\MeasuredBoot sont présents pour l'attestation.

Liste de contrôle

Tous les appareils démarrent en mode UEFI avec Secure Boot activé en mode standard
Inventaire de l'état de DB, KEK et du gestionnaire de démarrage par appareil et par modèle
Windows UEFI CA 2023 dans DB et gestionnaire de démarrage signé 2023 installé partout
KEK 2023 déployée ; modèles nécessitant une mise à jour du micrologiciel identifiés et mis à jour
Supports de démarrage, images PXE, WinRE et modèles de VM mis à jour
Révocation de PCA 2011 et mise à jour SVN appliquées, anneau par anneau, après la mise à jour des supports
Mot de passe du micrologiciel défini, démarrage hérité et externe désactivés, paramètres verrouillés

Une chaîne de démarrage digne de confiance est le socle de Credential Guard et de l'intégrité de la mémoire. Consultez l'entrée du glossaire Secure Boot pour une définition plus courte à partager avec des non-spécialistes.