Rootkits et micrologiciel : comment blinder l’UEFI et le démarrage de votre carte mère

Comprendre la menace silencieuse nichée au cœur de votre micrologiciel

Un virus classique s »installe généralement dans Windows, Linux ou les applications, puis s »appuie sur les mécanismes du système pour se lancer. Un bootkit UEFI agit plus bas, avant même que le noyau du système d »exploitation ne soit chargé. Cette position lui permet de préparer son exécution très tôt, de contourner certains outils de sécurité et de rester présent après une réinstallation complète du système.

Cette différence est essentielle pour choisir la bonne méthode de défense. Un formatage du disque dur efface les partitions et les fichiers accessibles au système, mais il ne répare pas une image de micrologiciel modifiée dans la mémoire SPI Flash de la carte mère. Une infection de ce type peut donc survivre à la suppression de Windows, au remplacement du disque ou à la restauration d »une sauvegarde logicielle. Cela ne signifie pas que toute panne de démarrage est un rootkit, mais qu »un diagnostic bas niveau devient nécessaire lorsque les symptômes persistent malgré une installation propre.

L »objectif consiste à sécuriser la plateforme sans improviser une manipulation risquée. Il faut vérifier la compatibilité du modèle de carte mère, confirmer le mode UEFI, contrôler le Secure Boot et le TPM, puis appliquer les mises à jour depuis les outils officiels. Procéder étape par étape permet de renforcer la chaîne de confiance tout en évitant les erreurs courantes, notamment la conversion prématurée d »un disque MBR ou l »interruption d »un flash firmware.

Anatomie d’une attaque sous le système avec les bootkits modernes

Les menaces de démarrage ne sont pas nouvelles. Les premiers logiciels malveillants visant le BIOS relevaient souvent de démonstrations expérimentales, mais l »évolution vers l »UEFI a fourni une architecture plus riche, composée de modules exécutés avant le système d »exploitation. Des familles telles que LoJax, MosaicRegressor et TrickBoot ont montré que des attaquants pouvaient exploiter le système d »exploitation pour recueillir des informations sur le firmware, désactiver certaines protections d »écriture, extraire une image SPI Flash, la modifier, puis la réinjecter dans la carte mère.

Le scénario est particulièrement préoccupant parce que l »implant peut charger un pilote DXE non signé ou intercepter un événement de transition tel que Ready-to-Boot. Il intervient alors avant le chargement complet de Windows ou de Linux. Un outil de sécurité fonctionnant dans le système peut détecter des comportements suspects, mais il ne dispose pas toujours des moyens nécessaires pour inspecter de manière fiable chaque module présent dans le firmware. La documentation de l »architecture UEFI aide à comprendre pourquoi cette couche précède le système d »exploitation et possède un rôle aussi déterminant.

La surface d »attaque du firmware est plus difficile à administrer que celle d »un système classique. Les protections dépendent du fabricant, de la génération de la carte mère, du microcode, du contrôleur SPI et des réglages de sécurité. Les exigences modernes concernant les images UEFI cherchent notamment à empêcher l »utilisation de zones mémoire à la fois exécutables et inscriptibles, à renforcer la protection NX et à limiter les pointeurs invalides. Le Secure Boot ne remplace donc pas une bonne hygiène de mise à jour, mais il constitue une barrière fondamentale contre l »exécution de composants non approuvés.

Les piliers matériels pour verrouiller le démarrage avec Secure Boot et TPM

La chaîne de confiance commence par une racine de confiance, c »est-à-dire un composant ou une clé considérée comme fiable dès les premières étapes du démarrage. Le firmware vérifie ensuite cryptographiquement le chargeur, qui vérifie à son tour les composants suivants. Si une signature est absente, invalide ou révoquée, l »exécution peut être bloquée avant que le code hostile n »atteigne le système d »exploitation.

Secure Boot s »appuie notamment sur plusieurs bases de données de clés. La plateforme conserve les clés de plateforme, les KEK, la base db des signatures autorisées et la base dbx des signatures ou composants révoqués. La base dbx est particulièrement importante, car elle permet de neutraliser un chargeur pourtant signé lorsqu »une vulnérabilité est découverte. Il faut cependant éviter de supprimer les clés par défaut sans raison précise, car une configuration incomplète peut rendre Windows ou Linux non amorçable.

• Secure Boot vérifie l »authenticité des chargeurs et des composants autorisés.
• TPM 2.0 stocke des secrets et enregistre des mesures d »intégrité dans des registres PCR.
• Measured Boot mesure les étapes du démarrage afin qu »un logiciel autorisé puisse détecter une modification.
• Protection du firmware limite les écritures non autorisées dans la mémoire SPI Flash.

Le TPM 2.0 ne remplace pas Secure Boot. Il complète la chaîne en enregistrant des mesures cryptographiques des différentes étapes du démarrage dans les PCR, ou Platform Configuration Registers. Ces informations peuvent être utilisées par BitLocker, un service d »attestation ou certaines solutions anti-triche afin de vérifier que la plateforme correspond à l »état attendu. Des jeux récents exigent ces fonctions pour réduire la triche bas niveau, mais leur intérêt dépasse largement le jeu vidéo. Une modification du mode UEFI, du TPM ou des clés peut toutefois provoquer une demande de récupération BitLocker, ce qui impose de sauvegarder la clé de récupération avant toute intervention.

Vérifier l’état de sécurité de votre plateforme sans entrer dans le BIOS

Windows fournit plusieurs contrôles natifs qui permettent de vérifier la configuration avant de modifier le firmware. Appuyez sur la touche Windows, saisissez msinfo32, puis ouvrez Informations système. Les lignes  » Mode BIOS  » et  » État du démarrage sécurisé  » doivent être examinées ensemble. Le mode BIOS doit indiquer UEFI et le démarrage sécurisé doit apparaître comme activé. Si le mode indique Legacy, n »activez pas directement Secure Boot dans l »UEFI.

Le point de vigilance principal concerne le partitionnement du disque système. Un démarrage UEFI standard attend généralement un disque GPT, tandis qu »une installation ancienne en mode Legacy utilise souvent MBR. Le guide officiel de Riot rappelle qu »une conversion MBR vers GPT, réalisée avec l »outil mbr2gpt, doit être précédée d »une sauvegarde et d »une vérification de compatibilité. Une modification directe du mode de démarrage peut empêcher Windows de se lancer, même si le matériel fonctionne correctement.

• Dans msinfo32, vérifier le mode BIOS et l »état du Secure Boot.
• Dans tpm.msc, confirmer que le TPM est prêt à être utilisé.
• Contrôler la version de spécification, qui doit être 2.0 lorsque cette exigence est demandée.
• Identifier le disque système et vérifier s »il utilise GPT ou MBR.
• Sauvegarder les données et la clé de récupération BitLocker avant toute modification.

La console tpm.msc permet de contrôler l »état du module et sa version de spécification. Un TPM absent, désactivé ou non initialisé peut nécessiter l »activation d »un réglage nommé Intel PTT, AMD fTPM ou TPM Security selon la plateforme. Les intitulés varient fortement d »un fabricant à l »autre. En cas d »option grisée, de certificat manquant ou d »erreur persistante, il est préférable de consulter la documentation du modèle concerné plutôt que de restaurer des clés au hasard.

Guide méthodologique pour flasher son micrologiciel en toute sérénité

Une mise à jour UEFI corrige parfois des vulnérabilités critiques, améliore la compatibilité matérielle ou ajoute les certificats nécessaires à une chaîne Secure Boot récente. Elle reste toutefois une opération sensible. Le fichier doit correspondre exactement au modèle et à la révision de la carte mère. Un firmware destiné à une variante proche, mais différente, peut rendre la machine inutilisable. Consultez donc la page de support officielle du fabricant et lisez les notes de version avant de télécharger quoi que ce soit.

Les recommandations du NIST SP 800-147 insistent sur l »authenticité et l »intégrité des mises à jour de firmware. Dans la pratique, cela signifie utiliser une image fournie par le fabricant, vérifier sa signature ou son empreinte lorsque cette information est disponible, et ne jamais employer un fichier provenant d »un forum non vérifié. Une clé USB simple, formatée en FAT32, est généralement préférable à un support contenant plusieurs partitions ou des utilitaires tiers.

1. Préparer la machine. Sauvegardez les fichiers importants, exportez ou notez la clé de récupération BitLocker, rétablissez une alimentation stable et évitez toute mise à jour pendant un orage ou sur une multiprise douteuse. Ne lancez pas l »opération avec une batterie presque vide sur un portable.
2. Vérifier le modèle. Relevez le modèle exact, la révision de la carte et la version actuelle du firmware. Téléchargez uniquement la version adaptée depuis le site officiel. Décompressez le fichier si le fabricant le demande, puis copiez-le à la racine d »une clé FAT32.
3. Utiliser l »outil embarqué. Redémarrez vers l »UEFI et ouvrez l »utilitaire correspondant à la marque, comme Q-Flash, EZ Flash ou M-Flash. Sélectionnez le fichier validé, relisez les informations affichées et confirmez seulement si le modèle correspond.
4. Ne rien interrompre. Pendant l »écriture, n »éteignez pas l »ordinateur, ne retirez pas la clé USB et n »appuyez pas sur le bouton de réinitialisation. Plusieurs redémarrages peuvent être normaux. L »écran peut rester noir temporairement pendant la réinitialisation de la mémoire d »entraînement.
5. Contrôler après redémarrage. Retournez dans l »UEFI, vérifiez la version installée, le mode UEFI, le TPM et Secure Boot. Contrôlez ensuite Windows avec msinfo32 et tpm.msc, puis réactivez les réglages personnalisés uniquement après avoir confirmé que le système démarre normalement.

Les protections modernes du firmware incluent aussi des mécanismes de validation des images et des mitigations mémoire. Les exigences récentes de Microsoft pour certains modules UEFI imposent notamment un alignement mémoire approprié, l »absence de sections combinant écriture et exécution, ainsi que des règles destinées à empêcher l »exécution depuis la pile ou l »utilisation de plages mémoire invalides. Ces contraintes expliquent pourquoi une ancienne image ou un module tiers peut devenir incompatible après une mise à jour de sécurité.

Sur Linux, les mises à jour peuvent passer par fwupd, mais les certificats de démarrage doivent rester cohérents avec les chargeurs utilisés. L »ajout d »un certificat récent, comme une autorité UEFI Microsoft 2023, doit préserver les certificats existants nécessaires au démarrage. Une mise à jour hors ligne peut être requise dans certains environnements. Pour une machine critique, vérifiez la documentation de la distribution, conservez un moyen de récupération et évitez de mélanger une procédure fabricant avec un outil générique non documenté.

Adoptez les bons réflexes pour une forteresse numérique durable

La sécurité du démarrage repose moins sur une option isolée que sur une routine de vérification. Conservez un mot de passe administrateur UEFI suffisamment robuste, limitez l »accès physique à la machine et évitez de laisser un démarrage externe prioritaire lorsque ce réglage n »est pas nécessaire. Surveillez les alertes de sécurité du fabricant, de Microsoft ou de votre distribution, car une mise à jour peut concerner le firmware, le microcode, les clés de démarrage ou les chargeurs approuvés.

• Maintenir le firmware à jour avec une version officielle et adaptée au modèle.
• Laisser Secure Boot activé lorsque le système et les outils utilisés le prennent en charge.
• Conserver le TPM 2.0 activé et protéger les clés de récupération.
• Ne pas supprimer les certificats par défaut sans procédure documentée.
• Vérifier régulièrement la base des certificats révoqués et appliquer les mises à jour dbx proposées par le système.
• Documenter chaque modification de l »UEFI afin de faciliter le dépannage.

Les certificats révoqués sont un élément vivant de la défense. Une chaîne de démarrage parfaitement signée peut rester vulnérable si elle autorise encore un ancien chargeur compromis. À l »inverse, une révocation appliquée trop tôt ou sans vérifier la compatibilité peut provoquer un échec de démarrage. La solution la plus sûre consiste à appliquer les mises à jour proposées par les canaux officiels, à vérifier la version du firmware et à conserver une sauvegarde avant chaque opération sensible. En faisant de ces contrôles un réflexe lors de chaque maintenance PC, la protection bas niveau devient une mesure préventive concrète plutôt qu »une intervention d »urgence après compromission.