wack0/bitlocker-attacksUne liste d'attaques publiques 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.
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.
| Résumé | Description | Corrigé | Fenêtre de divulgation publique | Découvert par |
|---|---|---|---|---|
| Sniffing TPM : bootmgr communique avec le TPM en clair | Windows Boot Manager communique avec le TPM en clair ; si une puce TPM séparée sur le bus LPC est utilisée (c.-à-d. pas fTPM ni « Pluton »/HSP), un analyseur logique sur ce bus peut être utilisé pour extraire le VMK. Voir aussi billet de blog de Pulse Security, code Verilog pour sniffer LPC. | Aucun, mais les TPM firmware n'étaient de toute façon pas vulnérables | janvier 2019 | marcan |
| Débogueur matériel : certains systèmes n'effectuent pas de mesure dans PCR7 avant d'activer un débogueur matériel | La spécification TCG EFI Platform pour TPM (section 6.4) inclut ce qui suit : « Si la plateforme fournit un mode débogueur firmware qui peut être utilisé avant l'environnement UEFI, ou si la plateforme fournit un débogueur pour l'environnement UEFI, alors la plateforme DOIT étendre un événement EV_EFI_ACTION dans PCR[7] avant de permettre l'utilisation du débogueur » Certains systèmes n'effectuent pas cette mesure avant d'activer certains débogueurs matériels (comme Intel DCI). Par conséquent, sur un tel système vulnérable, un contournement de Secure Boot (l'accès physique permettrait au moins deux avec Secure Boot toujours activé) ou une attaque matérielle (écriture directe dans la flash SPI) peut être utilisé pour activer le débogueur matériel ; définir un point d'arrêt (par exemple) dans bootmgr!FvebUnsealCallback peut alors permettre d'extraire le VMK. Voir aussi cet article de la Digital Forensics Research Conference Europe 2023. | Aucun, pour les systèmes vulnérables. Une liste exacte des systèmes vulnérables est inconnue. | mars 2023 | Police fédérale brésilienne |
| Glitching fTPM : exécution de code via du glitching pour compromettre entièrement l'état du fTPM | Si un processeur/microcontrôleur sur SoC qui implémente un fTPM est vulnérable au glitching, au point qu'une exécution de code peut être obtenue tôt au démarrage, l'ensemble de l'état du fTPM peut être compromis, permettant l'extraction du VMK (etc.). Voir aussi l'article de recherche, payloads/etc. pour AMD PSP | IntelME : novembre 2021 / Alder Lake AMD : inconnu, aucun ? Autres (ARM64, ARMv7, etc.) : inconnu | avril 2023 | Hans Niklas Jacob, Christian Werling, Robert Buhren, Jean-Pierre Seifert de la Technische Universität Berlin - SecT |
| Désactivation de l'IOMMU au démarrage : modifier le stockage de variables non volatiles UEFI via un dump/rewrite de la flash peut désactiver l'IOMMU au démarrage | Certains firmwares UEFI n'activent pas l'IOMMU au démarrage en fonction des données de variables. En effectuant un dump de la flash, en modifiant ces variables et en réécrivant, l'IOMMU sera désactivé au démarrage tandis que l'état non volatil du TPM reste valide. À ce stade, un attaquant peut alors écraser la table ACPI DMAR en utilisant le DMA PCI avant le lancement de bootmgr, démarrer en mode sans échec, puis utiliser à nouveau le DMA PCI pour obtenir un shell SYSTEM. Voir le writeup. On ne sait pas dans quel composant cela se trouve ; le writeup utilise un système Intel, le code concerné y étant fourni par l'Intel Firmware Support Package. On ignore si l'équivalent AMD (AGESA/CBS) est également affecté. | Intel Firmware Support Package : inconnu AMD AGESA/CBS : inconnu | mars 2026 | Craig S. Blackie de MDSec |
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.
