Contourner BitLocker sur Windows 11 avec un dump mémoire

 (noinitrd.github.io)
2 points par GN⁺ 2025-01-01 | 1 commentaires | Partager sur WhatsApp
  • Démonstration consistant à dumper la RAM dans un environnement Windows 11 24H2 avec Memory-Dump-UEFI afin de retrouver la FVEK, la clé de chiffrement complète du volume, et d’accéder à un volume protégé par BitLocker
  • Si un attaquant peut accéder physiquement à l’appareil, il peut viser les clés encore présentes en RAM juste après un redémarrage, mais le risque de corruption du contenu de la RAM augmente à mesure que la coupure d’alimentation se prolonge
  • La démonstration a utilisé une méthode consistant à court-circuiter les broches de reset (reset pins) de la carte mère pour redémarrer sans perte d’alimentation, et laisse hors du périmètre de la démo les cas de contournement de Secure Boot
  • Dans le dump de Windows 11, la FVEK a été trouvée sous les tags dFVE et None, au lieu de FVEc sur Windows 7 et Cngb sur Windows 8.1/10
  • Même si Microsoft tente de détruire les clés avec des fonctions comme SymCryptSessionDestroy, des clés peuvent rester dans le heap, ce qui fait du debugging au niveau noyau l’approche la plus directe pour analyser l’implémentation de BitLocker

Périmètre de la démonstration de contournement de BitLocker sur Windows 11

  • La cible est Windows 11 version 24H2, avec une méthode consistant à extraire depuis la mémoire la FVEK, la clé de chiffrement complète du volume de BitLocker
  • L’application UEFI Memory-Dump-UEFI est utilisée pour dumper le contenu de la RAM
  • Le point clé est que l’attaquant doit avoir un accès physique à l’appareil

Conditions nécessaires au dump de la RAM

  • La RAM de l’instance Windows exécutée récemment peut encore contenir des informations sensibles comme la FVEK
  • Comme le contenu de la RAM se dégrade rapidement lorsque l’alimentation est coupée, il faut minimiser le temps pendant lequel l’ordinateur est totalement éteint durant le redémarrage
  • Pour réduire cette dégradation, on peut refroidir physiquement la RAM ou maintenir une alimentation externe ; dans cette démonstration, le redémarrage est réalisé en court-circuitant les broches de reset de la carte mère sans perte d’alimentation
  • Secure Boot est un standard de sécurité qui limite ce qui peut être exécuté au démarrage de l’appareil, mais il existe des cas de contournement via shim, qui ne sont pas détaillés dans cette démo

Préparation de la clé USB de démarrage et création du dump

  • La clé USB de démarrage doit disposer d’une capacité de stockage supérieure à la quantité de RAM du système ciblé
  • Le script flashimage.sh simplifie la préparation de l’application bootable
  • La procédure de création et d’utilisation de l’application de démarrage est décrite dans MemoryDumpUEFI
  • Les chances de trouver la FVEK étaient les plus élevées lorsque le redémarrage avait lieu pendant le chargement de Windows, mais avant l’apparition de l’écran de connexion
  • Après avoir démarré immédiatement sur le périphérique USB avec Memory-Dump-UEFI, il faut exécuter app.efi dans le shell UEFI
    • Le mode d’exécution comporte des étapes supplémentaires dans le README de l’application
    • Le temps nécessaire au dump dépend de la capacité de la RAM et de la vitesse du périphérique USB
    • Pour éviter d’écrire sur le mauvais lecteur, mieux vaut débrancher les autres périphériques de stockage USB

Traitement des fichiers de dump et outils de recherche

  • Memory-Dump-UEFI peut générer plusieurs fichiers de dump
  • Pour respecter la spécification UEFI, il faut utiliser un système de fichiers FAT32, qui impose une limite de taille de fichier de 4 Go
  • concatDumps, dans le répertoire tools, fusionne plusieurs dumps en un seul dans l’ordre chronologique
  • Comme les dumps sont des données brutes présentes en mémoire à l’instant T, des outils comme xxd permettent de les examiner plus facilement
  • searchMem permet de rechercher des motifs hexadécimaux dans le dump et de se déplacer jusqu’à l’offset où ils sont trouvés

Tags de pool et emplacement de la FVEK

  • Un tag de pool (pool tag) est un identifiant de 4 caractères indiquant à quelle zone du pool mémoire noyau de Windows appartient un bloc
  • Les pools mémoire alloués par le noyau Windows peuvent être de bons emplacements pour rechercher des informations sensibles
  • pooltag.txt contient une liste de tags de pool ainsi que des informations sur leur usage respectif
  • L’emplacement des clés BitLocker différait selon les anciennes versions de Windows
    • Sur Windows 7, il était possible de récupérer la clé depuis le tag de pool FVEc, correspondant à des allocations de chiffrement de fvevol.sys
    • Sur Windows 8.1 et Windows 10, on pouvait trouver la clé dans le pool mémoire du tag Cngb, associé au module ksecdd.sys
  • Dans les dumps Windows 11, la clé n’a pas été trouvée sous FVEc ni Cngb, mais la FVEK a été identifiée à deux endroits
    • Le premier est sous le tag de pool dFVE, qui représente de la mémoire allouée par dumpfve.sys
    • dumpfve.sys est lié au filtre de crash dump de chiffrement complet de volume de BitLocker drive encryption
    • L’emplacement dFVE était celui où la clé était trouvée le plus facilement et le plus régulièrement
    • À cet emplacement, la clé était précédée de 0x0480, qui indique le type de chiffrement et correspondait dans l’environnement de démonstration à XTS-AES-128
    • Le second emplacement se trouvait sous le tag None, lié à des appels ExAllocatePool
    • À cet emplacement, la première moitié de la clé apparaissait deux fois, et la seconde moitié une fois

Accéder à un volume BitLocker avec la FVEK

  • La clé récupérée doit être préfixée par la valeur de l’algorithme de chiffrement utilisé
  • Dans l’exemple, la valeur d’algorithme 0x8004 est ajoutée devant la clé au format little endian, soit 0480
  • La valeur ainsi construite peut être enregistrée dans un fichier pour être utilisée sous la forme output.fvek
  • La suite d’outils dislocker est recommandée pour vérifier l’algorithme et les valeurs nécessaires, puis déverrouiller la partition protégée par BitLocker
  • Si la procédure est correcte, output.fvek permet d’accéder aux données du volume protégé par BitLocker

Analyse de l’implémentation de BitLocker et clés résiduelles dans le heap

  • La manière la plus directe de comprendre l’implémentation de BitLocker est d’utiliser windbg pour faire du debugging au niveau noyau
  • Le debugging noyau peut être mis en place assez facilement dans une machine virtuelle ou via un câble USB 3.0 A/A croisé
  • Suivre pas à pas le processus de démarrage de Windows et observer le fonctionnement de BitLocker a aidé à localiser les clés
  • Microsoft essaie de détruire les clés avec des fonctions comme SymCryptSessionDestroy, mais des clés peuvent rester dans le heap, ce qui empêche leur suppression complète

Liens de référence

À lire aussi

1 commentaires

 
GN⁺ 2025-01-01
Avis de Hacker News

  • Je pense que BitLocker est surtout avantageux quand on utilise TPM (PCR 7+11)+PIN
    Sans le PIN, il ne devrait pas être possible de lire la FVEK, ce qui peut atténuer cette attaque, et si BitLocker l’a correctement implémenté, le TPM passe en mode de verrouillage anti-attaque par dictionnaire après trop de PIN erronés
    Depuis des mois, j’essaie de mettre en place la même configuration sous Linux, mais systemd-cryptsetup/cryptenroll est destiné à LUKS, alors que je cherche à chiffrer quelques répertoires sensibles avec fscrypt (les clés de secure boot et /home) sur un eMMC interne lent
    Dès qu’on dépasse les bases, le codage avec TPM me semble extrêmement difficile : se lier au PCR 7, se lier au PCR 11 qui change à chaque mise à jour du kernel/init/cmdline, utiliser un PIN plutôt qu’une AuthValue, utiliser la même politique d’autorisation pour réinitialiser le compteur de verrouillage DA à la connexion tout en conservant aussi un long mot de passe/AuthValue pour la réinitialisation manuelle, et faire correspondre la signature PCR 11 fournie par systemd-stub ainsi que la clé publique
    En dehors des guides TPM de base, il y a très peu de documentation ; s’il y a des experts, j’aimerais avoir de l’aide. C’est un projet personnel, mais si je le termine un jour, je compte en faire un article

    • LUKS dispose de plusieurs slots de clés, donc il me semble qu’on pouvait utiliser un slot pour le déverrouillage via TPM et un autre pour la récupération avec un long mot de passe
      Cela vaut la peine d’envisager cette approche comme mécanisme de récupération
      L’une des raisons pour lesquelles peu de gens bricolent l’open source autour de TPM comme hobby, c’est qu’il existe beaucoup d’alternatives qui répondent à des besoins similaires bien plus facilement
      Si vous voulez lier des clés de chiffrement importantes au matériel, vous pouvez acheter une Yubikey ; si le mot de passe de chiffrement du disque d’un ordinateur portable est pénible, vous pouvez utiliser la veille à la fermeture du capot plutôt que l’arrêt complet
      Si le mot de passe de connexion est gênant, il y a les lecteurs d’empreintes ou les Yubikey avec authentification biométrique ; et si une borne sans surveillance ou une salle informatique d’école doit démarrer sans mot de passe, vous pouvez la mettre dans un solide boîtier métallique et l’enchaîner au mur
      Si un serveur de datacenter doit démarrer sans intervention, déplacez-le dans un datacenter doté d’une sécurité physique fiable, et si cela vous inquiète encore, utilisez Dropbear ou Tang pour qu’il ne démarre que lorsqu’il se trouve sur le bon réseau
      Si vous manipulez TPM comme hobby dans un homelab, il vaut mieux vérifier si travailler avec TPM est vraiment amusant, et il y a de fortes chances que vous découvriez que non
    • Même si Windows exige un PIN pour que le TPM obtienne la FVEK au départ, il finira de toute façon par conserver la FVEK en RAM
      Sinon, il faudrait saisir le PIN à chaque déchiffrement d’un bloc disque, non ? L’impact en performances d’un appel au TPM pour chaque opération disque serait aussi énorme
      Comme cette attaque lit la clé en RAM, je ne vois pas en quoi un PIN TPM constitue une atténuation
    • Je me demande s’il ne vaudrait pas mieux utiliser un chiffrement à clé scindée ou une clé secrète chiffrée
      Si l’on saisit un mot de passe avant le démarrage et que ce mot de passe doit être combiné avec une clé TPM pour ouvrir le lecteur, cela aide dans le cas où la clé TPM serait découverte par la suite
      Cela dit, il est difficile de savoir dans quelle mesure telle ou telle contre-mesure aiderait face à cette attaque. Pour que l’OS conserve l’accès en lecture/écriture au lecteur, il doit garder la clé quelque part ; donc, dans la plupart des scénarios, ce type de récupération de données en RAM restera possible, il suffira de changer l’endroit où chercher la clé
      Si je me souviens bien, sur les appareils Apple, la clé ne sort pas de l’enclave sécurisée, donc ils ne devraient pas être vulnérables à ce type d’attaque. TPM 3.0 devra, semble-t-il, se rapprocher beaucoup plus de ce modèle
    • Je me dis que le mot de passe de mise sous tension du BIOS devrait aussi fonctionner. Sans lui, le système ne peut pas atteindre le point où le TPM libère la FVEK
      Sur les ThinkPad, on peut utiliser l’empreinte digitale à la place du mot de passe de mise sous tension, et comme cela rend l’appareil presque inutilisable pour un voleur, je préfère cette configuration à un PIN BitLocker
      Bien sûr, le mot de passe de mise sous tension et l’authentification par empreinte ne sont pas plus solides que le TPM, mais n’est-ce pas aussi le cas de BitLocker TPM+PIN ?
    • J’ai l’impression que le TPM est une sorte de pot de miel
      Après le succès des logiciels de chiffrement open source, le mouvement vers TPM me paraît étrange. Cela ressemble à : « il existe un coffre-fort ultra-sécurisé fourni par de grandes entreprises, ne vous inquiétez pas et ne posez pas de questions »
      Je soupçonne fortement qu’il existe forcément une porte dérobée permettant aux agences de renseignement de télécharger tous les PIN et mots de passe et d’accéder aux données

  • Je ne comprends fondamentalement pas très bien le modèle de sécurité de BitLocker
    Dans la plupart des installations, on dirait qu’il suffit d’appuyer sur le bouton d’alimentation pour démarrer Windows
    Donc, si quelqu’un vole une machine avec un disque dur chiffré, il lui suffit de l’allumer ? Ce n’est sûrement pas le cas, mais en même temps je ne vois pas comment cette attaque précise est empêchée
    Je suppose qu’il faut partir du principe que le trafic du bus SPI est chiffré et qu’on ne peut pas extraire la clé de cette façon, mais quoi qu’il en soit la machine semble donner la clé assez facilement
    LUKS, au moins, affiche une invite de mot de passe pour déverrouiller le disque

    • Le trafic du bus SPI n’est pas chiffré
      Curieusement, Microsoft n’utilise pas le chiffrement des paramètres du TPM, et donc tous les un ou deux ans un chercheur en sécurité fabrique et démontre un dispositif de sniffing du TPM
      LUKS dépend aussi de la configuration. Linux peut être configuré ici de la même manière que Windows, et mon serveur de vidéosurveillance domestique est réglé ainsi parce qu’il doit redémarrer sans intervention. Je sais qu’il est vulnérable aux attaques par démarrage à chaud/à froid et à la surface d’attaque logicielle, mais si quelqu’un se contente de retirer le disque, il est protégé
      Windows peut aussi être configuré pour demander un mot de passe ou pour utiliser une clé scellée par le TPM avec authentification par PIN
      Si l’on met de côté le chiffrement des paramètres et le problème du sniffing de bus, BitLocker déplace la frontière de « n’importe qui peut lire le disque » vers « il faut mener une attaque au niveau de la plateforme pour obtenir le contenu de la mémoire, ou compromettre un service qui tourne sur l’écran de connexion »
      Comme il empêche très bien des scénarios du type vol de données financières sur des disques durs recyclés au hasard, c’est en pratique une amélioration de sécurité assez correcte
    • Si vous allumez une machine volée, vous n’arrivez qu’à l’écran de connexion, et vous ne pouvez pas aller plus loin sans mot de passe ni authentification biométrique
      Il faut un contournement du type vulnérabilité d’exécution de code à distance, ou démarrage avec un ancien bootloader Windows vulnérable. Comme le disque est verrouillé, le contournement classique consistant à remplacer le clavier logiciel par cmd.exe ne fonctionne pas
      Sans BitLocker, on peut brancher le disque Windows sur un autre PC et voir tous les fichiers. Avec BitLocker, il faut se débattre avec des logiciels Microsoft vulnérables, des failles, de la mémoire extraite, etc., et ça ne marche pas toujours
      Si BitLocker est configuré en mode TPM+PIN, on ne peut même pas faire cela, puisqu’il n’y a pas de mot de passe pour ouvrir le TPM. On peut aussi laisser BitLocker en mode mot de passe seul, mais il est beaucoup plus vulnérable à la force brute
      De même pour LUKS : la plupart des distributions Linux récentes prennent en charge TPM et TPM+PIN
    • C’est vrai, mais l’idée est qu’à l’écran de connexion (winlogon), il n’y a quasiment rien que l’on puisse faire sans identifiants d’un compte de cet ordinateur ou sans biométrie enregistrée
      Si vous essayez de redémarrer en mode sans échec, ou sur un autre OS, un utilitaire de mise à jour du firmware, etc., vous devez saisir la clé de récupération BitLocker
      Je ne sais pas très bien comment fonctionnent en interne les cas où l’on « pirate » le capteur d’empreintes ou la webcam de reconnaissance faciale
    • Le principal objectif de BitLocker avec PIN+TPM est de transformer un ordinateur éteint, ou le disque lui-même, en brique
      Il faut supposer que le TPM n’a pas de vulnérabilité permettant d’extraire la clé
      Le point essentiel, c’est quand la machine est hors tension
      Pour le chiffrement de disque généraliste, le TPM est trop lent pour déchiffrer réellement les grandes quantités de données, donc l’OS finit par détenir une clé extractible
    • Les volumes BitLocker peuvent avoir plusieurs protecteurs, et utiliser des fichiers de clé, des phrases secrètes, un PIN ou le stockage TPM : https://learn.microsoft.com/en-us/windows-server/administrat...
      Dans l’édition Pro, on peut aussi exiger une étape interactive au démarrage via une stratégie de groupe. Cela fonctionne même sans TPM ; dans ce cas, un mot de passe est demandé à chaque démarrage

  • Cela peut être entièrement bloqué par https://trustedcomputinggroup.org/resource/pc-client-work-gr...
    Lorsque cette fonction est activée, si l’OS ne s’est pas arrêté correctement et n’a pas eu l’occasion d’effacer les clés de chiffrement, le firmware s’arrête avant le démarrage suivant et efface la RAM
    Je me demande si Windows ne l’utilise pas, ou si le système testé ne l’implémentait pas

    • Windows est connu pour utiliser cette fonction : https://learn.microsoft.com/en-us/windows/security/operating...
      Il est indiqué que « BitLocker utilise la TCG Reset Attack Mitigation, aussi appelée MOR bit (Memory Overwrite Request), avant d’extraire la clé en mémoire »
      Cela dit, je ne fais absolument pas confiance à la plupart des implémentations de plateformes. Je n’ai jamais vu de plateforme UEFI qui se rapproche vraiment d’une implémentation correcte, sous quelque forme que ce soit
      Il serait intéressant de savoir quelle plateforme ce chercheur a utilisée, et si cette plateforme prétend prendre en charge le MOR bit
    • Cette mesure d’atténuation est très bancale, car on peut interférer même pendant l’écrasement de la RAM
      Il suffit de regarder comment Team Tweezers a attaqué la Wii originale
      La vraie mesure d’atténuation, ce sont les fonctions de chiffrement de la mémoire des CPU modernes. Comme c’est dans le die, les pincettes ne peuvent pas l’atteindre ; il suffit d’effacer la clé, ce qui est instantané, et même si elle survit à un cycle d’alimentation, il est très difficile d’interférer
    • Cela n’empêche quand même pas de retirer tout le module de RAM pour le dumper hors ligne
      Idéalement, la clé devrait rester uniquement dans le cache SRAM du CPU et ne jamais sortir du die du CPU

  • Je suis l’auteur du billet. Si vous avez des questions, vous pouvez m’écrire avec ce compte
    Le travail a été vraiment amusant, et merci pour tout l’intérêt suscité

  • Présentation du 38C3 liée au contournement de BitLocker sous Windows 11 : https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...

  • Il est assez bien connu que BitLocker ne protège correctement que les ordinateurs éteints, et encore seulement lorsque BitLocker est configuré pour demander un mot de passe au démarrage
    [0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...

  • Windows dispose d’une option de chiffrement de la mémoire proposée en même temps que la compression mémoire
    Intel comme AMD travaillent à intégrer cette fonctionnalité dans leurs CPU
    Cela dit, la cible semble être les serveurs faisant tourner plusieurs machines virtuelles, plutôt que les ordinateurs portables

    • Microsoft évolue de plus en plus vers la sécurité basée sur la virtualisation, avec notamment la possibilité d’exécuter des « enclaves » pour protéger certains morceaux de logiciel : https://learn.microsoft.com/en-us/windows/win32/trusted-exec...
      Il ne serait pas surprenant que des « machines virtuelles » chiffrées soient bientôt utilisées comme moyen de stocker ce type de secrets. Ce qu’il faut, c’est une prise en charge matérielle largement généralisée sur les plateformes grand public
      Cela dit, de précédentes attaques par canal auxiliaire sur les CPU ont montré que même la mémoire chiffrée pouvait être attaquée (https://www.usenix.org/conference/usenixsecurity21/presentat...). Elles ciblent le cache lorsque le CPU déchiffre la mémoire pour fonctionner normalement
      Cela aiderait à neutraliser les dumps mémoire, mais la RAM chiffrée ne mettra pas fin à l’extraction de clés depuis la mémoire. C’est particulièrement vrai face à des attaquants patients ou très qualifiés
    • Intel propose actuellement cela avec la fonctionnalité Total Memory Encryption. Dans l’écosystème Windows, elle vise, à juste titre, plutôt les machines virtuelles
      https://techcommunity.microsoft.com/blog/windowsosplatform/m...
      La compression mémoire existe depuis longtemps, au moins depuis Windows 10 RTM. Tous les grands systèmes d’exploitation l’ont implémentée, mais elle n’a rien à voir avec la sécurité

  • Article connexe : contourner BitLocker sur un ordinateur portable Lenovo avec un analyseur logique bon marché
    https://news.ycombinator.com/item?id=37249623

  • Dans une attaque qui repose sur la lecture du dump mémoire de la machine cible, avec un accès physique, je me demande dans quelle mesure un dispositif interposeur copiant ou modifiant les données qui entrent et sortent de la RAM serait réaliste
    Je pense à quelque chose comme l’« Action Replay » pour les anciens Game Boy, qui permettait de tricher en modifiant la mémoire chargée ou exécutée depuis la cartouche de jeu vers le système. On branchait la cartouche dans l’Action Replay, puis l’Action Replay dans la Game Boy
    Pourrait-on faire quelque chose de similaire entre la RAM et la carte mère ? Brancher la RAM dans un dispositif, brancher ce dispositif sur la carte mère, puis observer les lectures/écritures mémoire pour capturer l’état de la mémoire à un instant arbitraire
    Cela éviterait la contrainte d’éteindre manuellement la machine en espérant que les données nécessaires soient encore présentes
    Je ne suis pas ingénieur électricien, donc c’est peut-être une proposition totalement impossible. Les contraintes d’espace physique et de bande passante semblent clairement importantes, mais est-ce faisable ?

    • En théorie, c’est possible. En pratique, lors de l’établissement d’un lien DDR, il faut beaucoup de négociation entre le contrôleur mémoire et la RAM, et il n’est pas facile de créer une situation permettant de dumper les données tout en conservant les mêmes timings
      Il est difficile de s’attendre à voir apparaître une solution prête à l’emploi
    • Les CPU AMD/Intel récents prennent en charge le chiffrement intégral de la mémoire transparent, donc un tel interposeur ne verrait que des données RAM chiffrées

  • Peu de gens savent que les CPU Intel/AMD sortis ces dernières années prennent en charge le chiffrement intégral de la mémoire transparent
    Le contenu de la RAM est chiffré avec une clé aléatoire conservée dans le contrôleur mémoire du CPU et générée à la réinitialisation
    En général, c’est désactivé dans le BIOS, car il y a une légère perte de performances mémoire (0,1 % à 1 %)
    Mais cela peut bloquer complètement cette attaque

    • Si j’ai bien compris, AMD appelle cette fonctionnalité SME (Secure Memory Encryption), et Intel TME-MK (Total Memory Encryption-Multi Key)