Contornando o BitLocker no Windows 11 com dump de memória

 (noinitrd.github.io)
2 pontos por GN⁺ 2025-01-01 | 1 comentários | Compartilhar no WhatsApp
  • Demonstração em um ambiente Windows 11 24H2 que usa Memory-Dump-UEFI para fazer dump da RAM, encontrar a FVEK, a chave de criptografia de volume completo, e acessar um volume protegido pelo BitLocker
  • Se um invasor tiver acesso físico ao dispositivo, pode mirar na chave que permanece na RAM logo após uma reinicialização, mas quanto maior for o tempo sem energia, maior o risco de corrupção do conteúdo da RAM
  • A demonstração usou um curto nos pinos de reset (reset pins) da placa-mãe para reiniciar sem perda de energia, e deixou casos de bypass do Secure Boot fora do escopo da demo
  • Nos dumps do Windows 11, a FVEK foi encontrada sob as tags dFVE e None, em vez de FVEc do Windows 7 e Cngb do Windows 8.1/10
  • Mesmo que a Microsoft tente destruir chaves com funções como SymCryptSessionDestroy, a chave pode permanecer no heap; por isso, a depuração em nível de kernel é a abordagem mais direta para analisar a implementação do BitLocker

Escopo da demonstração de bypass do BitLocker no Windows 11

  • O alvo é o Windows 11 version 24H2, e o método extrai da memória a FVEK, a chave de criptografia de volume completo do BitLocker
  • Foi usado o aplicativo UEFI Memory-Dump-UEFI para fazer dump do conteúdo da RAM
  • A premissa central é que o invasor consiga ter acesso físico ao dispositivo

Condições para que o dump da RAM funcione

  • A RAM de uma instância do Windows executada recentemente pode conter informações sensíveis como a FVEK
  • Quando a energia é cortada, o conteúdo da RAM se corrompe rapidamente; portanto, é preciso minimizar o tempo em que o computador fica totalmente desligado durante a reinicialização
  • Métodos para reduzir a corrupção da RAM incluem resfriamento físico ou manutenção de uma fonte de alimentação externa; na demonstração, os pinos de reset da placa-mãe foram colocados em curto para reiniciar sem perda de energia
  • Secure Boot é um padrão de segurança que restringe o que pode ser executado na inicialização do dispositivo, mas já houve casos de bypass com shim e similares; esta demo não aborda isso em detalhes

Preparação do USB bootável e criação do dump

  • O USB bootável precisa de um dispositivo de armazenamento maior que a capacidade de RAM do sistema-alvo
  • O script flashimage.sh simplifica a preparação do aplicativo bootável
  • Os procedimentos para criar e usar o aplicativo de boot estão documentados em MemoryDumpUEFI
  • A maior probabilidade de encontrar a FVEK ocorreu ao reiniciar quando o Windows estava carregando, mas antes de a tela de login aparecer
  • Após inicializar imediatamente pelo dispositivo USB com Memory-Dump-UEFI, execute app.efi no UEFI shell
    • O modo de execução tem etapas adicionais no README do aplicativo
    • O tempo de dump varia conforme a quantidade de RAM e a velocidade do dispositivo USB
    • Para evitar gravação no drive errado, é melhor desconectar outros dispositivos de armazenamento USB

Processamento dos arquivos de dump e ferramentas de busca

  • O Memory-Dump-UEFI pode criar vários arquivos de dump
  • Para estar em conformidade com a especificação UEFI, é necessário usar o sistema de arquivos FAT32, que tem limite de tamanho de arquivo de 4 GB
  • concatDumps, no diretório tools, combina vários dumps em um único arquivo em ordem cronológica
  • Como o dump contém os dados brutos que estavam na memória naquele momento, é possível inspecioná-lo de forma mais legível com ferramentas como xxd
  • searchMem pesquisa padrões hexadecimais dentro do dump e permite ir até o offset do local encontrado

Pool tags e localização da FVEK

  • Pool tag é um identificador de 4 caracteres que indica a qual pool de memória do kernel do Windows algo pertence
  • Pools de memória alocados pelo kernel do Windows podem ser bons locais para procurar informações sensíveis
  • pooltag.txt contém uma lista de pool tags e informações sobre a finalidade de cada uma
  • Em versões anteriores do Windows, a localização da chave do BitLocker era diferente
    • No Windows 7, era possível recuperar a chave na pool tag FVEc, correspondente a alocações de criptografia de fvevol.sys
    • No Windows 8.1 e no Windows 10, a chave podia ser encontrada na pool de memória com a tag Cngb, correspondente ao módulo ksecdd.sys
  • Nos dumps do Windows 11, a chave não foi encontrada em FVEc nem em Cngb; em vez disso, a FVEK foi encontrada em dois locais
    • O primeiro fica sob a pool tag dFVE, que representa memória alocada por dumpfve.sys
    • dumpfve.sys está relacionado ao filtro de crash dump de criptografia de volume completo do BitLocker drive encryption
    • A localização dFVE foi o ponto em que a chave foi encontrada de forma mais fácil e consistente
    • Nesse local, a chave era precedida por 0x0480, que indica o tipo de criptografia e, no ambiente da demonstração, significa XTS-AES-128
    • O segundo fica sob a tag None, relacionada a chamadas ExAllocatePool
    • Nesse local, a primeira metade da chave aparecia duas vezes, e a segunda metade uma vez

Acessando o volume BitLocker com a FVEK

  • A chave obtida deve ser precedida pelo valor do algoritmo de criptografia em uso
  • No exemplo, o valor do algoritmo 0x8004 foi prefixado à chave no formato little endian, como 0480
  • O valor resultante pode ser salvo em um arquivo e usado como output.fvek
  • O conjunto de ferramentas dislocker é recomendado para verificar o algoritmo e os valores necessários e para desbloquear a partição protegida pelo BitLocker
  • Se o procedimento estiver correto, é possível acessar os dados do volume protegido pelo BitLocker com output.fvek

Análise da implementação do BitLocker e chaves remanescentes no heap

  • A forma mais direta de entender a implementação do BitLocker é a depuração em nível de kernel usando windbg
  • A depuração de kernel pode ser feita de maneira relativamente simples com uma máquina virtual ou com um cabo USB 3.0 A/A cruzado
  • Acompanhar passo a passo o processo de boot do Windows e observar o comportamento do BitLocker ajudou a encontrar a chave
  • A Microsoft tenta destruir chaves com funções como SymCryptSessionDestroy, mas a chave pode permanecer no heap, de modo que nem todas as chaves são removidas

Links de referência

Leituras relacionadas

1 comentários

 
GN⁺ 2025-01-01
Opiniões no Hacker News

  • Vejo o BitLocker como tendo sua maior vantagem ao usar TPM (PCR 7+11)+PIN
    Sem o PIN, não deveria ser possível ler a FVEK, então isso poderia mitigar esse ataque; e, se o BitLocker foi implementado corretamente, quando o PIN é digitado errado muitas vezes, o TPM entra em modo de bloqueio contra ataques de dicionário
    Há meses venho tentando fazer a mesma configuração no Linux, mas systemd-cryptsetup/cryptenroll é para LUKS, e meu caso é criptografar alguns diretórios sensíveis (chaves de secure boot e /home) com fscrypt em um eMMC interno lento
    Quando se passa do básico, sinto que programar TPM é extremamente difícil: vincular ao PCR 7, vincular ao PCR 11 que muda a cada atualização de kernel/init/cmdline, usar PIN em vez de AuthValue, usar a mesma política de autorização para zerar o contador de bloqueio DA no login, mantendo também uma senha longa/AuthValue para redefinição manual, e ainda fazer bater a assinatura do PCR 11 e a chave pública fornecidas pelo systemd-stub
    Fora guias básicos de TPM, quase não há material; se houver algum especialista, eu gostaria de ajuda. É um projeto pessoal, mas se um dia eu terminar, pretendo escrever sobre isso

    • Lembro que o LUKS tem vários slots de chave, então dava para usar um slot para desbloqueio via TPM e outro para recuperação com senha longa
      Vale considerar esse método como mecanismo de recuperação
      Um dos motivos de haver pouca gente mexendo com TPM open source por hobby é que existem muitas alternativas que resolvem desejos parecidos com muito menos dificuldade
      Se você quer vincular chaves criptográficas importantes ao hardware, basta comprar uma Yubikey; se a senha de criptografia de disco do notebook é incômoda, use o modo de espera ao fechar a tampa em vez de desligar completamente
      Se a senha de login incomoda, há leitores de impressão digital ou Yubikeys com autenticação biométrica; e, se for preciso inicializar sem senha, como em um quiosque sem supervisão ou laboratório de informática de escola, coloque o equipamento em uma caixa de metal resistente e prenda-o à parede com uma corrente
      Se um servidor de datacenter precisa inicializar sem supervisão, leve-o para um datacenter com segurança física confiável; e, se ainda estiver preocupado, faça com que ele só inicialize quando estiver na rede correta, usando Dropbear ou Tang
      Se você está mexendo com TPM em um homelab por hobby, é bom verificar se trabalhar com TPM é mesmo divertido; é bem provável que descubra que não é
    • Mesmo que o TPM exija um PIN para obter a FVEK pela primeira vez, o Windows no fim das contas vai manter a FVEK na RAM
      Caso contrário, não seria preciso digitar o PIN toda vez que um bloco de disco fosse descriptografado? O impacto de desempenho de chamar o TPM a cada operação de disco também seria grande
      Como esse ataque lê a chave da RAM, não entendo como o PIN do TPM seria uma mitigação
    • Acho que talvez fosse melhor usar criptografia com chave dividida ou uma chave secreta criptografada
      Se você digitar uma senha antes da inicialização e essa senha tiver de ser combinada com uma chave do TPM para abrir a unidade, isso ajuda em um cenário posterior em que a chave do TPM seja descoberta
      Dito isso, é difícil ter certeza de quanto cada medida ajudaria contra esse ataque. Para o SO manter acesso de leitura/gravação à unidade, ele precisa guardar a chave em algum lugar; então, se apenas mudarmos onde a chave fica, a recuperação desse tipo de dado da RAM será possível na maioria dos cenários
      Pelo que lembro, nos dispositivos Apple a chave não sai da área segura (enclave), então eles provavelmente não são vulneráveis a esse ataque. O TPM 3.0 parece precisar ficar muito mais próximo disso
    • Acho que a senha de power-on do BIOS também deveria funcionar. Sem ela, o sistema não chegaria ao ponto em que o TPM libera a FVEK
      Em ThinkPads, é possível usar impressão digital em vez de senha de power-on, e isso pode tornar o aparelho praticamente inútil para um ladrão, então prefiro essa configuração ao PIN do BitLocker
      Claro que a senha de power-on e a autenticação por impressão digital são tão fortes quanto o TPM, mas o BitLocker TPM+PIN também não é assim?
    • O TPM me parece uma espécie de honeypot
      A migração para TPM depois de softwares de criptografia open source bem-sucedidos me parece estranha. Soa como: existe um armazenamento superseguro fornecido por grandes empresas, então não se preocupem nem façam perguntas
      Suspeito que necessariamente exista um backdoor que permita a agências de inteligência baixar todos os PINs e senhas e acessar os dados

  • Fundamentalmente, não entendo muito bem o modelo de segurança do BitLocker
    Na maioria das instalações, parece que basta apertar o botão de energia para inicializar no Windows
    Então, se alguém roubar um dispositivo com um disco rígido criptografado, basta ligá-lo? Imagino que não seja assim, mas ao mesmo tempo não sei como esse ataque específico é impedido
    Acho que devo presumir que o tráfego do barramento SPI é criptografado e que a chave não pode ser despejada desse jeito, mas, de qualquer forma, parece que a máquina entrega a chave com bastante facilidade
    O LUKS pelo menos tem um prompt de senha para desbloquear a unidade

    • O tráfego do barramento SPI não é criptografado
      Curiosamente, a Microsoft não usa criptografia de parâmetros do TPM e, por isso, a cada um ou dois anos algum pesquisador de segurança monta e demonstra um dispositivo de sniffing de TPM
      O LUKS também depende da configuração. O Linux também pode ser configurado aqui da mesma forma que o Windows, e eu configurei assim meu servidor doméstico de segurança por vídeo porque ele precisa reiniciar silenciosamente. Sei que ele fica vulnerável a ataques de boot a quente/frio e à superfície de ataque de software, mas, se alguém simplesmente retirar a unidade, ela estará segura
      O Windows também pode ser configurado para exigir uma senha ou para usar uma chave selada pelo TPM com autenticação por PIN
      Tirando a criptografia de parâmetros e o problema de sniffing do barramento, o BitLocker desloca o limite de “qualquer um consegue ler a unidade” para “é preciso fazer um ataque em nível de plataforma para obter o conteúdo da memória ou hackear serviços que rodam na tela de login”
      Como ele impede muito bem situações como roubo de dados financeiros de discos rígidos reutilizados aleatoriamente, na prática é uma melhoria de segurança bem razoável
    • Se você ligar um dispositivo roubado, ele só chega até a tela de login, e não passa daí sem senha ou autenticação biométrica
      É preciso algum desvio, como uma vulnerabilidade de execução remota de código ou inicializar com um bootloader antigo e vulnerável do Windows. Como a unidade está bloqueada, aquele desvio comum de “trocar o teclado virtual por cmd.exe” não funciona
      Sem BitLocker, você pode conectar a unidade do Windows em outro PC e ver todos os arquivos. Com BitLocker, é preciso lidar com software vulnerável da Microsoft, falhas, memória despejada e coisas do tipo — e mesmo assim nem sempre funciona
      Se configurar o BitLocker no modo TPM+PIN, nem isso dá para fazer, porque não há senha para abrir o TPM. Também é possível deixar o BitLocker em modo somente senha, mas isso é muito mais vulnerável a força bruta
      O LUKS é parecido: hoje em dia, a maioria das distribuições Linux oferece suporte a TPM e TPM+PIN
    • Correto, mas a ideia é que, na tela de login (winlogon), praticamente não há nada que se possa fazer de fato sem ter credenciais de uma conta daquele computador ou biometria cadastrada
      Se você tentar reiniciar em modo de segurança, em outro SO, em um utilitário de atualização de firmware etc., será necessário informar a chave de recuperação do BitLocker
      Não sei bem como funciona internamente o caso de “hackear” um sensor de impressão digital ou uma webcam de reconhecimento facial
    • O principal objetivo de usar o BitLocker com PIN+TPM é transformar um computador desligado, ou a própria unidade, em um tijolo
      É preciso assumir que o TPM não tem vulnerabilidade de extração de chave
      O ponto central é quando ele está desligado
      Em criptografia de unidade de uso geral, o TPM é lento demais para descriptografar os dados em massa de fato; no fim, o SO acaba tendo uma chave que pode ser extraída
    • Volumes BitLocker podem ter vários protetores e podem usar arquivo de chave, frase secreta, PIN e armazenamento no TPM: https://learn.microsoft.com/en-us/windows-server/administrat...
      Na edição Pro, também é possível exigir uma etapa interativa na inicialização via Política de Grupo. Funciona mesmo sem TPM e, nesse caso, pede a senha a cada inicialização

  • Isto pode ser completamente impedido por https://trustedcomputinggroup.org/resource/pc-client-work-gr...
    Quando ativado, se o SO não foi encerrado normalmente e portanto não teve chance de apagar as chaves de criptografia, o firmware para antes da próxima inicialização e limpa a RAM
    Fico curioso se o Windows não usa isso ou se o sistema testado não o implementava

    • Sabe-se que o Windows usa esse recurso: https://learn.microsoft.com/en-us/windows/security/operating...
      Lá diz que “o BitLocker usa a TCG Reset Attack Mitigation, também conhecida como bit MOR (Memory Overwrite Request), antes de extrair chaves para a memória”
      Dito isso, não confio nem um pouco na maioria das implementações de plataforma. Nunca vi uma plataforma UEFI que chegasse perto de implementar isso direito, de qualquer forma
      Seria interessante saber qual plataforma esse pesquisador usou e se ela afirma oferecer suporte ao bit MOR
    • Essa mitigação é bem capenga, porque dá para interferir até durante a sobrescrita da RAM
      Basta ver como a Team Tweezers explorou o Wii original
      A mitigação de verdade é o recurso de criptografia de memória das CPUs modernas. Como fica dentro do die, uma pinça não alcança; basta apagar a chave, então a remoção é instantânea e é muito difícil interferir mesmo que ela tenha sobrevivido a um ciclo de energia
    • Ainda assim, isso não impede remover o módulo de RAM inteiro e despejá-lo offline
      Idealmente, a chave deveria permanecer apenas dentro do cache SRAM da CPU e nunca sair do die da CPU

  • Sou a pessoa que escreveu o post. Se tiverem perguntas, podem me mandar mensagem por esta conta
    Foi um trabalho muito divertido, e agradeço pelo grande interesse

  • Apresentação da 38C3 relacionada ao bypass do BitLocker no Windows 11: https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...

  • É bastante sabido que o BitLocker só protege adequadamente um computador desligado, e mesmo assim apenas quando está configurado para exigir uma senha de inicialização
    [0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...

  • O Windows tem uma opção de criptografia de memória proposta junto com a compactação de memória
    Tanto a Intel quanto a AMD estão trabalhando para colocar esse recurso nas CPUs
    Porém, o alvo parece ser servidores que executam várias máquinas virtuais, não notebooks

    • A Microsoft está migrando cada vez mais para a segurança baseada em virtualização, incluindo a capacidade de executar “enclaves” para proteger partes específicas de software: https://learn.microsoft.com/en-us/windows/win32/trusted-exec...
      Não seria surpreendente se, em breve, “máquinas virtuais” criptografadas fossem usadas como meio de armazenar esses segredos. O que falta é suporte de hardware amplamente comum em plataformas de consumo
      No entanto, ataques anteriores por canal lateral em CPUs mostraram que até memória criptografada pode ser atacada (https://www.usenix.org/conference/usenixsecurity21/presentat...). Eles miram o cache quando a CPU descriptografa a memória para operar normalmente
      Isso ajudaria a neutralizar dumps de memória, mas RAM criptografada não acabaria com o despejo de chaves da memória. Especialmente contra atacantes pacientes ou altamente qualificados
    • A Intel atualmente oferece isso como Total Memory Encryption. No ecossistema Windows, apropriadamente, o foco é em máquinas virtuais
      https://techcommunity.microsoft.com/blog/windowsosplatform/m...
      A compactação de memória existe há muito tempo, pelo menos desde o Windows 10 RTM. Todos os principais sistemas operacionais implementaram esse recurso, mas ele não tem relação com segurança

  • Artigo relacionado: burlando o BitLocker em notebooks Lenovo com um analisador lógico barato
    https://news.ycombinator.com/item?id=37249623

  • Em ataques que dependem de ler o dump de memória da máquina-alvo, fico curioso sobre o quão realista seria, com acesso físico, usar um dispositivo interposer que copiasse ou modificasse os dados que entram e saem da RAM
    Penso em algo como o antigo “Action Replay” para Gameboy, que permitia cheats modificando a memória carregada ou executada do cartucho do jogo para o sistema. Você encaixava o cartucho no Action Replay e o Action Replay no Gameboy
    Seria possível fazer algo parecido entre a RAM e a placa-mãe? Encaixar a RAM no dispositivo, encaixar o dispositivo na placa-mãe e então observar leituras/gravações de memória para capturar o estado da memória em um momento arbitrário
    Assim seria possível evitar o incômodo de desligar manualmente e torcer para que os dados necessários ainda estejam lá
    Não sou engenheiro elétrico, então talvez a proposta seja completamente impossível. As limitações de espaço físico e largura de banda certamente parecem grandes, mas seria possível?

    • Em teoria, é possível. Na prática, ao estabelecer um link DDR, há muita negociação entre o controlador de memória e a RAM, e não é fácil criar uma situação em que os dados sejam despejados mantendo os mesmos timings
      É difícil esperar que surja uma solução pronta de mercado
    • CPUs AMD/Intel modernas dão suporte à criptografia total de memória transparente, portanto esse tipo de interposer veria apenas os dados criptografados da RAM

  • Pouca gente sabe que CPUs Intel/AMD lançadas nos últimos anos dão suporte à criptografia total de memória transparente
    O conteúdo da RAM é criptografado com uma chave aleatória armazenada dentro do controlador de memória da CPU e gerada no reset
    Normalmente isso vem desativado no BIOS, porque há uma pequena perda de desempenho de memória (0,1%~1%)
    Mas esse ataque poderia ser bloqueado completamente

    • Pelo que entendi, na AMD esse recurso é chamado SME(Secure Memory Encryption), e na Intel, TME-MK(Total Memory Encryption-Multi Key)