baton drop (CVE-2022-21894): Vulnerabilidade de Bypass do Recurso de Segurança do Secure Boot

As Aplicações de Inicialização do Windows permitem a configuração truncatememory para remover blocos de memória contendo intervalos "persistentes" de dados serializados do mapa de memória, levando a um bypass do Secure Boot.

• O elemento BCD truncatememory removerá toda a memória acima de um endereço físico especificado do mapa de memória.
• Isso é realizado para cada aplicação de inicialização durante a inicialização, antes da política serializada do Secure Boot ser lida da memória.
• Portanto, tal elemento pode ser usado para remover a política serializada do Secure Boot do mapa de memória.
• Isso permitirá que configurações perigosas sejam usadas em uma aplicação de inicialização (bootdebug, testsigning, nointegritychecks), quebrando assim o Secure Boot.

Este problema foi corrigido por duas alterações diferentes:

• Após tentar carregar uma política serializada do Secure Boot, se nenhuma política foi carregada, e o Secure Boot está ativado, e a aplicação de inicialização não foi carregada diretamente pelo firmware UEFI, e a aplicação de inicialização não é o bootmgr, a inicialização da aplicação de inicialização falha.
• Ao carregar uma aplicação de inicialização, se ela tiver um recurso VERSIONINFO contendo um OriginalFilename, se esse nome de arquivo estiver incluído em uma lista de bloqueio (contendo bootmgr.exe e hvloader.exe; no Nickel, hvloader.efi foi adicionado, mas isso não foi backportado), o carregamento falha.
  • No Windows 8 e Windows 8.1, o hvloader.exe não está incluído na lista de bloqueio do winload - originalmente estava, o que quebrou o carregamento do Hyper-V!
  • Desde o Windows 10 versão 1809, se um determinado bit de flags estiver definido (usado com o elemento flightedbootmgr para carregar o bootmgr do disco), o OriginalFilename é obrigado a ser bootmgr.exe.

Exploração

O atacante precisa garantir que a Política de Secure Boot serializada seja alocada acima de um endereço físico conhecido.

• Por padrão, ela é alocada no menor endereço possível.
• Originalmente, a Política de Secure Boot serializada é alocada após ser carregada, antes de usar qualquer configuração carregada do BCD.
  • Desde o RS1, a Política de Secure Boot serializada é alocada ao carregar uma aplicação de inicialização.
  • Desde o RS2, qualquer Política de Secure Boot serializada existente é liberada ao serializar uma Política de Secure Boot.
• A Política de Secure Boot serializada é realocada se, ao carregar uma aplicação de inicialização, o osdevice da entrada BCD for uma partição criptografada pelo BitLocker onde o VMK foi derivado usando o TPM.
  • Isso pode ser falsificado definindo o bit 0 dos flags da chave após o desbloqueio bem-sucedido do TPM; este bit pode ser definido manualmente nos metadados do BitLocker, com metadados adicionais adicionados para especificar que o Secure Boot está sendo usado para validação de integridade.

O elemento avoidlowmemory pode ser usado para garantir que todas as alocações de memória física estejam acima de um endereço físico especificado:

• Desde o Windows 10, este elemento não é permitido se o VBS estiver ativado, mas como é usado durante a inicialização da aplicação de inicialização, antes da política serializada do Secure Boot ser lida da memória, carregar o bootmgr e especificar um caminho BCD personalizado (usando o elemento bcdfilepath também conhecido como custom:22000023) pode ser usado para contornar isso.
• Se o BitLocker estiver presente no volume do SO, ou o sistema de destino estiver executando TH1 ou TH2, então este método falhará; portanto, também é possível executar o ataque uma vez com um bootmgr do Windows 8.x para desabilitar o VBS e depois trocar de volta para o bootloader original.
  • O Windows 10 alterou a inicialização da aplicação de inicialização para bloquear todos os PCRs do TPM uma vez, então um bootmgr do Windows 8.x falhará ao desbloquear o VMK em um sistema Windows 10+.

O hvloader.efi pode ser carregado com o elemento nointegritychecks para carregar um mcupdate.dll autoassinado, cujo ponto de entrada será chamado antes do ExitBootServices.

Alternativamente, em sistemas não AMD64, o winload.efi anterior ao TH2 pode ser usado com o elemento testsigning; isso permite binários autoassinados com o EKU szOID_NT5_CRYPTO no certificado.

Em sistemas ARMv7, carregar um hal.dll autoassinado e modificado com uma importação para mcupdate.dll será necessário para obter execução de código.

Em sistemas x86 e AMD64, o arquivo carregado como mcupdate.dll deve ser nomeado mcupdate_*.dll, onde * é a string do fabricante da CPUID (GenuineIntel, AuthenticAMD, etc).

Em sistemas ARM64, esta técnica não pode ser usada devido ao build de produção assinado mais antigo disponível ser um WinPE do RS2; portanto, atualmente apenas a execução de código atrelada pode ser realizada (usando bootdebug).

Arquivos incluídos

Este repositório inclui os seguintes arquivos:

• O código-fonte para um payload simples é fornecido. Este payload apenas espera por uma interrupção infinitamente, pois sem encontrar funções e variáveis interessantes na aplicação de inicialização chamadora, é impossível fazer qualquer outra coisa.
  • Como o mcupdate.dll é executado em um endereço virtual com paginação ativada, é impossível chamar funções EFI diretamente (a paginação precisa ser desabilitada para chamar funções EFI, retornar a um endereço virtual com paginação desligada não leva a um bom resultado).
  • Para chamar funções EFI, um payload precisaria chamar BlImgLoadPEImageEx ou BlImgLoadPEImageFromSourceBuffer com o bit 0 definido nos flags para carregar um payload adicional em um mapeamento 1:1 de endereço físico para endereço virtual.
    • Alternativamente, pode chamar BlImgAllocateImageBuffer com o mesmo bit definido para alocar memória em um mapeamento 1:1 de endereço físico para endereço virtual; depois carregar um payload ele mesmo (ou se remapear lá).
• Um ISO que explora este problema no AMD64 usando o bootmgfw do Windows 8 RTM e o hvloader do TH1 RTM.
  • O payload usado aqui imprime uma mensagem na tela usando uma função do hvloader obtida por offset e depois loop infinito.
• Um ISO que explora este problema no AMD64 usando o bootmgr do RS1 e o hvloader do TH1 RTM.

Pós-escrito

Este problema pode ser usado para despejar chaves do BitLocker (onde o Secure Boot é usado para validação de integridade).

• Embora seja possível, o método exato de obter execução de código com chaves do BitLocker derivadas para um volume arbitrário na memória não será divulgado.

A correção para este problema também corrigiu outro problema que não possui CVE.

• O bootmgr ignora qualquer keytable do BitLocker já na memória e aloca uma nova, sem limpar a antiga.
  • Portanto, um atacante poderia carregar o bootmgr do RS2+ a partir do bootmgr (especificando um osdevice arbitrário onde o Secure Boot é usado para validação de integridade), inicializar no WinPE, carregar um driver vulnerável conhecido e usá-lo para procurar e despejar a keytable existente do BitLocker na memória física.

Nenhuma aplicação de inicialização vulnerável conhecida foi revogada ainda.

• Até que a revogação ocorra, um atacante pode simplesmente trazer seus próprios bootloaders vulneráveis.
• A revogação faria com que todas as mídias de instalação/recuperação do Windows existentes e backups antigos falhassem ao inicializar.
  • A falha de inicialização ocorreria mesmo com o Secure Boot desabilitado devido ao bootmgr verificar sua própria assinatura.

Atualização (2023-05-10)

Ocorreu uma revogação incompleta, e outro CVE (CVE-2023-24932). Ainda existem bootmgfws vulneráveis que não foram revogados, além de patches adicionais corrigindo apenas o caso em que o bootmgr carrega o bootmgr. Foi preciso apenas um bootkit colado para a MS agir ;)
Se você for criativo o suficiente, encontrará uma maneira de contornar a revogação de mais de 2000 arquivos bootmgfw ;)