Ataques 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.

Conteúdo

• Ataques de hardware
• Ataques de software

Ataques de hardware

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.

Ataques de software

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.

dangerous association

Um sistema vulnerável terá as atualizações de maio de 2022 ou junho de 2022 instaladas, mas não quaisquer atualizações posteriores.

O GUID das opções associadas faz parte dos dados com hash, portanto o elemento do dispositivo usado deve ser marcado como não verificado.
Não há elementos que possam ser usados no Windows 7 e anteriores (embora, quando configurações personalizadas fora do padrão forem usadas, isso ainda possa ser possível).
No Windows 8 e superiores, osloader!osdevice não é verificado por padrão e, como tal, pode ser usado.
A maneira mais fácil de explorar isso é usar o editor de dispositivos raw do BCD, bcdeditmod, embora editar manualmente o hive do registro BCD também seja possível (descubra você mesmo).

A exploração envolve:

• obter o BCD do dispositivo de destino e criar dois elementos de dispositivo
• copiar o osdevice de {default} para o primeiro
• definir o GUID de opções associadas em {default}!osdevice para o primeiro elemento de dispositivo
• definir o GUID de opções associadas em {first}!osdevice para o segundo elemento de dispositivo
• definir quaisquer opções "perigosas" (como debug) no segundo elemento de dispositivo
• inicializar o dispositivo de destino usando esse BCD e o mesmo binário bootmgfw que ele estava usando

bitpixie

Esta vulnerabilidade existia há mais de 17 anos; a compilação conhecida mais antiga em que foi introduzida é 6.0.5231.2 (winmain_idx03.051004-2120), de outubro de 2005.
Quando a validação de integridade do Secure Boot é usada, um ataque de downgrade ainda funcionaria para explorar esta vulnerabilidade.Set up a PXE boot server with a vulnerable bootmgfw.efi (where legacy integrity validation is used, this must be the bootmgfw.efi from the target device) renamed correctly for EFI booting.

For the BCD, set up one default entry where device is the BitLocker encrypted osdevice; path is "\"; and a recovery sequence.

The recovery sequence should point to a single startup entry, where device is boot, path points to an EFI application to run (from the PXE server); and pxesoftreboot is enabled.

When Secure Boot is disabled, that EFI application can just be an application to scan physical memory looking for a BitLocker keytable to dump.

When Secure Boot is enabled, that EFI application can use a known Secure Boot bypass (where physical access is required if needed).
For exploiting a Windows boot application in this way, you will need to replace the BCD with your second one on the PXE server.
This means pressing an arrow key during bootmgr startup to force the boot menu to show; and then replacing the BCD on the PXE server at that point.

push button decrypt

Exploitation involves:

• Dump the bitlocker protected osvolume to a disk image. This method to get the FVEK leads to actual data loss!
• Boot to WinRE using whatever means (force it by startup repair if needed, or just set bootsequence BCD element, etc).
• Start a reset (Troubleshoot -> Reset this PC -> Remove everything). It's quicker to choose "Local reinstall". Be sure to choose "Just remove my files".
  • Choosing to "keep files" will ask for recovery key.
  • If the system's WinRE is not vulnerable, it will also ask for a recovery key.
• When the reset gets to ~98%, shut the system down forcefully (via holding power button down 7 seconds / etc).
• Power the system back on, it should boot to WinRE again and show an error. Dismissing the error should reboot.
• When you see the blue "updating" screen, press Shift+F10 to get to a shell.
• Execute manage-bde -pause C: followed by manage-bde -protectors -delete C:
• Shut the system down forcefully (again).

At this point, the on-disk BitLocker metadata will contain a plaintext VMK.
Dump it, and use that VMK to decrypt the FVEK.
The decrypted FVEK can be used on the disk image made previously to decrypt the partition.

Please note: I only successfully exploited this issue on Windows 10 in very specific circumstances (TPM-only BitLocker with no recovery key). However, others have successfully exploited this issue using a vulnerable WinRE on Windows 11 (Nickel).

ram leak

As far as I am aware, this vulnerability has existed as long as the boot manager has - it appears to be present as early as 6.0.5098.0 (winmain_beta1.050628-1740) from June 2005, although that pre-dates the BCD so exploitation would be different in builds that early. Relevant code seems to also exist earlier too (the ramdisk-related code appears to be the same in build 5048 from April 2005), but build 5098 is the earliest dumped build with BitLocker present in some form.

To exploit this, you need to set up a default entry and a recovery sequence like in bitpixie. This is to so the keys are derived for the OS device when the file is loaded.

The recovery sequence must have an additional device entry to set up the ramdisk. Use bcdeditmod for this. Use a custom element here like custom:21100000. An example of a device entry to use here would be !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]] - you'd want to replace the part2 block device here with the one from your target system's BCD.

The file can then be dumped out of memory using whatever method that works for you. I prefer to use older winload into self-signed mcupdate via advanced options menu, but other options are available (PXE soft reboot into a third party operating system for example; memory dumping from WinPE by using a bugcheck or a known vulnerable driver is possible, but winload will mark the memory area as free in the NT memory map so it might get overwritten without some other settings to mark that memory as bad/etc in winload).

A proof of concept implementation of my preferred method is included in this repository as ramleak.zip. Read the included readme for usage instructions.

Shout out to Maxim Suhanov, this was inspired by reading CrashXTS writeup and figuring out some other way to possibly dump hiberfil.sys.

And now for my own thoughts, about this bug and about yellowkey:

This was the first time I had a real issue with submitting to MSRC, and was mainly a misunderstanding from their side related to Secure Boot. Given that other bitlocker 0day being dropped I decided to release this now, I've been sitting on this for almost a year now wondering what to do with it.

Unlike yellowkey, I won't make overblown calls about this being a "backdoor", in my opinion I don't think yellowkey is a backdoor, the related component is to do with WinPE (not WinRE-specific), and the main "vuln" there is getting winpeshl.ini deleted to reach that codepath, I can totally understand why MS thought deleting it in a WinRE+bitlocker scenario wasn't possible.

Given that loading a ramdisk from a bitlocker encrypted partition is actually a feature in the boot environment, although I had to use an existing trick to actually get it to work, other people could also say this was a backdoor if they wanted, but I'm not going to go that far. The boot environment is complex (and keeps getting bigger, latest bootmgfw_ex.efi no longer fits in a 2.88MB image - end of an era), several vulns have been discovered because of how certain features interact with each other.