Des applications de confiance introduisent une faille dans le processus de démarrage UEFI

Sept programmes de récupération système contenaient une vulnérabilité équivalente à une porte dérobée, permettant d’injecter des fichiers non vérifiés dans le processus de démarrage des appareils utilisant l’interface UEFI (Unified Extensible Firmware Interface).

Cette faille, identifiée dans des logiciels de récupération en temps réel, pourrait être exploitée par des attaquants disposant de privilèges administratifs pour introduire des logiciels malveillants directement dans le processus de démarrage des systèmes UEFI. Les produits concernés incluent Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery, Sanfong EZ-back System, WASAY eRecoveryRX, CES NeoImpact et SignalComputer HDD King. Tous utilisent un fichier EFI signé par Microsoft, nommé "reloader.efi", qui est au cœur du problème.

Selon un rapport récent d’ESET, reloader.efi utilise un chargeur personnalisé permettant de charger des binaires non signés pendant le processus de démarrage. Cela équivaut à une porte dérobée contournant les protections d’UEFI Secure Boot. La vulnérabilité, référencée sous le code CVE-2024-7344, a reçu un score de 6,5 sur l’échelle CVSS (Common Vulnerability Scoring System), ce qui la classe comme une menace de gravité moyenne, car son exploitation nécessite des privilèges administratifs.

Une porte dérobée dans le démarrage UEFI

Normalement, le chargement et l’exécution des images UEFI en mémoire système se font via les fonctions standard LoadImage et StartImage. Cependant, reloader.efi contourne ce processus en utilisant un mécanisme personnalisé qui lui permet de charger n’importe quel binaire, qu’il soit de confiance ou non, au démarrage.

Martin Smolár, chercheur en malware chez ESET, suppose que les développeurs ont peut-être implémenté ce chargeur personnalisé par commodité ou par manque de sensibilisation aux bonnes pratiques de codage sécurisé. "Cela leur évite de devoir soumettre chaque mise à jour à Microsoft pour une nouvelle signature", explique-t-il. Reloader.efi charge des binaires arbitraires à partir d’un fichier chiffré nommé "cloak.dat". Après décryptage, ESET a découvert que ce fichier contenait un exécutable non signé, conçu principalement pour des environnements éducatifs.

"Son rôle principal est de permettre une récupération en temps réel du système, garantissant que les étudiants de différentes classes peuvent travailler dans un environnement informatique prédéfini par l’enseignant dans des salles informatiques partagées", précise Smolár. Cependant, ce composant pourrait également être utilisé dans d’autres contextes, comme les cybercafés. Le problème est que cet exécutable non signé est exécuté pendant le démarrage, contournant complètement les vérifications d’UEFI Secure Boot.

Bien que ce logiciel de récupération soit légitime, un attaquant pourrait facilement le remplacer par un fichier malveillant. Avec des privilèges administratifs, un attaquant pourrait accéder à la partition système EFI (ESP) et substituer son propre fichier malveillant à cloak.dat. Un simple redémarrage suffirait alors pour injecter n’importe quel logiciel malveillant dans le processus de démarrage.

Pourquoi les failles UEFI sont si critiques

L’UEFI représente une couche critique du système, servant de pont entre le micrologiciel et le système d’exploitation. Toute intrusion à ce niveau confère au malware une persistance redoutable, lui permettant de survivre aux redémarrages et de s’exécuter avant même les mécanismes de sécurité du système.

Les programmes de sécurité ont du mal à détecter les malwares opérant à un niveau aussi bas. De plus, en s’exécutant en premier, un malware UEFI peut contourner les vérifications de sécurité qu’il cherche à éviter. Les auteurs de malwares exploitent cette vulnérabilité en concevant des bootkits UEFI capables de compromettre des mécanismes de sécurité critiques comme UEFI Secure Boot ou HVCI (Hypervisor-Protected Code Integrity), une technologie Windows visant à bloquer l’exécution de code non signé dans le noyau.

Pour prévenir de telles attaques, le gestionnaire de démarrage UEFI vérifie chaque binaire d’application de démarrage par rapport à deux listes : "db", qui contient les programmes signés et de confiance, et "dbx", qui répertorie les programmes interdits. Cependant, lorsqu’un binaire vulnérable est signé par Microsoft, ces vérifications deviennent inefficaces.

Un processus de signature opaqueSous titre

Microsoft impose une liste d’exigences pour signer les binaires UEFI, mais le processus reste peu transparent. "Je ne sais pas si cela se limite à une vérification automatisée des exigences ou si cela inclut des examens manuels pour détecter des comportements potentiellement dangereux", explique Smolár. Microsoft a déjà mentionné que certains binaires UEFI sont "approuvés après un examen manuel", mais les détails restent flous.

ESET a découvert la vulnérabilité CVE-2024-7344 en juillet 2024. Depuis, toutes les applications concernées ont été corrigées, et Microsoft a révoqué les binaires vulnérables lors de sa mise à jour de sécurité du 14 janvier 2025.