Attaques contre BitLocker

Une liste d'attaques publiques contre BitLocker. Toute attaque publique ayant le potentiel d'attaquer BitLocker mais dont la méthode exacte n'est pas encore publique (comme baton drop) est hors du périmètre.

La plupart des attaques concernent les cas où le VMK est scellé par le TPM uniquement, ce qui est le paramètre par défaut, et c'est ce que BitLocker automatique utilise en plus du dépôt de la clé de récupération auprès d'un compte Microsoft.

Par défaut, à partir de Windows 8, la validation d'intégrité Secure Boot est utilisée si Secure Boot est activé.

Si vous devez sceller le VMK par le TPM uniquement, la configuration la plus sécurisée pour cela est d'utiliser la validation d'intégrité héritée avec les PCR 0, 2, 4, 7, 11 (et également de maintenir votre système entièrement à jour).
Veuillez noter que cela ne protégera que contre les attaques logicielles.

Sommaire

• Attaques matérielles
• Attaques logicielles

Attaques matérielles

Les attaques matérielles ne sont généralement utiles que lorsque l'attaquant a un accès physique à un système où le VMK est scellé par le TPM uniquement.

Attaques logicielles

Les attaques logicielles sont généralement des vulnérabilités dans bootmgr, ou une autre application de démarrage, où l'exploitation est possible avec des clés BitLocker dérivées en mémoire pour un volume arbitraire.
Lorsqu'une exécution de code peut être obtenue dans une application de démarrage, un attaquant « evil cleaner » peut éventuellement installer un bootkit qui s'exécutera lui-même avec les clés dérivées en mémoire (ou lorsque les clés peuvent encore être dérivées), et ainsi compromettre un système où un mot de passe ou une clé de démarrage est utilisé à la place ou en plus d'un TPM.

dangerous association

Un système vulnérable aura les mises à jour de mai 2022 ou juin 2022 installées, mais pas les mises à jour ultérieures.

Le GUID des options associées fait partie des données hachées, donc l'élément de périphérique utilisé doit être marqué comme non vérifié.
Il n'existe aucun élément utilisable sur Windows 7 et inférieur (bien qu'avec des paramètres personnalisés non par défaut, cela puisse encore être possible).
Sur Windows 8 et supérieur, osloader!osdevice n'est pas vérifié par défaut et peut donc être utilisé.
Le moyen le plus simple d'exploiter cela est d'utiliser l'éditeur brut de périphériques BCD, bcdeditmod, bien que modifier manuellement la ruche de registre BCD soit également possible (débrouillez-vous).

L'exploitation implique :

• prendre le BCD de votre périphérique cible, créer deux éléments de périphérique
• copier l'osdevice depuis {default} vers le premier
• définir le GUID des options associées dans {default}!osdevice sur le premier élément de périphérique
• définir le GUID des options associées dans {first}!osdevice sur le second élément de périphérique
• définir les options « dangereuses » souhaitées (comme debug) dans le second élément de périphérique
• démarrer le périphérique cible en utilisant ce BCD et le même binaire bootmgfw qu'il utilisait

bitpixie

Cette vulnérabilité a existé pendant plus de 17 ans, le build connu le plus ancien dans lequel elle a été introduite étant 6.0.5231.2 (winmain_idx03.051004-2120) d'octobre 2005.
Lorsque la validation d'intégrité Secure Boot est utilisée, une attaque par rétrogradation fonctionnerait toujours pour exploiter cette vulnérabilité.Configurez un serveur de démarrage PXE avec un bootmgfw.efi vulnérable (lorsque la validation d'intégrité héritée est utilisée, il doit s'agir du bootmgfw.efi de l'appareil cible) renommé correctement pour le démarrage EFI.

Pour le BCD, configurez une entrée par défaut où device est l'osdevice chiffré par BitLocker ; path est "\" ; et une séquence de récupération.

La séquence de récupération doit pointer vers une seule entrée startup, où device est boot, path pointe vers une application EFI à exécuter (depuis le serveur PXE) ; et pxesoftreboot est activé.

Lorsque Secure Boot est désactivé, cette application EFI peut simplement être une application qui analyse la mémoire physique à la recherche d'une keytable BitLocker à extraire.

Lorsque Secure Boot est activé, cette application EFI peut utiliser un contournement connu de Secure Boot (un accès physique étant requis si nécessaire).
Pour exploiter une application de démarrage Windows de cette manière, vous devrez remplacer le BCD par votre second BCD sur le serveur PXE.
Cela signifie appuyer sur une touche fléchée au démarrage de bootmgr pour forcer l'affichage du menu de démarrage ; puis remplacer le BCD sur le serveur PXE à ce moment-là.

push button decrypt

L'exploitation implique :

• Extraire l'osvolume protégé par BitLocker vers une image disque. Cette méthode pour obtenir le FVEK entraîne une réelle perte de données !
• Démarrez dans WinRE par tous les moyens (forcez via la réparation de démarrage si nécessaire, ou définissez simplement l'élément BCD bootsequence, etc.).
• Lancez une réinitialisation (Dépannage -> Réinitialiser ce PC -> Tout supprimer). Il est plus rapide de choisir "Réinstallation locale". Assurez-vous de choisir "Supprimer uniquement mes fichiers".
  • Choisir "Conserver mes fichiers" demandera la clé de récupération.
  • Si le WinRE du système n'est pas vulnérable, il demandera également une clé de récupération.
• Lorsque la réinitialisation atteint ~98 %, éteignez le système de force (en maintenant le bouton d'alimentation enfoncé pendant 7 secondes / etc.).
• Rallumez le système ; il devrait démarrer à nouveau dans WinRE et afficher une erreur. La fermeture de l'erreur devrait déclencher un redémarrage.
• Lorsque vous voyez l'écran bleu "mise à jour", appuyez sur Shift+F10 pour obtenir un shell.
• Exécutez manage-bde -pause C: suivi de manage-bde -protectors -delete C:
• Éteignez le système de force (à nouveau).

À ce stade, les métadonnées BitLocker sur disque contiendront un VMK en clair.
Extrayez-le, puis utilisez ce VMK pour déchiffrer le FVEK.
Le FVEK déchiffré peut être utilisé sur l'image disque créée précédemment pour déchiffrer la partition.

Veuillez noter : je n'ai réussi à exploiter ce problème que sur Windows 10 dans des circonstances très spécifiques (BitLocker avec TPM uniquement et sans clé de récupération). Cependant, d'autres ont réussi à exploiter ce problème en utilisant un WinRE vulnérable sur Windows 11 (Nickel).

ram leak

Pour autant que je sache, cette vulnérabilité existe depuis aussi longtemps que le gestionnaire de démarrage lui-même - elle semble être présente dès 6.0.5098.0 (winmain_beta1.050628-1740) de juin 2005, bien que cela précède le BCD, l'exploitation serait donc différente sur des builds aussi anciens. Le code concerné semble également exister plus tôt (le code lié au ramdisk semble être le même dans le build 5048 d'avril 2005), mais le build 5098 est le build dumpé le plus ancien contenant BitLocker sous une forme ou une autre.

Pour exploiter cela, vous devez configurer une entrée par défaut et une séquence de récupération comme dans bitpixie. Ceci afin que les clés soient dérivées pour le périphérique du système d'exploitation lorsque le fichier est chargé.

La séquence de récupération doit contenir une entrée de périphérique supplémentaire pour configurer le ramdisk. Utilisez bcdeditmod pour cela. Utilisez ici un élément personnalisé comme custom:21100000. Un exemple d'entrée de périphérique à utiliser ici serait !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]] - vous voudrez remplacer le périphérique de bloc part2 ici par celui du BCD de votre système cible.

Le fichier peut ensuite être extrait de la mémoire par la méthode qui fonctionne pour vous. Je préfère utiliser un winload plus ancien avec un mcupdate auto-signé via le menu des options avancées, mais d'autres options sont disponibles (un soft reboot PXE vers un système d'exploitation tiers par exemple ; un dump mémoire depuis WinPE en utilisant un bugcheck ou un pilote vulnérable connu est possible, mais winload marquera la zone mémoire comme libre dans la carte mémoire NT, elle pourrait donc être écrasée sans certains réglages pour marquer cette mémoire comme défaillante/etc dans winload).

Une implémentation de preuve de concept de ma méthode préférée est incluse dans ce dépôt sous le nom ramleak.zip. Lisez le readme inclus pour les instructions d'utilisation.

Un grand merci à Maxim Suhanov ; cela a été inspiré par la lecture du writeup de CrashXTS et par la recherche d'un autre moyen de potentiellement extraire hiberfil.sys.

Et maintenant, mes réflexions sur ce bug et sur yellowkey :

C'était la première fois que j'avais un réel problème avec une soumission à MSRC, et c'était principalement un malentendu de leur côté concernant Secure Boot. Étant donné qu'un autre 0day BitLocker a été divulgué, j'ai décidé de publier ceci maintenant ; je garde cela depuis près d'un an en me demandant quoi en faire.

Contrairement à yellowkey, je ne vais pas faire de déclarations exagérées en parlant de "backdoor", à mon avis je ne pense pas que yellowkey soit une backdoor, le composant concerné est lié à WinPE (pas spécifique à WinRE), et la principale "vuln" consiste à faire supprimer winpeshl.ini pour atteindre ce chemin de code, je comprends tout à fait pourquoi MS pensait que sa suppression dans un scénario WinRE+bitlocker n'était pas possible.

Étant donné que charger un ramdisk depuis une partition chiffrée par BitLocker est en réalité une fonctionnalité de l'environnement de démarrage, même si j'ai dû utiliser une astuce existante pour la faire fonctionner, d'autres pourraient aussi dire que c'était une backdoor s'ils le voulaient, mais je n'irai pas jusque-là. L'environnement de démarrage est complexe (et ne cesse de grossir, le dernier bootmgfw_ex.efi ne tient plus dans une image de 2.88MB - fin d'une époque), plusieurs vulns ont été découvertes en raison de la façon dont certaines fonctionnalités interagissent entre elles.