BlackLotus, ce malware qui met Secure Boot K.-O.
Publié par Clément Bohic le | Mis à jour le
ESET attire l'attention sur BlackLotus, un malware capable de contourner Secure Boot. Comment fonctionne-t-il ?
Contourner Secure Boot, y compris sur des systèmes Windows disposant des derniers correctifs ? Il y a un malware pour ça. On l'a appelé BlackLotus.
La vulnérabilité qu'il exploite (CVE-2022-21894) est colmatée depuis plus d'un an. Mais elle reste utilisable, parce que certains fichiers problématiques n'ont pas été révoqués (= placés sur la liste noire de Secure Boot). En l'occurrence, des bootloaders.
Au début de la chaîne d'attaque, il y a plusieurs types d'installeurs dont le vecteur de diffusion est inconnu. Certains embarquent les bootloaders vulnérables. D'autres les récupèrent sur les serveurs de Microsoft.
Si nécessaire, l'installeur obtient les privilèges admin en contournant le contrôle de compte d'utilisateur par l'intermédiaire de l'assistant de compatibilité des programmes. Il effectue alors une première opération au sein de l'ESP (partition système EFI) : renommer le gestionnaire de démarrage Windows bootmgfw.efi en winload.efi. Le fichier sera ultérieurement utilisé pour lancer l'OS ou restaurer la séquence de démarrage d'origine avant désinstallation du malware.
Comment BlackLotus squatte la partition EFI
L'installeur dépose ensuite plusieurs éléments dans l'ESP, au sein du dossier /EFI/Microsoft/Boot. Dont :
grubx64.efi (le bootkit)
bootload.efi (un shim légitime, signé par Microsoft, mais vulnérable)
bootmgfw.efi (gestionnaire de démarrage là aussi légitime, mais vulnérable)
BCD (base de paramètres pour les bootloaders)
BCDR (backup du BCD d'origine)
L'installeur crée aussi un dossier \system32 sur l'ESP. Il y place :
hvloader.efi (chargeur Hyper-V légitime mais vulnérable)
bootmgr.efi (autre gestionnaire de démarrage)
mcupdate_AuthenticAMD.dll (exécutable portable autosigné, exécuté par hvloader.efi après exploitation sur les CPU AMD)
mcupdate_GenuineIntel.dll (idem sur les CPU Intel)
Interviennent ensuite la désactivation de HVCI (protection contre le code non signé) et de BitLocker (chiffrement du disque). Respectivement en mettant à zéro une valeur de registre et le paramètre DisableCount de la méthode DisableKeyProtectors.
Une variable pour « casser » Secure Boot
Un PoC pour la faille CVE-2022-21894 est public depuis août 2022. Les concepteurs de BlackLotus semblent s'en être très largement inspirés. Y compris pour mettre en place une persistance. Dans les grandes lignes, le processus se déroule comme suit :
- L'installeur relance la machine. Le firmware charge alors la première option d'amorçage. Sur les systèmes Windows, il s'agit, par défaut, de bootmgfw.efi.
- S'exécute donc ici la version vulnérable de bootmgfw.efi. Elle charge les paramètres du BCD que l'installeur a déployé. La séquence de démarrage bascule alors vers le bootmgfw.efi placé dans le dossier \system32 de l'ESP.
- Ce dernier charge hvloader.efi et, surtout, diverses options qui se trouvent dans son propre BCD. Dont une, cruciale, qui permet de « casser » Secure Boot. Elle empêche en fait le chargement d'une stratégie en mémoire. Pour cela, elle bloque les adresses supérieures à 0x1000000 ; c'est-à-dire toutes celles où cette politique est autorisée à se placer.
- C'est la porte ouverte à l'activation/désactivation de paramètres qui contrôlent, par exemple, la vérification d'intégrité ou l'exécution de pilotes non signés.
- Dans ce contexte, hvloader.efi peut exécuter l'une des deux DLL susmentionnées. Et qui, elles-mêmes, exécutent le dernier maillon de la chaîne : une application définissant le shim comme méthode de démarrage par défaut.
Un shim... puis BlackLotus
Ce shim, signé par Microsoft, est conçu pour exécuter des bootloaders dont il a vérifié l'intégrité, soit à partir de sa liste de clés (autorisées / révoquées), soit à partir d'une base externe. Cette base (la « liste MOK », pour Machine Owner Key) n'est accessible qu'au démarrage, dans une variable NVRAM.
La vulnérabilité permet d'injecter des clés arbitraires dans cette liste. Et ainsi de faire en sorte que le shim exécute BlackLotus. Le bootkit crée d'abord une variable NVRAM destinée à désactiver les fonctionnalités VBS (sécurité basée sur la virtualisation). Parmi elles, HVCI et Credential Guard. Pour passer encore plus inaperçu, il intercepte certaines commandes de démarrage et tente de désactiver Defender.
BlackLotus installe deux composantes. D'un côté, un pilote kernel. Celui-ci sert notamment à empêcher la suppression des fichiers déposés sur l'ESP. Surtout, il déploie un downloader HTTP et l'injecte dans le processus winlogon.exe. C'est lui communique avec le serveur de commande et de contrôle, par messages chiffrés.
Photo d'illustration © artbase - Adobe Stock