baton drop (CVE-2022-21894): vulnérabilité de contournement de la fonctionnalité de sécurité Secure Boot

Les applications de démarrage Windows permettent au paramètre truncatememory de supprimer de la carte mémoire les blocs de mémoire contenant des plages « persistantes » de données sérialisées, ce qui conduit à un contournement de Secure Boot.

• L'élément BCD truncatememory supprime de la carte mémoire toute la mémoire située au-dessus d'une adresse physique spécifiée.
• Cette opération est effectuée pour chaque application de démarrage pendant l'initialisation, avant que la stratégie Secure Boot sérialisée ne soit lue depuis la mémoire.
• Par conséquent, un tel élément peut être utilisé pour retirer de la carte mémoire la stratégie Secure Boot sérialisée.
• Cela permettra d'utiliser des paramètres dangereux dans une application de démarrage (bootdebug, testsigning, nointegritychecks), cassant ainsi Secure Boot.

Ce problème a été corrigé par deux changements distincts:

• Après avoir tenté de charger une stratégie Secure Boot sérialisée, si aucune stratégie n'a été chargée, et que Secure Boot est activé, et que l'application de démarrage n'a pas été chargée directement par le firmware UEFI, et que l'application de démarrage n'est pas bootmgr, l'initialisation de l'application de démarrage échoue.
• Lors du chargement d'une application de démarrage, si celle-ci possède une ressource VERSIONINFO contenant un OriginalFilename, et si ce nom de fichier figure dans une liste de blocage (contenant bootmgr.exe et hvloader.exe; dans Nickel, hvloader.efi a été ajouté mais cela n'a pas été rétroporté), le chargement échoue.
  • Sous Windows 8 et Windows 8.1, hvloader.exe n'est pas inclus dans la liste de blocage de winload - il l'était à l'origine, ce qui cassait le chargement d'Hyper-V!
  • Depuis Windows 10 version 1809, si un certain bit d'indicateur est défini (utilisé avec l'élément flightedbootmgr pour charger bootmgr depuis le disque), OriginalFilename doit obligatoirement être bootmgr.exe.

Exploitation

L'attaquant doit s'assurer que la stratégie Secure Boot sérialisée est allouée au-dessus d'une adresse physique connue.

• Par défaut, elle est allouée à l'adresse la plus basse possible.
• À l'origine, la stratégie Secure Boot sérialisée était allouée après son chargement, avant d'utiliser toute configuration chargée depuis le BCD.
  • Depuis RS1, la stratégie Secure Boot sérialisée est allouée lors du chargement d'une application de démarrage.
  • Depuis RS2, toute stratégie Secure Boot sérialisée existante est libérée lors de la sérialisation d'une stratégie Secure Boot.
• La stratégie Secure Boot sérialisée est réallouée si, lors du chargement d'une application de démarrage, le osdevice de l'entrée BCD est une partition chiffrée BitLocker dont le VMK a été dérivé à l'aide du TPM.
  • Cela peut être simulé en définissant le bit 0 des drapeaux de clé après un déscellage réussi du TPM; ce bit peut être défini manuellement dans les métadonnées BitLocker, avec des métadonnées supplémentaires ajoutées pour spécifier que Secure Boot est utilisé pour la validation d'intégrité.

L'élément avoidlowmemory peut être utilisé pour garantir que toutes les allocations de mémoire physique se situent au-dessus d'une adresse physique spécifiée:

• Depuis Windows 10, cet élément est interdit si VBS est activé, mais comme il est utilisé pendant l'initialisation de l'application de démarrage, avant que la stratégie Secure Boot sérialisée ne soit lue depuis la mémoire, le chargement de bootmgr et la spécification d'un chemin BCD personnalisé (via l'élément bcdfilepath alias custom:22000023) peuvent être utilisés pour contourner cette restriction.
• Si BitLocker est présent sur le volume du système d'exploitation, ou si le système cible exécute TH1 ou TH2, cette méthode échouera; il est donc également possible de lancer l'attaque une fois avec un bootmgr Windows 8.x pour désactiver VBS, puis de revenir au bootloader d'origine.
  • Windows 10 a modifié l'initialisation des applications de démarrage pour plafonner tous les PCR du TPM une fois, de sorte qu'un bootmgr Windows 8.x ne pourra pas desceller le VMK sur un système Windows 10+.

hvloader.efi peut être chargé avec l'élément nointegritychecks pour charger un mcupdate.dll auto-signé, dont le point d'entrée sera appelé avant ExitBootServices.

Alternativement, sur les systèmes non-AMD64, winload.efi antérieur à TH2 peut être utilisé avec l'élément testsigning; cela permet d'exécuter des binaires auto-signés dont le certificat contient l'EKU szOID_NT5_CRYPTO.

Sur les systèmes ARMv7, il sera nécessaire de charger un hal.dll auto-signé modifié avec un import vers mcupdate.dll pour obtenir l'exécution de code.

Sur les systèmes x86 et AMD64, le fichier chargé en tant que mcupdate.dll doit être nommé mcupdate_*.dll, où * est la chaîne de fabricant CPUID (GenuineIntel, AuthenticAMD, etc.).

Sur les systèmes ARM64, cette technique ne peut pas être utilisée car la première build de production signée disponible est un WinPE de RS2; par conséquent, seule une exécution de code filaire peut actuellement être effectuée (via bootdebug).

Fichiers inclus

Ce dépôt contient les fichiers suivants:

• Le code source d'une charge utile simple est fourni. Cette charge utile se contente d'attendre une interruption indéfiniment, car sans trouver de fonctions et de variables intéressantes dans l'application de démarrage appelante, il est impossible de faire quoi que ce soit d'autre.
  • Comme mcupdate.dll s'exécute à une adresse virtuelle avec la pagination activée, il est impossible d'appeler directement les fonctions EFI (la pagination doit être désactivée pour appeler les fonctions EFI; revenir à une adresse virtuelle avec la pagination désactivée ne mène à rien de bon).
  • Pour appeler des fonctions EFI, une charge utile devrait appeler BlImgLoadPEImageEx ou BlImgLoadPEImageFromSourceBuffer avec le bit 0 défini dans les drapeaux afin de charger une charge utile supplémentaire selon un mappage adresse physique-adresse virtuelle 1:1.
    • Alternativement, elle peut appeler BlImgAllocateImageBuffer avec le même bit défini pour allouer de la mémoire selon un mappage adresse physique-adresse virtuelle 1:1; puis charger elle-même une charge utile (ou s'y remapper).
• Une ISO qui exploite ce problème sur AMD64 en utilisant le bootmgfw de Windows 8 RTM et le hvloader de TH1 RTM.
  • La charge utile utilisée ici affiche un message à l'écran en utilisant une fonction de hvloader obtenue par décalage, puis boucle indéfiniment.
• Une ISO qui exploite ce problème sur AMD64 en utilisant bootmgr de RS1 et le de TH1 RTM.

Post-scriptum

Ce problème peut être utilisé pour extraire les clés BitLocker (lorsque Secure Boot est utilisé pour la validation d'intégrité).

• Bien que ce soit possible, la méthode exacte permettant d'obtenir l'exécution de code avec des clés BitLocker dérivées pour un volume arbitraire en mémoire ne sera pas divulguée.

Le correctif de ce problème a également corrigé un autre problème qui n'a pas de CVE.

• bootmgr ignore toute table de clés BitLocker déjà présente en mémoire et en alloue une nouvelle, sans effacer l'ancienne.
  • Par conséquent, un attaquant pourrait charger un bootmgr RS2+ depuis bootmgr (en spécifiant un osdevice arbitraire où Secure Boot est utilisé pour la validation d'intégrité), démarrer sur WinPE, charger un pilote vulnérable connu, et l'utiliser pour rechercher et extraire la table de clés BitLocker existante en mémoire physique.

Aucune application de démarrage vulnérable connue n'a encore été révoquée.

• Jusqu'à ce qu'une révocation ait lieu, un attaquant peut simplement apporter ses propres chargeurs de démarrage vulnérables.
• Une révocation empêcherait tous les supports d'installation/récupération Windows existants, ainsi que les anciennes sauvegardes, de démarrer.
  • L'échec du démarrage se produirait même avec Secure Boot désactivé, car bootmgr vérifie sa propre signature.

Mise à jour (2023-05-10)

Une révocation incomplète a eu lieu, et un autre CVE (CVE-2023-24932). Il existe encore des bootmgfw vulnérables qui n'ont pas été révoqués, ainsi que des correctifs supplémentaires qui ne corrigent que le cas où bootmgr charge bootmgr. Il a suffi d'un bootkit copié-collé pour faire réagir Microsoft ;)
Si vous êtes assez créatif, vous trouverez un moyen de contourner la révocation de plus de 2000 fichiers bootmgfw ;)