wack0/bitlocker-attacksUna lista de ataques públicos a BitLocker
Una lista de ataques públicos a BitLocker. Cualquier ataque público con el potencial de atacar BitLocker pero cuyo método exacto aún no sea público (como baton drop) queda fuera del alcance.
La mayoría de los ataques son para cuando la VMK está sellada únicamente por el TPM, que es la configuración predeterminada, y es lo que BitLocker automático usa junto con el depósito de la clave de recuperación en una cuenta Microsoft.
De forma predeterminada, a partir de Windows 8, se utiliza la validación de integridad de Secure Boot si Secure Boot está habilitado.
Si debes sellar la VMK únicamente con el TPM, la configuración más segura para ello es usar la validación de integridad heredada con las PCR 0, 2, 4, 7, 11 (y además mantener tu sistema completamente actualizado).
Ten en cuenta que esto solo protegerá contra ataques de software.
Los ataques de hardware suelen ser útiles solo cuando el atacante tiene acceso físico a un sistema donde la VMK está sellada únicamente por el TPM.
| Summary | Description | Fixed | Public disclosure timeframe | Discovered by |
|---|---|---|---|---|
| Sniffing de TPM: bootmgr se comunica con el TPM en claro | El Administrador de arranque de Windows se comunica con el TPM en claro, por lo que si se usa un chip TPM independiente en el bus LPC (es decir, no fTPM, ni "Pluton"/HSP), se puede usar un analizador lógico en ese bus para volcar la VMK. Ver también entrada de blog de Pulse Security, código Verilog del sniffer LPC. | Ninguna, pero los TPM de firmware no eran vulnerables de todos modos | enero de 2019 | marcan |
| Depurador de hardware: algunos sistemas no miden en la PCR7 antes de habilitar un depurador de hardware | La especificación de plataforma EFI de TCG para TPM (sección 6.4) incluye lo siguiente: "Si la plataforma proporciona un modo de depurador de firmware que pueda usarse antes del entorno UEFI, o si la plataforma proporciona un depurador para el entorno UEFI, entonces la plataforma DEBE extender un evento EV_EFI_ACTION a la PCR[7] antes de permitir el uso del depurador" Algunos sistemas no realizan esta medición antes de habilitar algunos depuradores de hardware (como Intel DCI). Por lo tanto, en un sistema vulnerable de este tipo, se puede usar una omisión de Secure Boot (el acceso físico permitiría al menos dos con Secure Boot aún habilitado) o un ataque de hardware (escribiendo directamente en la memoria flash SPI) para habilitar el depurador de hardware; establecer un punto de interrupción (por ejemplo) dentro de bootmgr!FvebUnsealCallback puede entonces permitir volcar la VMK. Ver también este artículo de la Conferencia Digital Forensics Research Europe 2023. | Ninguna, para sistemas vulnerables. Se desconoce la lista exacta de sistemas vulnerables. | Marzo de 2023 | Policía Federal de Brasil |
| Glitching de fTPM: ejecución de código mediante glitching para comprometer por completo el estado del fTPM | Si un procesador/microcontrolador en el SoC que implementa un fTPM es vulnerable al glitching de modo que se pueda obtener ejecución de código al inicio del arranque, todo el estado del fTPM puede verse comprometido, lo que permite volcar la VMK (etc.). Ver también el artículo de investigación, payloads/etc. para AMD PSP | IntelME: noviembre de 2021 / Alder Lake AMD: desconocido, ¿ninguno? Otros (ARM64, ARMv7, etc.): desconocido | Abril de 2023 | Hans Niklas Jacob, Christian Werling, Robert Buhren, Jean-Pierre Seifert de Technische Universität Berlin - SecT |
| Deshabilitación de IOMMU en el arranque: modificar el almacenamiento de variables no volátiles de UEFI con un volcado/reescritura de flash puede deshabilitar IOMMU en el arranque | Algunos firmwares UEFI no habilitan IOMMU en el arranque según los datos de variables. Al volcar la flash, modificar esas variables y reescribirla, IOMMU quedará deshabilitada en el arranque con el estado no volátil del TPM aún válido. En ese momento, un atacante puede sobrescribir la tabla ACPI DMAR mediante PCI DMA antes de que se inicie bootmgr, arrancar en modo seguro y volver a usar PCI DMA para obtener un shell de SYSTEM. Ver el informe. Se desconoce en qué componente está; el informe usa un sistema Intel, y el código relevante allí lo proporciona el Intel Firmware Support Package. Se desconoce si el equivalente de AMD (AGESA/CBS) también está afectado. | Intel Firmware Support Package: desconocido AMD AGESA/CBS: desconocido | Marzo de 2026 | Craig S. Blackie de MDSec |
Los ataques de software suelen ser vulnerabilidades en bootmgr, o en alguna otra aplicación de arranque donde la explotación es posible con las claves de BitLocker derivadas en memoria para un volumen arbitrario.
Cuando se puede obtener ejecución de código dentro de una aplicación de arranque, puede ser posible para un atacante "evil cleaner" instalar un bootkit que a su vez se ejecutará con las claves derivadas en memoria (o cuando las claves aún pueden derivarse), y así comprometer un sistema donde se usa una contraseña o una clave de inicio en lugar de un TPM o además de él.
