CVE-2021-40444 Totalmente Armada

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

Atualização 31/05/2022 - CVE-2022-30190 - Follina

Agora o gerador é capaz de gerar o documento necessário para explorar também o ataque "Follina" (aproveitando o ms-msdt).

Contexto

Embora muitos PoCs já estejam disponíveis na internet, resolvi dar uma chance a mim mesmo de armamentar 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
• Twit do j00sean
• Twit do wdormann

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 for uma DLL)

Requisitos Ignorados

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

Talvez ninguém tenha "liberado" 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" no MS Word.

Arquivo CAB

O arquivo CAB precisa ser corrigido por bytes para evitar erros de extração e para alcançar o ZipSlip:

• filename.inf deve se tornar ../filename.inf
• filename.inf deve ter exatamente <12 caracteres>.inf Não é verdade, 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 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 passei 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 file para acionar a escrita do INF falhará Falso, consegui obter o mesmo resultado com uma amostra comprimida em MSZIP
• CoffCabStart: CoffCabStart dá a posição absoluta da primeira estrutura CFDATA, como adicionamos um '../', precisaríamos aumentar isso em 3 para apontar para o arquivo (isso é mais um palpite)
• cCfData: Como há apenas 1 arquivo, devemos ter apenas 1 CFDATA, não tenho 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 nenhum 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 atingirá 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, como notado 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 uma assinatura, potencialmente impedindo que arquivos PE sejam embutidos 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. Cabe ao leitor curioso desenvolver isso mais adiante.

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 atacante precisa gerar uma DLL especialmente criada. Se quiser testar, experimente meu script evildll-gen.

JScript, VBScript, Javaw, MSIexec, ...

Como observado por Max Maluin, é possível interagir com vários tipos de arquivo abusando do IE e da extensão de arquivo associada ao URI. 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. Conforme 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 certo 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 virtualmente 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 HTML smuggling pode ser um cenário possível para explorar a vulnerabilidade.

Ataque sem CAB usando arquivo RAR híbrido

Esta técnica foi divulgada pela primeira vez por Eduardo Braun no Twitter e explicada mais detalhadamente 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 uma referência a um HTML, que por sua vez tentará carregar o arquivo RAR como um script WSF.

Para resumir:

1. Arquivo RAR especialmente criado é baixado (provavelmente na pasta Downloads)
2. DOCX extraído e aberto
3. Relacionamento armazenado em document.xml.rels aponta para HTML malicioso
4. A pré-visualização do IE é iniciada para abrir o link HTML
5. 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