CVE-2021-40444 Completamente Armado

Gerador de docx malicioso para explorar CVE-2021-40444 (Execução Remota de Código no Microsoft Office Word), funciona com arquivos DLL arbitrários.

Histórico

Embora muitos PoCs já estejam espalhados pela internet, resolvi tentar armar esta vulnerabilidade, pois o que encontrei disponível carecia de informações valiosas que valessem a pena compartilhar, considerando também que a Microsoft já lançou uma correção para esta vulnerabilidade.

Até agora, os únicos recursos valiosos que vi para criar um gerador totalmente funcional são:

• Blog do Ret2Pwn
• Tweet do j00sean

Os recursos acima descrevem muitos dos requisitos necessários para criar uma cadeia completa. Para evitar repetir muitas informações desnecessárias, vou apenas resumir os detalhes relevantes.

Cadeia de Exploração

1. Docx aberto
2. Relacionamento armazenado em document.xml.rels aponta para HTML malicioso
3. A pré-visualização do IE é iniciada para abrir o link HTML
4. JScript dentro do HTML contém um objeto apontando para um arquivo CAB e um iframe apontando para um arquivo INF, prefixado com a diretiva ".cpl:"
5. O arquivo cab é aberto, o arquivo INF armazenado no diretório %TEMP%\Low
6. Devido a uma vulnerabilidade de Path traversal (ZipSlip) no CAB, é possível armazenar o INF em %TEMP%
7. Então, o arquivo INF é aberto com a diretiva ".cpl:", causando o side-loading do arquivo INF via rundll32 (se este for um DLL)

Requisitos Ignorados

Existem vários requisitos ignorados para que esta exploração funcione, o que fez com que até mesmo bons PoCs, como o do lockedbyte, falhassem.

Talvez ninguém tenha "lançado" explicitamente para evitar que a vulnerabilidade fosse mais explorada. Mas agora está corrigida, então não deve causar muitos problemas divulgar os detalhes.

Arquivo HTML

Conforme este tweet de Will Dormann, o HTML deve ter pelo menos 4096 bytes de tamanho para acionar a "Pré-visualização" dentro do MS Word.

Arquivo CAB

O arquivo CAB precisa ser corrigido em nível de byte para evitar erros de extração e conseguir o ZipSlip:

• filename.inf deve se tornar ../filename.inf
• filename.inf deve ter exatamente <12-caracteres>.inf Na verdade não, o importante é modificar coffCabStart
• CFFOLDER.typeCompress deve ser 0 (não comprimido)
• CFFOLDER.coffCabStart deve ser aumentado em 3 (devido ao '../' adicionado)
• CFFOLDER.cCfData deve ser 2
• CFFILE.cbFile deve ser maior do que todo o CFHEADER.cbCabinet
• CFDATA.csum deve ser recalculado (ou zerado) [OPCIONAL]

A razão para essas restrições são muitas, e não gastei tempo suficiente para entender profundamente todas, mas vamos ver as mais importantes:

• TypeCompress: Se o CAB estiver comprimido, o truque de abri-lo dentro de um objeto para acionar a escrita do INF falhará Falso, consegui o mesmo resultado com uma amostra comprimida em MSZIP
• CoffCabStart: CoffCabStart fornece a posição absoluta da primeira estrutura CFDATA; como adicionamos um '../', precisaríamos aumentar em 3 para apontar para o arquivo (é mais um palpite)
• cCfData: Como há apenas 1 arquivo, devemos ter apenas 1 CFDATA; não tenho tanta certeza por que isso deve ser definido como 2 Na verdade, podemos deixar como 1
• cbFile: Curiosamente, se a extração do CAB terminar sem erro, o arquivo INF será marcado para exclusão pelo WORD, arruinando a exploração. A única maneira de evitar isso é fazer o WORD acreditar que a extração falhou. Se o valor cbFile for definido como maior que o próprio arquivo cabinet, o extrator alcançará um EOF antes de ler todos os bytes definidos em cbFile, gerando um erro de extração.
• [OPCIONAL] Esse valor parece não ser verificado pelo MS Word. De qualquer forma, para ter um CAB correto, o valor csum deve ser recalculado. Felizmente, conforme observado por j00sean e de acordo com a documentação da MS, esse valor pode ser 0

NOTA1: O Defender agora detecta se o arquivo CAB contém um PE usando o valor _IMAGE_DOS_HEADER.e_magic como assinatura, potencialmente evitando que arquivos PE sejam incorporados no CAB. Essa assinatura pode ser contornada? Não tenho certeza, mas, como observado antes, esta é uma vulnerabilidade corrigida, então não pretendo investir muito mais tempo nisso. Fica a cargo do leitor curioso desenvolver isso mais.

NOTA2: O patch da Microsoft bloqueia esquemas de URI arbitrários, aparentemente usando uma abordagem de lista negra (isso é apenas uma suposição)

Ataque DLL

A principal cadeia de ataque associada ao CVE-2021-40444 é o ataque DLL carregado via esquema de URI .cpl. Para explorar isso, um invasor precisa gerar um DLL especialmente criado. Se quiser testar, experimente meu script evildll-gen.

JScript, VBScript, Javaw, MSIexec, ...

Conforme observado por Max Maluin, é possível interagir com vários tipos de arquivo abusando do IE e do URI baseado na extensão de arquivo associada. Embora isso possa ser uma boa maneira de explorar o IE, tem limitações.

De fato, deve-se notar que o método usado na exploração para baixar arquivos é baseado em atualizações de controle ActiveX e não pode ser usado para baixar arquivos arbitrários. Segundo a documentação da Microsoft, a tag codebase pode apontar apenas para alguns tipos de arquivo: OCX, INF e CAB.

Mesmo que possamos baixar diretamente um arquivo OCX ou INF, ainda não podemos ter certeza de baixar o arquivo no local correto dentro do sistema. Com a exploração do cab, é possível mover o arquivo .inf para um caminho conhecido usando o path traversal, mas em qualquer outro caso o arquivo será armazenado em um diretório aleatório, tornando praticamente impossível referenciá-lo.

Até hoje, não encontrei uma maneira de encadear download e execução SEM um arquivo CAB.

Nota: Falando apenas do IE, o contrabando de HTML (HTML smuggling) poderia ser um cenário possível para explorar a vulnerabilidade.

Ataque sem CAB usando arquivo RAR híbrido

Esta técnica foi divulgada primeiramente por Eduardo Braun no Twitter e explicada posteriormente neste artigo.

Observe que, usando esta técnica, a cadeia de ataque é um pouco diferente. Este ataque exige que o usuário baixe um arquivo RAR especialmente criado, obtido encadeando um script WSF válido e um arquivo RAR válido. Uma vez aberto, o RAR conterá um DOCX com referência a um HTML, que por sua vez tentará carregar o arquivo RAR como um script WSF.

Para resumir:

1. O arquivo RAR especialmente criado é baixado (provavelmente na pasta Downloads)
2. O DOCX é extraído e aberto
3. O relacionamento armazenado em document.xml.rels aponta para HTML malicioso
4. A pré-visualização do IE é iniciada para abrir o link HTML
5. O JScript dentro do HTML contém um script/iframe apontando para o arquivo RAR, prefixado com o esquema de URI ".wsf:"
6. Como o RAR foi projetado para ser simultaneamente um RAR válido e um script WSF válido, o script é executado

Quais são os PoCs de exploração implementados pela ferramenta

O utilitário gerador pode atualmente reproduzir os seguintes ataques: