01
 ░██▀█████    ░██▀████     ░▀███████     ░██▌  ░██     ░█▀████     ██     ░▀▀██████
  ░░░██       ░██░░░░█▌    ░██░░░░██     ░███ ░███    ░██░░░░██   ░██     ░██░░░░██
    ░██       ░██   ░█▌    ░██   ░██     ░██ ██░██    ░██   ░██   ░▓█     ░██   ░██
    ░██       ░██████▀     ░████████     ░██ 01░█▀    ░██   ░██   ░█▀     ░██████▀█
    ░█·       ░██   ▀█     ░▓█   ░██     ░▓█   ░██    ░▓█   ░██   ░█▓     ░▓█   ░██
    ░██       ░██   ░█     ░█▓   ░█▓     ░▒    ░█▓    ░░▓   ░▒▓   ░█▓     ░█▓   ░█▓
    ░▓▓       ░▓▓   ░▓▌    ░▓▓   ░▓▒     ░▓▒   ░▓▒    ░▒░   ░▓░   ░▒▒     ░▓▓   ░▓▒
    ░▒▓       ░▓    ░▓▌    ░▓▒   ░▓▓     ░░▒   ░░▓     ░▒████░    ░▓░     ░▓▒   ░░▓
    ░▓░       ░▒░   ░░▌    ░▒░                 ░▓▒                ░░▒     ░▒░   ░▓█
    ░▒▓       ░░▒          ░▒                  ░▒▓                ░▒░     ░▒·   ░▓▒
    ░▒·       ░▒           ░▒                  ░▓                 ░▒░     ░▒▓   ░░▓
    ░▒▒                                        ░▒░                  ░           ░▒·
    ░░░                                          ░                              ░░▒
    ·░░                                                                         ░░░
    ·░░  [+]--------------------------------------------------------------[+]   ·░░
    ░░░   | Era uma vez uma Lótus Negra:                                   |    ░░░
    ░░░   | Uma introdução à UEFI, SecureBoot e à CVE-2022-21894           |    ░░░
    ░░░   | por Mr. Clusterfvck                                            |    ·░░
    ░░░  [+]--------------------------------------------------------------[+]   ░░░
    ░░░                                 ..:..                                   ░░░
    ░░░                            ... ..-#=.. ....                             ░░░
    ░░░                         .-+... .:###=.. ...=-.                          ░░░
    ░░░                     .-##+:.. ..:#####-.. .:+##=..                       ░░░
    ░░░                   .-####*... ..*#####*:. ..+####=..                     ░░░
    ░░░              .... .=######+...+#######+...=######=. ....                ░░░
    ░░░        ..=-...... .=########::#########-:*#######=.. .....--..          ░░░
    ░░░       ..=####+:....-#######+.*##########.=#######=....:+####=.          ·░░
    ·░░        ..*#######+-.:*#####:-###########+:*####*-.:+#######*..          ░░░
    ░░░       . ..*##########+::=#+.#############:+#=::+###########:..          ░░░
    ░░░          .:#############*:.-#############=..*#############:..           ░░░
    ░░░          ..-#############*:+#############+.##############-..            ░░░
    ░░░           ..+############*:*#############*:#############+..             ░░░
    ░░░            ..=###########*:*#############*:############+...             ░░░
    ·░░           ....=##########*:+#############+.###########=...              ░░░
    ░░░        ...-+*#:-##########=-#############=-##########-:**+-...          ░░░
    ░░░  .....=########-:#########*:+###########*.+#########:-########=.....    ░░░
    ░░░   .:*############+.=########+.+#########*:=########=.+############+..   ░░░
    ░░░  ....:+###########=:=#######*.=#######+.+#######+.=###########+:.....   ░░░
    ░░░      ....:+#########=.-*######-.*###*:-######*-.=########*+:....        ░░░
    ░░░          .....:=+*####*=::-==++=..:..=++==-::=*####*+=:....             ░░░
    ░░░             ..........:---:.............:--::..........                 ░░░
    ·░░                               ... . ..                                  ░░░
    ░░░                                                                         ░░░
░░░ Resumo: ·░░ ░░░ ░░░ ░░░ Não muito tempo atrás lá em 2022, Zammis Clark/Wack0[1], um ░░░ ░░░ pesquisador focado em reversing e exploitdev de bootloaders no ░░░ ░░░ Windows (pesquisando pelo nome dele você acha alguns acontecimentos ░░░ ░░░ interessantes ;]) lançou no github uma PoC da CVE-2022-21894, ░░░ ░░░ descoberta por ele. A CVE consiste em um bypass das proteções de ░░░ ░░░ SecureBoot implementadas na UEFI, permitindo que o processo de boot ░░░ ░░░ da máquina afetada possa ser manipulado. ·░░ ░░░ Talvez o que o Wack0 não esperasse (ou esperasse, quem sabe ¯\_(ツ)_/¯) ░░ ░░░ é que um trombadinha virtual, fã de visual novels e da ·░░ ░░░ Hasherezade[2], fosse utilizar seu exploit no desenvolvimento de um ░░░ ░░░ bootkit, dando vida assim ao BlackLotus. Menos ainda que esse ░░░ ░░░ malware funcionaria tão bem, que seria necessário uma nota de ░░░ ·░░ mitigação da NSA[3] pra essa ameaça. Quem diria que com um pouco de ░░░ ░░░ criatividade, um exploit pronto e maldade no coração você consegue ░░░ ░░░ ir tão longe ;]. ·░░ ·░░ Esse simples artigo escrito pelo que vos fala, tem o intuito de ·░░ ░░░ introduzir o funcionamento da UEFI e seus internals de forma ░░░ ·░░ resumida, falar sobre o mecanismo de SecureBoot e trazer uma ░░░ ░░░ explicação da CVE-2022-21894 e como ela foi utilizada pelo ·░░ ░░░ BlackLotus durante sua cadeia de infecção. ░░░ ░░░ ░░░ ░░░ [+]--------------------------------------------------------------[+] ░░░ ░░░ | 0. Em uma galáxia muito distante, nascia a BIOS | ░░░ ░░░ [+]--------------------------------------------------------------[+] ░░░ ░░░ ░░░ ░░░ Dessa vez, muito tempo atrás lá em 1975, Gary Kildall conceitualiza ░░░ ·░░ a primeira BIOS (Bicho Ignorante Operando Sistema? Não! Basic Input ·░░ ░░░ Output System) com o intuito de ser uma implementação de plataforma ░░░ ░░░ de firmware boot, se mantendo como a principal ferramenta do mercado ·░░ ░░░ por 30 anos. A BIOS tem o papel de agir como um “homem do meio” ░░░ ░░░ entre o hardware e o software (esse sendo normalmente o SO), ░░░ ░░░ cuidando do fluxo de dados entre essas partes e realizar as funções ░░░ ░░░ primárias de inicialização da máquina (também podem ser usada para ░░░ ░░░ fazer com que os dados fluam diretamente pra memória de alguns ░░░ ·░░ dispositivos, como GPUs), sendo acessada pelo processador em um chip ░░░ ░░░ EPROM (Erasable Programmable Read-Only Memory), um chip de memória ░░░ ·░░ não volátil que pode armazenar seus dados por até 20 anos. ░░░ ·░░ Sua função básica pode ser resumida com a sigla ICTC (Identificar, ░░░ ░░░ Configurar, Testar e Conectar), e durante o processo de ░░░ ░░░ inicialização da máquina, a BIOS faz as seguintes etapas: ·░░ ·░░ 1. Power On Self Test (POST) - Testa o hardware do dispositivo e ░░░ ·░░ suas conexões para verificar se está tudo devidamente ░░░ ░░░ conectado e funcionando, se tratam de testes elétricos para ·░░ ·░░ verificar se há algum mal funcionamento das peças (lembra ░░░ ░░░ quando você foi ligar seu computador e deu aquele beeeep logo ░░░ ·░░ antes de desligar novamente? isso é o POST avisando que alguma ·░░ ░░░ peça sua está com problema ou mal conectada); ░░░ ░░░ 2. CMOS Setup - Checa informação em uma pequena quantidade de RAM ·░░ ░░░ (64 bytes) localizada na CMOS (Complementary Metal-Oxide ·░░ ░░░ Semiconductor) para fornecer informações detalhadas sobre seu ░░░ ░░░ sistema (como data e hora do sistema, quantidade e tipos de ░░░ ░░░ drives, memória interna,...); ░░░ ░░░ 3. Execução de BIOS de outros dispositivos - Ela executa a BIOS ░░░ ░░░ de outros dispositivos (como GPUs por exemplo, que podem ter ░░░ ░░░ sua própria BIOS); ░░░ ░░░ 4. Identifica o dispositivo de boot - Baseado nas configurações ░░░ ░░░ captadas durante o CMOS Setup, a BIOS identifica os bootable ░░░ ·░░ devices da máquina e sua ordem de sequência; ░░░ ·░░ 5. Identificação e carregamento do MBR na RAM - A BIOS procura ·░░ ░░░ pelo MBR (Master Boot Record) no primeiro setor do dispositivo ░░░ ░░░ de boot (offset físico 0) e então carrega o SO na RAM, baseado ░░░ ░░░ nas configurações do bootstrap code do MBR, inicializando o ░░░ ░░░ sistema operacional da máquina. ░░░ ·░░ ·░░ ░░░ Abaixo tem um exemplo da estrutura de um MBR genérico: ░░░ ░░░ ░░░ ░░░ +-------------+---------------------------------+------------------+ ░░░ ░░░ | Endereço | Descrição | Tamanho (bytes) | ░░░ ░░░ +-------------+---------------------------------+------------------+ ░░░ ░░░ | | | | ░░░ ░░░ | | | | ·░░ ░░░ | | | | ░░░ ░░░ | | | | ·░░ ░░░ | | | | ·░░ ░░░ | 0x0000 | Bootstrap Code Area | 446 | ░░░ ░░░ | | | | ░░░ ·░░ | | | | ░░░ ░░░ | | | | ·░░ ░░░ | | | | ░░░ ░░░ | | | | ░░░ ░░░ | | | | ░░░ ·░░ +-------------+-------------------+-------------+------------------+ ░░░ ░░░ | 0x01BE | Partition Entry 1 | | 16 | ·░░ ░░░ +-------------+-------------------+ |------------------+ ░░░ ░░░ | 0x01CE | Partition Entry 2 | Partition | 16 | ░░░ ░░░ |-------------+-------------------+ Table |------------------+ ·░░ ░░░ | 0x01DE | Partition Entry 3 | | 16 | ░░░ ·░░ |-------------+-------------------+ |------------------+ ░░░ ░░░ | 0x01EE | Partition Entry 4 | | 16 | ░░░ ░░░ |-------------+-------------------+-------------+------------------+ ░░░ ·░░ | 0x01FE | 0x55 | Boot | | ░░░ ░░░ |-------------+-------------------+ Signature | 2 | ░░░ ·░░ | 0x01FF | 0xAA | | | ░░░ ░░░ +-------------+-------------------+-----+-------+------------------+ ·░░ ░░░ | Tamanho total: 512 bytes | ·░░ ░░░ +--------------------------+ ░░░ ░░░ ░░░ ░░░ Vale dizer que existem outros tipos de MBR (como AAP MBR ou NEWLDR ░░░ ░░░ MBR por exemplo) com adições de outras entradas, verificações e até ·░░ ░░░ divisões da área do bootstrap code, mas de forma simples, esse ·░░ ·░░ exemplo é um esqueleto da grande maioria dos MBRs usados desde ░░░ ░░░ antigamente até hoje em dia. Mais na frente a gente vai ver a ░░░ ·░░ diferença entre MBR e GPT, então guardem essa estrutura na cabeça ░░░ ░░░ até lá ;]. ░░░ ░░░ ░░░ ·░░ [*]-----------------------------------[*] ░░░ ░░░ | 0.1 Mas nem tudo são flores… | ░░░ ·░░ [*]-----------------------------------[*] ░░░ ░░░ ░░░ ░░░ Conforme o tempo foi passando, a BIOS começou a apresentar problemas ░░░ ·░░ para a época: ░░░ ·░░ - Suporte de drives limitado: Devido à limitações da época em ░░░ ░░░ que foi desenvolvida, a BIOS suportava somente drives de até ·░░ ░░░ 2.2TB; ░░░ ░░░ - Suporte de drivers guardado em ROM: Fazer atualizações dos ░░░ ░░░ drivers da BIOS era de fato muito trabalhoso devido à seu ░░░ ░░░ suporte ser guardado em uma Read-Only Memory, o que ░░░ ░░░ dificultava a experiência do usuário; ░░░ ░░░ - Rodava em modo 16-bits: Por conta de seu funcionamento em ░░░ ░░░ 16-bits, a interface gráfica era extremamente limitada e ░░░ ░░░ dependia de informações guardadas em outras memórias para ·░░ ░░░ mostrar dados do sistema (como o dia e hora por exemplo); ░░░ ░░░ - Escrita totalmente em ASM: Por ser desenvolvida completamente ·░░ ░░░ em Assembly, fazer atualizações e manter o código era ·░░ ░░░ extremamente trabalhoso e custoso para as fabricantes; ░░░ ░░░ - Adaptada para recursos obsoletos da arquitetura x86: Por mais ░░░ ·░░ que a BIOS fosse atualizada, suas adaptações principais já não ·░░ ░░░ serviam tanto uma vez que foram pensadas em recursos obsoletos ░░░ ░░░ da arquitetura x86. ░░░ ░░░ ░░░ ·░░ Logo, houve uma necessidade por parte das OEMs (Original Equipment ░░░ ░░░ Manufacturers) de melhorar a BIOS para poder suportar as novas ░░░ ░░░ tecnologias que estavam popularizando-se no mercado, foi então que ░░░ ░░░ ao final de 1990, a Intel decidiu iniciar um projeto sobre um novo ·░░ ░░░ sistema que viria a substituir a BIOS como conhecemos: a EFI. ░░░ ·░░ ░░░ ░░░ [+]--------------------------------------------------------------[+] ░░░ ░░░ | 1. E então veio outra explosão… UEFI | ░░░ ░░░ [+]--------------------------------------------------------------[+] ░░░ ░░░ ·░░ ░░░ A EFI (Extensible Firmware Interface) nasceu como uma ideia da Intel ░░░ ░░░ para suceder a BIOS na era moderna, focando principalmente em ░░░ ·░░ melhorar os principais problemas que a BIOS começou a apresentar com ░░░ ░░░ o tempo. Desde o início de sua criação, a EFI sofreu diversas ·░░ ░░░ alterações com o tempo, já começando pelo seu nome, uma vez que a ░░░ ░░░ Intel decide se juntar com outras grandes empresas em 2005 para ░░░ ░░░ fundar o UEFI Forum, ganhando assim a letra U de “Unified” na sua ░░░ ░░░ sigla. A linha do tempo abaixo fala um pouco sobre essas mudanças e ░░░ ░░░ atualizações desde a década de 70 até eventos mais recentes: ░░░ ░░░ ·░░ ░░░ 1975 1990 ░░░ ░░░ Criação da BIOS Mudanças na tecnologia ·░░ ░░░ +--------------------------+ +--------------------------+ ·░░ ░░░ |> Idealizada por Gary | |> 32-bit protected mode | ░░░ ░░░ | Kildall | |> CPUs mais rápidas | ░░░ ░░░ |> Principal implementação | |> Mais memória | ·░░ ░░░ | de firmware boot por | ---> |> Novos dispositivos | ·░░ ░░░ | 30 anos | |> Complexidade máxima da | ░░░ ░░░ |> Closed-source e | | BIOS atingida | ░░░ ░░░ | distribuída em binários | | | ░░░ ·░░ +--------------------------+ +--------------------------+ ·░░ ░░░ _________________________________________| ░░░ ░░░ ↓ ░░░ ·░░ 1998 2005 ░░░ ·░░ Desenvolvimento da EFI Nascimento da UEFI ░░░ ░░░ +--------------------------+ +--------------------------+ ░░░ ░░░ |> Intel começa a | |> Última especificação da | ░░░ ░░░ | trabalhar na EFI para | | EFI (1.10) | ░░░ ░░░ | substituir a BIOS nas | |> Criação do UEFI Forum | ·░░ ░░░ | plataformas Intel-HP | ---> |> Especificação da EFI é | ░░░ ░░░ | Itanium | | contribuída ao Forum | ░░░ ░░░ |> Sua documentação era | | pela Intel | ░░░ ░░░ | restrita à parceiros | |> Criação da UEFI | ░░░ ░░░ +--------------------------+ +--------------------------+ ░░░ ░░░ _________________________________________| ░░░ ░░░ ↓ ·░░ ░░░ 2006 2007 ░░░ ·░░ UEFI 2.0 UEFI 2.1 ░░░ ·░░ +--------------------------+ +--------------------------+ ░░░ ░░░ |> Introdução de mecanismos| |> Autenticação via rede | ░░░ ░░░ | de criptografia e | |> Atualização de | ░░░ ·░░ | segurança | |Arquitetura da UI | ░░░ ░░░ |> Versão 1.0 da Platform |----> | | ░░░ ·░░ | Initialization é | | | ░░░ ░░░ | lançada | | | ░░░ ·░░ | | | | ░░░ ░░░ +--------------------------+ +--------------------------+ ░░░ ·░░ _________________________________________| ░░░ ░░░ ↓ ·░░ ░░░ 2010 2018 ░░░ ░░░ Expansão da UEFI Projeto Mu ░░░ ░░░ +--------------------------+ +--------------------------+ ·░░ ░░░ |> BIOS ainda era o padrão,| |> Microsoft anuncia o | ·░░ ░░░ |mas a UEFI começou a ser | |projeto Mu (um fork do | ░░░ ░░░ |utilizada em massa | |EDKII da TianoCore para o | ·░░ ·░░ |> Diversas implementações | ---> |Surface e o Hyper-V) | ░░░ ░░░ | da UEFI começaram a | | | ░░░ ░░░ | disponibilizar um modo de| | | ░░░ ░░░ | compatibilidade legado | | | ░░░ ░░░ +--------------------------+ +--------------------------+ ░░░ ░░░ ░░░ ░░░ Analisando as atualizações e as funcionalidades adicionadas ao longo ·░░ ░░░ dos anos, temos essa lista resumida: ░░░ ░░░ ░░░ ░░░ 1998 - 2005 2005 - … ·░░ ·░░ EFI UEFI ░░░ ░░░ - Menos limitada comparada à - Interfaces unificadas para ░░░ ░░░ BIOS, mas sem visão de unificação; serviços e programação; ░░░ ░░░ - Adicionou suporte para drives. - Padrão aberto com ░░░ ░░░ maiores que 2TB; implementação em C; ░░░ ░░░ - Permitiu independência de - Adicionou suporte para USB, ░░░ ·░░ arquitetura; PCI/PCIe, SCSI, ACPI e ░░░ ░░░ - Design modular; Networking; ░░░ ░░░ - Retrocompatibilidade via CSM - Implementação de mecanismos ░░░ ░░░ (Compatibility Support Mode). de segurança (SecureBoot e ░░░ ░░░ driver signing); ░░░ ░░░ - Melhor UI; ░░░ ░░░ - Runtime services modernos; ░░░ ░░░ - Shell própria. ░░░ ·░░ ·░░ ░░░ ░░░ ░░░ [+]--------------------------------------------------------------[+] ░░░ ░░░ | 1. UEFI Internals 101 | ░░░ ·░░ [+]--------------------------------------------------------------[+] ░░░ ░░░ ░░░ ░░░ [*]-----------------------------------[*] ░░░ ░░░ | 1.1 UEFI Services | ░░░ ░░░ [*]-----------------------------------[*] ░░░ ░░░ ░░░ ░░░ A UEFI define dois tipos de serviços principais: ░░░ ·░░ - Boot services: Disponíveis somente enquanto o firmware está ·░░ ░░░ sob controle da máquina (tudo antes da chamada da função ░░░ ░░░ ExitBootServices()), como serviços de controle de blocos, ░░░ ·░░ dispositivos e bus, por exemplo. ░░░ ░░░ - Runtime services: Disponíveis também durante o controle do SO, ░░░ ░░░ como serviços de data e hora e acesso de NVRAM. ·░░ ░░░ Alguns desses principais serviços da UEFI são: ░░░ ░░░ - UEFI Memory map ░░░ ░░░ - SMM (espaço de memória usado pelo proc que tem acesso ao OS ░░░ ░░░ mas a recíproca não é verdadeira, bootkits gostam daqui ;]) ░░░ ░░░ - ACPI ░░░ ░░░ - SMBIOS ░░░ ·░░ - Time ░░░ ░░░ - Variables ░░░ ·░░ ·░░ ░░░ Vamos dar um pouco de destaque pro serviço de variáveis listado ░░░ ░░░ acima, onde essas variáveis UEFI (UEFI variables) são usadas como ░░░ ░░░ uma forma de guardar dados em áreas de memória não-volátil. Por ░░░ ░░░ exemplo, variáveis UEFI podem ser usadas para armazenar mensagens de ░░░ ░░░ crash na NVRAM depois de um problema. Aqui um exemplo de variáveis ░░░ ░░░ UEFI em um sistema: ░░░ ░░░ ░░░ ░░░ root@kharon ~# efivar --list ░░░ ·░░ 8be4df61-93ca-11d2-aa0d-00e098032b8c-SignatureSupport ·░░ ░░░ 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder ░░░ ░░░ 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot ·░░ ░░░ a04a27f4-df00-4d42-b552-39511302113d-Setup ░░░ ░░░ 59d1c24f-50f1-401a-b101-f33e0daed443-SecureBootEnforce ·░░ ·░░ 8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndications ░░░ ░░░ 59d1c24f-50f1-401a-b101-f33e0daed443-PhysicalBootOrder ░░░ ░░░ d719b2cb-3d3a-4596-a3bc-dad00e67656f-db ░░░ ░░░ 8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode ░░░ ░░░ 8be4df61-93ca-11d2-aa0d-00e098032b8c-PK ░░░ ░░░ d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx ░░░ ·░░ 8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK ░░░ ░░░ 59d1c24f-50f1-401a-b101-f33e0daed443-CustomSecurity ░░░ ░░░ 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003 ░░░ ·░░ 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0002 ░░░ ·░░ ░░░ ░░░ [*]-----------------------------------[*] ·░░ ░░░ | 1.2 UEFI Applications | ░░░ ░░░ [*]-----------------------------------[*] ░░░ ░░░ ·░░ ·░░ Aplicações UEFI são arquivos guardados em partições EFI (chamadas de ░░░ ·░░ ESPs, a gente vai falar mais sobre essas partições jajá). Essas ·░░ ░░░ aplicações podem ser executadas pela UEFI Shell, pelo boot manager ░░░ ░░░ do firmware ou por outras aplicações UEFI (por sinal, bootloaders, ░░░ ░░░ como o GRUB e o Windows Boot Manager são aplicações UEFI, assim como ░░░ ░░░ a própria UEFI Shell, chame isso de recursão :P). Elas podem ser ·░░ ░░░ desenvolvidas e instaladas manualmente pelos OEMs do SO ou do ░░░ ░░░ hardware da sua máquina. ░░░ ░░░ ░░░ ░░░ [*]-----------------------------------[*] ░░░ ░░░ | 1.3 EFI System Partitions | ░░░ ░░░ [*]-----------------------------------[*] ░░░ ░░░ ░░░ ░░░ As ESPs nada mais são que partições de armazenamento de dados ░░░ ░░░ acessados pelo firmware da UEFI durante a inicialização da máquina, ░░░ ░░░ nelas ficam armazenadas as aplicações UEFI e seus arquivos (como os ░░░ ░░░ bootloaders que a gente comentou). As ESPs suportam os esquemas de ░░░ ░░░ partição MBR e GPT (não o chat, mas a GUID Partition Table), a MBR ·░░ ░░░ sendo suportada como parte do sistema de compatibilidade da BIOS ·░░ ░░░ (CSM). Em suma, a diferença entre as partições GPT e MBR está em sua ░░░ ·░░ arquitetura e na quantidade de partições suportadas: ░░░ ░░░ ░░░ ░░░ MBR (4 partições) GPT (128 partições) ░░░ ░░░ +--------------------------+ +--------------------------+ ░░░ ░░░ | Master Boot Record | | Protective MBR | ░░░ ░░░ +--------------------------+ +--------------------------+ ░░░ ·░░ | Primary Partition (C:). | | Primary GUID Header | ░░░ ░░░ +--------------------------+ +--------------------------+ ·░░ ░░░ | Primary Partition (E:) | | Primary GUID Entry Array | ·░░ ░░░ +--------------------------+ +--------------------------+ ░░░ ░░░ | Primary Partition (F:) | | Primary Partition (C:) | ·░░ ·░░ +--------------------------+ +--------------------------+ ░░░ ░░░ | Extended Partition | | Primary Partition (E:) | ░░░ ░░░ +--------------------------+ +--------------------------+ ░░░ ░░░ | Primary Partition n | ░░░ ·░░ +--------------------------+ ░░░ ░░░ | Backup GUID Entry Array | ░░░ ░░░ +--------------------------+ ░░░ ░░░ | Backup GUID Header | ░░░ ░░░ +--------------------------+ ·░░ ░░░ ░░░ ░░░ [*]-----------------------------------[*] ░░░ ░░░ | 1.4 UEFI Booting | ░░░ ░░░ [*]-----------------------------------[*] ░░░ ·░░ ░░░ ░░░ O boot usando a UEFI é diferente da BIOS, sendo as principais ░░░ ░░░ diferenças a implementação do SecureBoot (que veremos mais pra ·░░ ░░░ frente), uso de operações com velocidade de 64-bits e o abandono de ·░░ ░░░ uso de boot sectors por conta do uso de partições GPT (porém contudo ░░░ ░░░ todavia, boot sectors ainda podem ser utilizados pelo CSM caso o ░░░ ░░░ usuário opte usar partições MBR) no seu disco. Em vez de utilizar ░░░ ░░░ boot sectors, a UEFI define um Boot Manager como mecanismo ·░░ ░░░ principal, checando os dados de configuração de boot (BCD - Boot ░░░ ░░░ Configuration Data, dados esses definidos pelas variáveis que a ░░░ ░░░ gente estudou, armazenadas na NVRAM) e inicializando o bootloader do ░░░ ░░░ SO instalado naquele disco. Aqui um exemplo do fluxo de boot com ░░░ ░░░ UEFI no Windows: ░░░ ░░░ ░░░ ░░░ ░░░ ░░░ +----------------+ ░░░ ░░░ | Máquina ligada | ░░░ ·░░ +-------|--------+ ░░░ ░░░ | ░░░ ░░░ +-------↓--------+ ░░░ ░░░ | Firmware | ░░░ ░░░ | bootloaders | ░░░ ░░░ +-------|--------+ ░░░ ░░░ +- UEFI --------------↓--------------------------------------------+ ░░░ ░░░ | +-----------------+ +-----------------+ | ░░░ ·░░ | | Aplicações UEFI | | Drivers UEFI e | | ·░░ ·░░ | | de OEMs | | serviços | | ·░░ ·░░ | +-----------------+ +-----------------+ | ░░░ ░░░ |+- Ambiente de Boot -|----------------------------------------+ | ░░░ ░░░ || | +-----------------+ | | ░░░ ░░░ || +-------↓---------+ | Bibliotecas de | | | ░░░ ░░░ || | | | Boot | | | ░░░ ░░░ || | Windows Boot | +-----------------+ | | ░░░ ░░░ || | Manager | | | ░░░ ·░░ || | | +-----------------+ | | ░░░ ░░░ || | | | BCD | | | ·░░ ░░░ || +----|------|-----+ +-----------------+ | | ░░░ ░░░ |+-----------------|------|------------------------------------+ | ·░░ ░░░ +------------------|------|----------------------------------------+ ░░░ ░░░ +----------------↓+ +---↓-------------+ ░░░ ░░░ | SO | | Atualizar SO | ░░░ ░░░ +-----------------+ +-----------------+ ░░░ ░░░ ░░░ ░░░ ░░░ ░░░ [*]-----------------------------------[*] ░░░ ░░░ | 1.5 UEFI SecureBoot | ░░░ ░░░ [*]-----------------------------------[*] ░░░ ·░░ ░░░ ·░░ O SecureBoot nasceu como uma medida de proteção contra ameaças que ░░░ ░░░ visavam modificar arquivos e aplicações durante o processo de boot ░░░ ░░░ da máquina, essas ameaças sendo normalmente bootkits e ataques de ░░░ ░░░ recuperação de senha de boot. Em suma, ele impede o carregamento de ░░░ ░░░ UEFI drivers ou aplicações UEFI que não são assinados com uma ░░░ ░░░ assinatura digital, através de várias checagens à cada etapa do ░░░ ░░░ boot. ░░░ ░░░ Quando o SecureBoot é ativado, ele inicia no modo “setup”, ░░░ ░░░ escrevendo uma chave pública mestra conhecida como Platform Key(PK) ·░░ ░░░ no firmware da máquina. Após essa escrita, ele entra no modo “user” ░░░ ░░░ onde apenas UEFI drivers e aplicações UEFI assinados com a PK podem ░░░ ░░░ ser carregados pelo firmware. Key Enrollment Keys (KEKs, aonde estão ·░░ ░░░ meus manos do WoW? XD) também podem ser adicionadas ao banco de ░░░ ·░░ dados de chaves guardado na memória para permitir o uso de outros ░░░ ░░░ certificados (embora essas KEKs possam ser adicionadas por usuários ·░░ ░░░ para testes com certificados auto-assinados, elas ainda precisam ter ░░░ ░░░ uma conexão com a PK para serem válidas). O fluxo de SecureBoot no ░░░ ░░░ Windows funciona da seguinte forma (senta que lá vem história): ░░░ ░░░ ░░░ ░░░ ░░░ ░░░ +----------------+ +---------+ ·░░ ░░░ | Máquina ligada |---+ não +--> | Erro no | ░░░ ·░░ +----------------+ | | | Boot | ░░░ ░░░ ↓ | +---------+ ░░░ ░░░ +----------------+ +----------------+ ^ ·░░ ·░░ | OEM_PK_HASH |-------checa------>| Ta assinado? | -----+ ░░░ ░░░ +----------------+ +----------------+ | ░░░ ░░░ ^ | | ░░░ ░░░ | +----- sim -----+ | ░░░ ·░░ | ↓ | ░░░ ░░░ | +----------------+ +----------------+ | não ░░░ ░░░ | | Bootloaders |----->| Ta assinado? | | ·░░ ░░░ | | Pré-UEFI | +----------------+ | ░░░ ░░░ | +----------------+ | | ░░░ ░░░ | | | ·░░ ░░░ | +----- sim -----+ | | ░░░ ░░░ | ↓ | ░░░ ░░░ | +----------------+ +----------------+ | ░░░ ░░░ | | UEFI Boot |-->| Ta assinado? |---------+ ·░░ ░░░ | | Manager | +----------------+ | ░░░ ░░░ | +----------------+ | | ░░░ ░░░ | | | ░░░ ░░░ | | | ░░░ ░░░ | +----- sim -----+ | ·░░ ░░░ | ↓ | ░░░ ░░░ | +----------------+ +----------------+ | ░░░ ░░░ | |Todos os drivers|-->| Ta assinado? |---------+ ░░░ ░░░ | | e apps UEFI | +----------------+ | ·░░ ░░░ | +----------------+ | | ░░░ ░░░ | | | ░░░ ░░░ | +----- sim -----+ | ░░░ ·░░ | ↓ | ░░░ ░░░ | +----------------+ +----------------+ | ░░░ ░░░ | | Windows Boot |-->| BCD Correto? |---------+ ·░░ ░░░ | | Manager | +----------------+ | ·░░ ░░░ | +----------------+ | | | ·░░ ░░░ | sim se não, aplicar | ░░░ ░░░ ↓ | valores de BCD | ░░░ ░░░ +----------------+ | default | ░░░ ░░░ | Chaves UEFI | | | | ░░░ ░░░ +----------------+ ↓ ↓ | ·░░ ░░░ +----------------+ | ░░░ ░░░ | Ta assinado? |---------+ ·░░ ░░░ +----------------+ | ░░░ ░░░ | | ░░░ ░░░ +----- sim -----+ | ·░░ ░░░ ↓ | ░░░ ░░░ +----------------+ +----------------+ | ░░░ ░░░ | Windows |-->| Ta assinado? |-----+ ░░░ ░░░ | Bootloader | +----------------+ ░░░ ·░░ +----------------+ | ░░░ ░░░ | ░░░ ░░░ +----- sim -----+ ░░░ ░░░ ↓ ░░░ ░░░ +----------------+ ·░░ ·░░ | Boot do SO e | ░░░ ·░░ | seus drivers | ░░░ ░░░ +----------------+ ░░░ ░░░ ░░░ ·░░ ·░░ ·░░ Agora que a gente entendeu (ou pelo menos espero que tenha entendido ░░░ ░░░ :P) melhor sobre o SecureBoot, vamos pra parte interessante de fato ░░░ ░░░ :] ░░░ ░░░ ░░░ ░░░ [*]--------------------------------------------------------------[*] ·░░ ░░░ | 2. Baton Drop (CVE-2022-21894) | ░░░ ░░░ | https://github.com/Wack0/CVE-2022-21894 | ·░░ ░░░ [*]--------------------------------------------------------------[*] ·░░ ░░░ ·░░ ░░░ Publicada em 11 de Janeiro de 2022, A CVE-2022-21894 (Baton Drop) ░░░ ·░░ descoberta pelo brilhante Wack0, consiste em um bypass que quebra as ░░░ ░░░ políticas do SecureBoot, permitindo que um atacante manipulasse o ░░░ ░░░ processo de carregamento dessas policies antes delas serem ░░░ ░░░ carregadas na memória da máquina. A vulnerabilidade é baseada e faz ░░░ ░░░ parte de um conjunto de outras CVEs e pesquisas do próprio Wack0 e ░░░ ░░░ outros pesquisadores sobre falhas no processo de SecureBoot (em ░░░ ░░░ março de 2023 ele apresentou uma palestra[4] sobre essas pesquisas e ░░░ ░░░ uma explicação mais detalhada e profunda sobre a exploração da Baton ·░░ ░░░ Drop, que a gente vai ver de forma mais resumida e simples agorinha, ░░░ ░░░ então recomendo fortemente você assistir!!). ·░░ ░░░ Em 10 de Agosto do mesmo ano, o Wack0 sobe no GitHub o disclosure ░░░ ·░░ junto com uma PoC da exploração da Baton Drop, explicando para nós ░░░ ░░░ mortais sobre todo funcionamento dessa vulnerabilidade e como ·░░ ░░░ explorá-la: ░░░ ░░░ ░░░ ░░░ A Baton Drop consiste em abusar de aplicações UEFI vulneráveis no ░░░ ·░░ Windows e configurações armazenadas nos BCDs para remover blocos de ░░░ ░░░ memória contendo dados serializados do memory map, esses dados sendo ░░░ ░░░ a SecureBoot Policy. O atributo truncatememory passado em um BCD, ░░░ ░░░ permite remover toda memória acima de um endereço de memória físico ·░░ ░░░ do memory map antes da SecureBoot Policy ser lida da memória. Dessa ░░░ ░░░ forma, esse atributo pode ser utilizado para remover a policy ░░░ ░░░ serializada do memory map, fazendo com que outros atributos ░░░ ·░░ “perigosos” (como bootdebug, testsigning, nointegritychecks) possam ░░░ ░░░ ser carregados pelo bootloader, assim quebrando o SecureBoot. Para ·░░ ░░░ que a exploração seja efetuada com sucesso, o atacante deve ter ░░░ ·░░ certeza que a policy serializada esteja alocada acima de um endereço ░░░ ░░░ físico conhecido, para resolver essa questão, o atributo ░░░ ░░░ avoidlowmemory pode ser usado para garantir que alocações de memória ·░░ ░░░ física estejam acima de um endereço físico especificado. Além desse ·░░ ░░░ bypass, a UEFI application hvloader.efi pode ser carregada com o ░░░ ░░░ atributo nointegritychecks já mencionado para carregar uma DLL ░░░ ░░░ auto-assinada (mcupdate.dll, cujo entry point é chamado antes da ░░░ ░░░ função ExitBootServices()) para realizar execução de código na ░░░ ░░░ máquina. Essa exploração também permite realizar o dump das chaves ·░░ ░░░ do BitLocker, e embora o método para realização deste não tenha sido ░░░ ░░░ divulgado, o Wack0 falou sobre na palestra que eu citei mais cedo. ░░░ ░░░ ░░░ ░░░ [*]--------------------------------------------------------------[*] ░░░ ░░░ | 3. O mito se torna realidade: BlackLotus | ░░░ ░░░ [*]--------------------------------------------------------------[*] ░░░ ░░░ ░░░ ░░░ “O primeiro bootkit UEFI descoberto ░░░ ░░░ in-the-wild que subverte as proteções de ░░░ ░░░ SecureBoot em sistemas UEFI ░░░ ░░░ 100% atualizados agora é uma realidade” ░░░ ░░░ - Martin Smolár, ESET (traduzido) ·░░ ░░░ ░░░ ·░░ A CVE já havia sido publicada, o exploit divulgado e a Microsoft já ░░░ ░░░ havia lançado um “patch” para mitigar essa falha no Windows, porém, ░░░ ·░░ como o problema envolve aplicações UEFI vulneráveis, mesmo em um ░░░ ░░░ sistema atualizado, o que aconteceria se um atacante criativo ░░░ ·░░ decidisse manualmente injetar essas aplicações vulneráveis no ·░░ ░░░ sistema? Foi então que um pequeno trombadinha virtual chamado ░░░ ░░░ “maxwell187”, anunciou no dia 6 de Outubro de 2022 no eXploit[5], que ░░░ ░░░ estava vendendo um UEFI bootkit com um bypass integrado de ·░░ ░░░ SecureBoot, bypass esse sendo a CVE do Wack0! O nome desse malware? ·░░ ░░░ BlackLotus (onde estão meus manos do Magic?). ·░░ ░░░ ░░░ ░░░ O BlackLotus realmente foi uma surpresa para muitos analistas em ░░░ ░░░ 2022, visto que um malware que subvertia as proteções do SecureBoot ·░░ ░░░ em sistemas UEFI atualizados parecia conto de fadas. Seu impacto na ·░░ ·░░ comunidade foi grande o suficiente para chamar a atenção da NSA, que ░░░ ░░░ até liberou uma nota de mitigação para a ameaça. Aqui eu vou focar ░░░ ░░░ em explicar sobre como o BlackLotus utilizou o exploit desenvolvido ·░░ ░░░ pelo Wack0 na sua cadeia de infecção, mas também vou deixar linkado ░░░ ·░░ um artigo[6] escrito pelo Martin Smolár[7] da ESET sobre uma análise ░░░ ·░░ completa do malware, que pra quem se interessar, recomendo ░░░ ░░░ fortemente a leitura :] ░░░ ░░░ ░░░ ░░░ [*]-----------------------------------[*] ·░░ ·░░ | 3.1 Instalação | ░░░ ░░░ [*]-----------------------------------[*] ░░░ ░░░ ░░░ ░░░ ㄴ Etapa 0 - Instalador ░░░ ░░░ ㄴ O instalador primeiro verifica seus privilégios, e caso ele ░░░ ░░░ esteja com um nível baixo, executa um UAC Bypass[8] para ░░░ ░░░ escalar privilégios; ░░░ ·░░ ㄴ Checa a presença do SecureBoot utilizando a Win32API, caso o ░░░ ░░░ dispositivo não esteja protegido, já inicia a etapa de ░░░ ░░░ persistência; ░░░ ░░░ ㄴ Renomeia o Windows Boot Manager (bootmgfw.efi) para ░░░ ·░░ “winload.efi” e reinicia a máquina (uma forma de backup caso o ░░░ ░░░ processo de exploração seja interrompido ou o operador do malware ░░░ ░░░ deseje desinstalar ele da máquina da vítima). ░░░ ░░░ ㄴ Etapa 1 - Deploy ░░░ ·░░ ㄴ Implanta arquivos em dois diretórios da máquina: ░░░ ░░░ ㄴ ESP:\EFI\Microsoft\Boot\ (ESP UEFI padrão da Microsoft) ·░░ ░░░ ㄴ ESP:\system32\ (ESP criado pelo instalador) ░░░ ·░░ ░░░ ░░░ [*] - Malicioso ░░░ ░░░ [**] - Legítimo, mas vulnerável ░░░ ░░░ [***] - Legítimo e não vulnerável ░░░ ░░░ ░░░ ░░░ +-------------------------------------------------------------------+ ·░░ ░░░ | Diretório | Arquivos | Descrição | ░░░ ░░░ +------------------------+-----------------+------------------------+ ░░░ ░░░ |ESP:\EFI\Microsoft\Boot\|grubx64.efi[*] | BlackLotus bootkit | ░░░ ·░░ +------------------------+-----------------+------------------------+ ░░░ ·░░ |ESP:\EFI\Microsoft\Boot\|bootload.efi[***]|Binário shim assinado | ░░░ ░░░ +------------------------+-----------------+------------------------+ ░░░ ░░░ |ESP:\EFI\Microsoft\Boot\|bootmgfw.efi[**] |Windows Boot Manager (1)| ·░░ ░░░ +------------------------+-----------------+------------------------+ ░░░ ░░░ |ESP:\EFI\Microsoft\Boot\|BCD[*] |BCD do atacante (1) | ·░░ ░░░ +------------------------+-----------------+------------------------+ ░░░ ░░░ |ESP:\EFI\Microsoft\Boot\|BCDR[***] |Backup do BCD da vítima | ░░░ ░░░ +------------------------+-----------------+------------------------+ ░░░ ░░░ |ESP:\system32 |hvloader.efi[**] |WinHypervisor Loader | ·░░ ░░░ +------------------------+-----------------+------------------------+ ·░░ ░░░ |ESP:\system32 |bootmgr.efi[**] |Windows Boot Manager (2)| ░░░ ░░░ +------------------------+-----------------+------------------------+ ░░░ ░░░ |ESP:\system32 |mcupdate.dll[*] |DLL usada no exploit | ░░░ ·░░ +------------------------+-----------------+------------------------+ ░░░ ░░░ |ESP:\system32 |BCD[*] |BCD do atacante (2) | ░░░ ░░░ +------------------------+-----------------+------------------------+ ░░░ ·░░ ░░░ ·░░ ㄴ Etapa 2 - Desativando o HVCI ·░░ ·░░ ㄴ O HVCI (Integridade de Memória/Hypervisor Enforced Code ░░░ ░░░ Integrity) é um recurso da VBS (Segurança Baseada em ░░░ ·░░ Virtualização/Virtualization Based Security) utilizado para ·░░ ░░░ proteção contra manipulações de memória em kernel mode; ░░░ ·░░ ㄴ O instalador define o valor de registro Enabled da chave de ░░░ ░░░ registro do HVCI para 0: ░░░ ·░░ ░░░ ░░░ int DisableHypervisorEnforcedCodeIntegrity() { ·░░ ░░░ KeyHandle = 0i64; ░░░ ░░░ Value = 0; ░░░ ░░░ //\Registry\Machine\SYSTEM\CurrentControlSet\Control\DeviceGuar ░░░ ░░░ d\Scenarios\HypervisorEnforcedCodeIntegrity v0 = ░░░ ·░░ DecryptStr(&unk_140009C30, 0x69u, 1); ░░░ ·░░ RtlInitUnicodeString(&v3, v0); ░░░ ░░░ ObjectAttributes.RootDirectory = 0i64; ░░░ ·░░ ObjectAttributes.ObjectName = &v3; ·░░ ░░░ ObjectAttributes.Length = 48; ░░░ ·░░ ObjectAttributes.Attributes = 64; ░░░ ░░░ *&ObjectAttributes.SecurityDescriptor = 0i64; ░░░ ░░░ result = ZwOpenKey(&KeyHandle, 0xF003Fu, &ObjectAttributes); ░░░ ░░░ if (result >= 0) { ░░░ ░░░ v2 = DecryptStr(&unk_140009D08, 8u, 1); // “Enabled” ░░░ ·░░ RtlInitUnicodeString(&ValueName, v2); ░░░ ░░░ ZwSetValueKey(KeyHandle, &ValueName, 0, 4u, &Value, 4u); ░░░ ░░░ return ZwClose(KeyHandle); // “0” ░░░ ·░░ } ·░░ ░░░ return result; ·░░ ·░░ } ·░░ ·░░ ░░░ ░░░ ㄴ Etapa 3 - Desativando o BitLocker ░░░ ░░░ ㄴ O BitLocker é o recurso nativo de criptografia de volumes do ░░░ ░░░ Windows (o BitLocker está para o Windows como o VeraCrypt está ·░░ ·░░ para o Linux), ele é usado em conjunto da TPM (Trusted Platform ·░░ ░░░ Unset ░░░ ░░░ Module, sem piadinhas dessa vez), que é um criptoprocessador que ░░░ ░░░ realiza funções criptográficas na máquina, criando e armazenando ·░░ ░░░ chaves para confirmar se o SO e o firmware não foram adulterados ░░░ ░░░ enquanto o sistema estiver offline; ░░░ ░░░ ㄴ O instalador caminha por todos os volumes no WMI ·░░ ·░░ (Instrumentação de Gerenciamento do Windows/Windows Management ·░░ ░░░ Instrumentation) namespace Root\CIMV2\Security\ ░░░ ░░░ MicrosoftVolumeEncryption e checa seus status de proteção; ░░░ ░░░ ㄴ Para os volumes protegido pelo BitLocker, ele chama o método ·░░ ░░░ DisableKeyProtectors() com o parâmetro DisableCount alterado para ░░░ ░░░ zero. ░░░ ░░░ ░░░ ░░░ ㄴ Etapa 4 - Reiniciar a máquina ░░░ ░░░ ㄴ ¯\_(ツ)_/¯ ░░░ ░░░ ░░░ ░░░ [*]-----------------------------------[*] ·░░ ░░░ | 3.2 “Dropping the baton” | ·░░ ░░░ [*]-----------------------------------[*] ░░░ ░░░ ·░░ ·░░ ㄴ Exploitation ░░░ ░░░ ㄴ Após reiniciar a máquina, o sistema executa o bootmgfw.efi ░░░ ░░░ implantado pelo instalador; ·░░ ░░░ ㄴ Após a execução do arquivo, ele carrega o primeiro BCD ·░░ ░░░ implantado no diretório ESP:\EFI\Microsoft\Boot\; ░░░ ░░░ ㄴ O Windows Boot Manager segue para carregar o ESP:\system32\ ·░░ ░░░ bootmgr.efi com os elementos do primeiro BCD: ░░░ ░░░ avoidlowmemory:0x10000000 e custom:22000023 (esse argumento ░░░ ░░░ apontando para o segundo BCD guardado no diretório ░░░ ·░░ ESP:\system32\); ░░░ ░░░ ░░░ ░░░ ANTES DA EXPLORAÇÃO ░░░ ░░░ ·░░ ░░░ Windows Boot Manager ·░░ ░░░ -------------------- ·░░ ░░░ identifier {bootmgr} ░░░ ░░░ device partition=\Device\HarddiskVolume2 ░░░ ░░░ path \EFI\Microsoft\Boot\bootmgfw.efi ░░░ ░░░ description Windows Boot Manager ░░░ ░░░ locale en-US ·░░ ░░░ inherit {globalsettings} ░░░ ░░░ default {current} ░░░ ░░░ resumeobject {499d02c2-23e9-11ec-81bc-c8c171fb7d17} ░░░ ·░░ displayorder {current} ░░░ ░░░ tooldisplayorder {memdiag} ░░░ ░░░ timeout 30 ░░░ ░░░ ░░░ ░░░ Windows Boot Loader ░░░ ·░░ ------------------- ·░░ ░░░ identifier {current} ·░░ ·░░ device partition=C: ░░░ ░░░ path \WINDOWS\system32\winload.efi ░░░ ░░░ description Windows 10 ·░░ ·░░ locale en-US ·░░ ░░░ inherit {bootloadersettings} ░░░ ·░░ recoverysequence {499d02c2-23e9-11ec-81bc-c8c171fb7d17} ░░░ ░░░ displaymessageoverride Recovery ·░░ ░░░ recoveryenabled Yes ░░░ ░░░ isolatedcontext Yes ░░░ ░░░ allowedinmemorysettings 0x15000075 ·░░ ░░░ osdevice partition=C: ·░░ ░░░ systemroot \WINDOWS ░░░ ░░░ resumeobject {499d02c2-23e9-11ec-81bc-c8c171fb7d17} ░░░ ░░░ nx OptIn ░░░ ·░░ bootmenupolicy Standard ·░░ ░░░ hypervisorlaunchtype Auto ·░░ ░░░ ░░░ ░░░ DEPOIS DA EXPLORAÇÃO ░░░ ░░░ ░░░ ░░░ Windows Boot Manager ·░░ ·░░ -------------------- ░░░ ░░░ identifier {bootmgr} ░░░ ░░░ description Windows Boot Manager ░░░ ░░░ locale en-US ░░░ ░░░ inherit {globalsettings} ░░░ ░░░ bootdebug No ░░░ ░░░ displayorder {527f84fc-036e-11ec-abb0-005056c00008} ░░░ ░░░ timeout 30 ░░░ ░░░ ·░░ ·░░ Windows Boot Loader ░░░ ·░░ ------------------- ░░░ ░░░ identifier {527f84fc-036e-11ec-abb0-005056c00008} ░░░ ░░░ device boot ░░░ ░░░ path \system32\bootmgr.efi <--- ░░░ ░░░ description RIP the woo ░░░ ·░░ locale en-US ░░░ ░░░ inherit {bootloadersettings} ░░░ ░░░ avoidlowmemory 0x10000000 <--- ░░░ ░░░ bootdebug No ░░░ ░░░ isolatedcontext Yes ░░░ ░░░ custom:22000023 \system32\bcd <--- ·░░ ·░░ ems Yes ░░░ ░░░ ·░░ ·░░ ㄴ O bootmgr.efi executado então carrega o segundo BCD com os ░░░ ░░░ parâmetros truncatememory:0x10000000, nointegritychecks:Yes e ·░░ ░░░ testsigning:Yes; ░░░ ░░░ ░░░ ░░░ Windows Boot Manager ░░░ ░░░ -------------------- ░░░ ░░░ identifier {bootmgr} ░░░ ░░░ description Windows Boot Manager ░░░ ░░░ locale en-US ░░░ ░░░ inherit {globalsettings} ░░░ ░░░ bootdebug No ░░░ ·░░ displayorder {527f84fc-036e-11ec-abb0-005056c00008} ░░░ ░░░ timeout 30 ·░░ ░░░ ░░░ ░░░ Windows Boot Loader ·░░ ░░░ ------------------- ░░░ ░░░ identifier {527f84fc-036e-11ec-abb0-005056c00008} ·░░ ░░░ device boot ·░░ ░░░ path \system32\hvloader.efi <--- ░░░ ░░░ description Hoy la disco se flota ░░░ ░░░ locale en-US ░░░ ·░░ inherit {bootloadersettings} ·░░ ░░░ truncatememory 0x10000000 <--- ░░░ ░░░ avoidlowmemory 0x1000 ░░░ ░░░ nointegritychecks Yes <--- ░░░ ·░░ testsigning Yes <--- ·░░ ░░░ isolatedcontext Yes ░░░ ░░░ osdevice boot ░░░ ░░░ systemroot. \ ░░░ ░░░ ems Yes ░░░ ░░░ ㄴ Devido às opções carregadas do BCD, a política de SecureBoot ░░░ ·░░ foi apagada da memória, permitindo que o bootmgr.efi agora ·░░ ░░░ carregasse outra aplicação vulnerável implantada pelo ░░░ ░░░ instalador: hvloader.efi; ░░░ ░░░ ㄴ Durante sua execução, o hvloader.efi carrega e executa a ░░░ ░░░ mcupdate_*.dll; ░░░ ░░░ ㄴ A DLL executa um MokInstaller integrado, iniciando assim a ░░░ ·░░ fase de persistência e finalizando a exploração do bug. ·░░ ░░░ ░░░ ░░░ hvloader.efi ·░░ ░░░ unsigned __int64 __fastcall BtLoadUpdateDll(__int64 a1, ·░░ ░░░ └►_QWORD *imageEP) { ·░░ ░░░ platform = 0i64; ░░░ ░░░ BtpUpdateDllImagePages = 0i64; ░░░ ·░░ v9[1] = v9; ░░░ ·░░ v9[0] = v9; ░░░ ░░░ // Identifica a plataforma baseada no CPUID ░░░ ░░░ status = BtpIdentifyPlatform(a1, &platform); ░░░ ░░░ if … ·░░ ░░░ mcupdate_filename = *(platform + 16); ░░░ ·░░ if … ░░░ ░░░ // Carrega a imagem do ░░░ ·░░ //<dispositivo> ·░░ ░░░ //:\\<systemroot>\system32\mcupdate_<platform>.dll ·░░ ░░░ status = BtpLayoutImage(mcupdate_filename, v10, &image, v9, ░░░ ░░░ └► &platform, a1, 1); ░░░ ░░░ v7 = *(platform + 0x30); ░░░ ░░░ BtpUpdateDllImagePages = v7; ░░░ ░░░ if (status) { ░░░ ░░░ // Erro, chamar gHvlpInvalidHypervisorImage ░░░ ░░░ (*(a1 + 0x78))(L”\\SystemRoot\\system32\\”, *(platform + 16)); ░░░ ░░░ } else { ░░░ ░░░ image.ImageBase = v7; ░░░ ·░░ BtpProcessImageLoadConfig(v10, &image.ImageBase, v7, 0); ░░░ ·░░ *imageEP = BtpUpdateDllImagePages + image.AddressOfEntryPoint; ·░░ ░░░ } ·░░ ░░░ } ░░░ ░░░ ░░░ ·░░ mcupdate_*.dll ░░░ ░░░ // Verifica se a imagebase do hvloader foi encontrada checando se o ·░░ ░░░ // IMAGE_NT_HEADERS64.OptionalHeader.CheckSum é igual à 0xEC35E ·░░ ·░░ if (*(*(HvloaderImageBase + 0x3C) + HvloaderImageBase + 0x58) == ░░░ ░░░ 0xEC35E) { ░░░ ░░░ EfiImageHandle = *(HvloaderImageBase + 0x113670); ░░░ ░░░ BlpArchSwitchContext = HvloaderImageBase + 0xC550; ░░░ ░░░ if (EfiImageHandle) { ░░░ ·░░ EfiST = *(HvloaderImageBase + 0x1136C8); // achar o ·░░ ░░░ //ponteiro para EFI_SYSTEM_TABLE ░░░ ·░░ if (EfiST) { ░░░ ░░░ // BlImgAllocateImageBuffer ░░░ ·░░ if (((HvloaderImageBase + 0x3CC0C))( ░░░ ░░░ &ImageBase, MINtHdrs->OtionalHeader.SizeOfImage, ░░░ ░░░ └►0xE0000012i64, ░░░ ░░░ 0x424000i64, 0, 1) >= 0 && ░░░ ░░░ ImageBase) { ·░░ ░░░ // Copiar os headers do MokInstaller na ░░░ ░░░ //memória alocada ░░░ ░░░ for (i = 0i64; ░░░ ░░░ i < MINtHdrs->OptionalHeader.SizeOfHeaders, ░░░ ░░░ └►++i) * ░░░ ░░░ (i + ImageBase) = gMokInstallEfiApp[i]; ·░░ ░░░ j = 0; ░░░ ░░░ // Copiar o resto dos dados para memória alocada ░░░ ·░░ for (v1 = MINtHdrs + ░░░ ·░░ └►MINtHdrs->FileHeader.SizeOfOptionalHeader; ░░░ ░░░ j < MINtHdrs->FileHeader.NumberOfSections; ++j) {·░░ ░░░ if… // Copiar o resto dos dados para a memória alocada ░░░ ·░░ } ·░░ ░░░ if (MINtHdrs->OptionalHeader.AddressOfEntryPoint) ░░░ ░░░ // Executar o EntryPoint do MokInstaller ·░░ ·░░ ((ImageBase + ░░░ ·░░ └►MINtHdrs->OptionalHeader.AddressOfEntryPoint))( ░░░ ░░░ EfiI mageHandle, EfiST, BlpArchSwitchContext); ░░░ ░░░ } ░░░ ░░░ } ░░░ ░░░ } ░░░ ░░░ } ·░░ ░░░ ·░░ ░░░ ㄴ Exploração resumida ░░░ ░░░ ░░░ ░░░ bootmgfw.efi ░░░ ░░░ [+] BCD (ESP:\EFI\Microsoft\Boot\) ░░░ ·░░ | ░░░ ░░░ +------> bootgmr.efi ░░░ ░░░ - avoidlowmemory:0x10000000 ░░░ ░░░ - custom: 22000023 ░░░ ░░░ | bootmgr.efi ░░░ ░░░ +----> [+] BCD (ESP:\system32\) ░░░ ░░░ - path: \system32\hvloder.efi --+ ·░░ ░░░ - truncatememory: 0x10000000 | ░░░ ░░░ - nointegritychecks: Yes | ░░░ ░░░ - testsigning: Yes | ░░░ ░░░ | ░░░ ░░░ persistência <------ mcupdate_*.dll <------ hvloader.efi <---------+ ·░░ ·░░ ·░░ ░░░ ㄴ Impacto final do bootkit ░░░ ·░░ Uma vez que o malware executa o exploit e a persistência na máquina ░░░ ░░░ da vítima (vale lembrar que o malware fica localizado no file system ·░░ ·░░ como uma aplicação UEFI), ele procede para funcionar como um HTTP ·░░ ░░░ Loader, mantendo comunicação com servidor de C&C (ou C2, pros mais ░░░ ░░░ chegados). De acordo com o criador, as máquinas infectadas eram ░░░ ░░░ controladas por uma interface web e usadas como bots para o que o ░░░ ░░░ operador daquele malware quisesse usar. Por se tratar de uma ░░░ ░░░ persistência em um nível tão baixo, AVs não seriam capazes de ░░░ ░░░ detectá-lo e removê-lo. ░░░ ░░░ ░░░ ░░░ Mais recentemente (12 de Julho de 2023) o suposto código do ░░░ ░░░ BlackLotus foi vazado no GitHub[9], e embora ele utilize outro ░░░ ░░░ exploit que não o Baton Drop, pesquisadores como o Alex Matrosov[10] ░░░ ░░░ afirmam realmente se tratar do bootkit original, e que as funções de ·░░ ·░░ carregamento da UEFI, infecção e pós-exploração permanecem ░░░ ░░░ inalterados. ·░░ ░░░ ·░░ ░░░ [*]--------------------------------------------------------------[*] ░░░ ·░░ | 4. Agradecimentos e referências | ·░░ ░░░ [*]--------------------------------------------------------------[*] ░░░ ░░░ ·░░ ░░░ Chegamos ao fim deste artigo, e tudo que eu posso falar é obrigado ░░░ ░░░ por ter lido até aqui. Essa pesquisa foi o resultado de pelo menos 3 ░░░ ░░░ meses de pesquisa sobre diversos assuntos que eu nunca sequer tinha ░░░ ░░░ chegado perto de estudar antes, e realmente deu bastante trabalho, ░░░ ░░░ mas como tudo de bom nessa vida, nada vem fácil ;] ░░░ ░░░ “Meses do meu trabalho, pra alguns minutos do seu entretenimento” ░░░ ·░░ ░░░ ░░░ Tem algumas pessoas que eu faço questão de agradecer, tanto pela ·░░ ░░░ inspiração para realizar essa pesquisa quanto por ajuda técnica ░░░ ░░░ durante o processo de estudo: ░░░ ░░░ - rodnt: Se não fosse por você, eu não estaria onde eu tô hoje, ·░░ ░░░ tanto literalmente quanto hipoteticamente. Você confiou em mim ░░░ ░░░ quando ninguém mais confiava e me deu um ponta pé inicial que ░░░ ░░░ eu jamais vou poder retribuir. Não sei o que você viu ou vê em ░░░ ░░░ mim que te faz achar que eu sou digno de tanta ajuda que você ░░░ ░░░ me deu e dá, mas eu prometo que vou continuar estudando pra ·░░ ░░░ ser essa pessoa que você vê em mim :] ░░░ ·░░ - fxo: Você pode achar que não ajudou muito, mas o simples fato ░░░ ·░░ de ter confiado em mim com as ideias pra fazer essa pesquisa ░░░ ░░░ já é uma ajuda imensurável. Por mais que quem tenha feito a ░░░ ░░░ pesquisa fui eu, a ideia dela veio de você, e ter achado que ░░░ ░░░ eu seria capaz de efetuá-la já é muito pra mim. Talvez você ░░░ ░░░ não goste quando as pessoas digam isso, mas você é uma enorme ░░░ ░░░ inspiração pra mim :] ░░░ ░░░ - Wack0: Já começa que se não fosse por você, essa pesquisa não ░░░ ·░░ existiria, uma vez que ela é toda construída nos seus estudos, ░░░ ░░░ mas além disso, durante o processo de análise da CVE, eu ░░░ ░░░ encontrei algumas dificuldade por se tratar de um assunto ░░░ ░░░ completamente novo pra mim, e te pingar no mastodon com ·░░ ░░░ algumas dúvidas sem a mínima expectativa de resposta, você me ░░░ ░░░ respondeu em menos de 5min, respondendo todos os meus ░░░ ░░░ questionamentos e me ajudando a entender melhor a sua ░░░ ·░░ pesquisa. Você não tinha a mínima obrigação de me ajudar, mas ░░░ ░░░ fez mesmo assim no mesmo instante, humilde :D ░░░ ░░░ ░░░ ░░░ Tem bem mais gente que eu gostaria de agradecer e que são tão ░░░ ░░░ importantes quanto os que eu citei aqui, mas se eu fosse citar todo ░░░ ░░░ mundo, dava pra fazer um artigo só disso :] ░░░ ░░░ ░░░ ░░░ [1]https://haqueers.com/@Rairii ░░░ ░░░ [2]https://twitter.com/hasherezade ░░░ ░░░ [3]https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Re ░░░ ░░░ lease-View/Article/3435305/nsa-releases-guide-to-mitigate-blacklotus ░░░ ░░░ -threat/ ·░░ ░░░ [4]https://www.youtube.com/watch?v=U02ClZS8hqw ░░░ ░░░ [5]https://www.bleepstatic.com/images/news/u/1109292/2022/BlackLotus ░░░ ░░░ _promo.png ·░░ ░░░ [6]https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit ·░░ ·░░ -myth-confirmed/ ░░░ ░░░ [7]https://twitter.com/smolar_m || ░░░ ░░░ https://www.welivesecurity.com/en/our-experts/martin-smolar/ ░░░ ░░░ [8]https://book.hacktricks.xyz/windows-hardening/authentication-cr ·░░ ░░░ entials-uac-and-efs/uac-user-account-control ░░░ ░░░ [9]https://github.com/ldpreload/BlackLotus ·░░ ·░░ [10]https://twitter.com/matrosov ░░░ ·░░ [11]https://p.ost2.fyi/courses/course-v1:OpenSecurityTraining2+Arch4 ░░░ ·░░ 021_intro_UEFI+2023_v1/course/ ░░░ ░░░ [12]https://learn.microsoft.com/en-us/windows-hardware/drivers/bring ░░░ ░░░ up/boot-and-uefi ░░░ ░░░ [13]https://eclypsium.com/research/theres-a-hole-in-the-boot/ ░░░ ░░░ [14]https://learn.microsoft.com/en-us/windows-hardware/design/device ░░░ ░░░ -experiences/oem-secure-boot ░░░ ░░░ [15]https://learn.microsoft.com/en-us/windows/security/operating-sys ░░░ ·░░ tem-security/system-security/secure-the-windows-10-boot-process ░░░ ░░░ [16]https://www.binarly.io/posts/The_Untold_Story_of_the_BlackLotus_ ░░░ ·░░ UEFI_Bootkit/index.html ░░░ ·░░ [17]https://uefi.org/ ░░░ ·░░ [18]https://media.blackhat.com/us-13/us-13-Bulygin-A-Tale-of-One-Sof ░░░ ░░░ tware-Bypass-of-Windows-8-Secure-Boot-Slides.pdf ·░░ ·░░ [19]Babar, Y. Hands-on Booting: Learn the Boot Process of Linux, ░░░ ░░░ Windows, and Unix. Apress, 2020. ░░░ ·░░ [20]Yao, J., Zimmer, V. Building Secure Firmware: Armoring the ░░░ ░░░ Foundation of the Platform. Apress, 2020. ░░░ ··░ ░··