wack0/bitlocker-attacksUma lista de ataques públicos ao BitLocker
Uma lista de ataques públicos ao BitLocker. Qualquer ataque público com potencial para atacar o BitLocker, mas cujo método exato ainda não seja público (como baton drop), está fora do escopo.
A maioria dos ataques é para os casos em que a VMK é selada apenas pelo TPM, que é a configuração padrão, e é o que o BitLocker automático usa juntamente com a guarda da chave de recuperação em uma conta Microsoft.
Por padrão, a partir do Windows 8, a validação de integridade do Secure Boot é usada se o Secure Boot estiver ativado.
Se for necessário selar a VMK apenas pelo TPM, a configuração mais segura para isso é usar a validação de integridade legada com as PCRs 0, 2, 4, 7, 11 (e também manter o sistema totalmente atualizado).
Observe que isso protegerá apenas contra ataques de software.
Os ataques de hardware geralmente só são úteis quando o atacante tem acesso físico a um sistema em que a VMK é selada apenas pelo TPM.
| Resumo | Descrição | Correção | Período de divulgação pública | Descoberto por |
|---|---|---|---|---|
| Sniffing de TPM: o bootmgr comunica-se com o TPM em texto claro | O Windows Boot Manager comunica-se com o TPM em texto claro; portanto, se um chip TPM separado no barramento LPC for usado (ou seja, não fTPM, nem "Pluton"/HSP), um analisador lógico nesse barramento pode ser usado para despejar a VMK. Veja também a publicação do blog da Pulse Security, código Verilog do sniffer LPC. | Nenhuma, mas TPMs de firmware não eram vulneráveis de qualquer forma | Janeiro de 2019 | marcan |
| Depurador de hardware: alguns sistemas não medem para PCR7 antes de ativar um depurador de hardware | A especificação TCG EFI Platform Specification for TPM (seção 6.4) inclui o seguinte: "Se a plataforma fornecer um modo de depurador de firmware que possa ser usado antes do ambiente UEFI, ou se a plataforma fornecer um depurador para o ambiente UEFI, a plataforma DEVE estender um evento EV_EFI_ACTION para PCR[7] antes de permitir o uso do depurador" Alguns sistemas não realizam essa medição antes de ativar alguns depuradores de hardware (como Intel DCI). Portanto, em um sistema vulnerável, um bypass do Secure Boot (o acesso físico permitiria pelo menos dois com o Secure Boot ainda ativado) ou um ataque de hardware (escrever diretamente na flash SPI) pode ser usado para ativar o depurador de hardware; definir um ponto de interrupção (por exemplo) dentro de bootmgr!FvebUnsealCallback pode então permitir o despejo da VMK. Veja também este artigo da Digital Forensics Research Conference Europe 2023. | Nenhuma, para sistemas vulneráveis. Uma lista exata de sistemas vulneráveis é desconhecida. | Março de 2023 | Polícia Federal Brasileira |
| Glitching de fTPM: execução de código via glitching para comprometer completamente o estado do fTPM | Se um processador/microcontrolador no SoC que implementa um fTPM for vulnerável a glitching, de modo que a execução de código possa ser obtida logo no início da inicialização, todo o estado do fTPM pode ser comprometido, levando ao despejo da VMK (etc.). Veja também o artigo de pesquisa, payloads/etc para AMD PSP | IntelME: novembro de 2021 / Alder Lake AMD: desconhecida, nenhuma? Outros (ARM64, ARMv7, etc.): desconhecida | Abril de 2023 | Hans Niklas Jacob, Christian Werling, Robert Buhren, Jean-Pierre Seifert da Technische Universit ät Berlin - SecT |
| Desativação de IOMMU em tempo de inicialização: modificar o armazenamento de variáveis não voláteis da UEFI com despejo/reescrita de flash pode desativar o IOMMU na inicialização | Alguns firmwares UEFI não ativarão o IOMMU na inicialização com base em dados de variáveis. Ao despejar a flash, modificar essas variáveis e regravá-la, o IOMMU será desativado na inicialização com o estado não volátil do TPM ainda válido. Nesse ponto, um atacante pode sobrescrever a tabela ACPI DMAR usando PCI DMA antes de o bootmgr ser iniciado, inicializar no Modo de Segurança e usar PCI DMA novamente para obter um shell SYSTEM. Veja o artigo. Não se sabe em qual componente isso está; o artigo usa um sistema Intel, e o código relevante é fornecido pelo Intel Firmware Support Package. Não se sabe se o equivalente AMD (AGESA/CBS) também é afetado. | Intel Firmware Support Package: desconhecida AMD AGESA/CBS: desconhecida | Março de 2026 | Craig S. Blackie da MDSec |
Os ataques de software são normalmente vulnerabilidades no bootmgr, ou em algum outro aplicativo de inicialização, onde a exploração é possível com chaves do BitLocker derivadas em memória para um volume arbitrário.
Quando a execução de código pode ser obtida dentro de um aplicativo de inicialização, um atacante "evil cleaner" pode instalar um bootkit que, por sua vez, será executado com chaves derivadas em memória (ou quando as chaves ainda podem ser derivadas), comprometendo assim um sistema em que uma senha ou chave de inicialização seja usada em vez de, ou além de, um TPM.
