CreateRCE – Outra vulnerabilidade no CreateUri
Resumo executivo
O pesquisador da Akamai, Ben Barnea, encontrou uma vulnerabilidade crítica no Microsoft Windows, que foi atribuída ao CVE-2023-35628.
Um invasor na Internet pode disparar a vulnerabilidade contra clientes do Outlook sem nenhuma interação do usuário (clique zero).
A vulnerabilidade está na análise de um caminho pela função CreateUri. No momento, estamos cientes de duas maneiras de acionar essa vulnerabilidade: (1) enviando um e-mail criado para um cliente do Outlook ou (2) atraindo um usuário a navegar no Explorador de arquivos para uma pasta contendo um arquivo mal-intencionado baixado.
A vulnerabilidade foi divulgada de forma responsável à Microsoft e abordada no Patch Tuesday de dezembro de 2023.
Os computadores Windows com a atualização de software de dezembro de 2023 instalada estão protegidos contra essa vulnerabilidade. Além disso, os clientes Outlook que utilizam servidores Exchange corrigidos com a atualização de software de março de 2023 estão protegidos contra o uso indevido dessa funcionalidade.
Introdução
A onipresença da Microsoft nas empresas e além faz dela um alvo grande (e lucrativo) para os invasores. Como tal, fizemos uma extensa pesquisa sobre o conjunto de produtos e protocolos, encontrando vulnerabilidades e criando ferramentas para ajudar na detecção e mitigação.
Como parte desta pesquisa, descobrimos uma nova vulnerabilidade de execução remota de código (RCE) na função WinAPI CreateUri que é chamada como parte do patch para a vulnerabilidade original CVE-2023-23397. Enquanto a cadeia de vulnerabilidade de RCE anterior precisava reunir duas vulnerabilidades para alcançar uma primitiva de RCE de clique zero, essa vulnerabilidade pode fazer isso por conta própria. Além do Outlook, também mostraremos como ativar a vulnerabilidade no Explorador de arquivos.
A saga da vulnerabilidade
Entre as vulnerabilidades abordadas como parte do Patch Tuesday de março de 2023, uma vulnerabilidade crítica do Outlook foi descoberta pela própria Microsoft (atribuída ao CVE-2023-23397) que era usada no mundo real por um agente de ameaças patrocinado pelo estado russo chamado Forest Blizzard.
Em dezembro de 2023, a Microsoft, juntamente com o Polish Cyber Command, divulgou que eles tinham visto tentativas recentes de exploração da vulnerabilidade pelo mesmo agente de ameaças. A vulnerabilidade permitia que um invasor coagisse um cliente Outlook a se conectar ao servidor do invasor. Como parte dessa conexão, o cliente envia suas credenciais NTLM para o invasor, que pode decifrá-las off-line ou usá-las em um ataque de retransmissão. Essa vulnerabilidade poderia ser explorada remotamente pela Internet sem nenhuma interação do usuário (clique zero).
Depois que o patch para essa vulnerabilidade foi lançado, encontramos dois desvios junto com uma vulnerabilidade de análise de som. O encadeamento das vulnerabilidades de desvio e de análise pode levar a uma primitiva de RCE de zero clique no cliente do Outlook.
MapUrlToZone
Como parte do patch para a vulnerabilidade do Outlook CVE-2023-23397, o código responsável pelo tratamento de um som de lembrete personalizado adiciona uma chamada ao MapUrlToZone. A chamada verifica se o URL fornecido, especificado por meio da extensão da propriedade MAPI PidLidReminderFileParameter, não aponta para um recurso da internet.
Embora isso reduza a vulnerabilidade inicial, ele adiciona uma nova superfície de ataque: a função MapUrlToZone ; nós controlamos o caminho que está sendo passado ao MapUrlToZone.
Como parte da análise feita pela função MapUrlToZone, ele chama o CreateUri. CreateUri cria um objeto IUri que representa um URI (Uniform Resource Identifier). Para criar o objeto, a função sabe analisar URLs e alguns dos caminhos DOS do Windows.
Quando CreateUri é chamado com um caminho de arquivo (por exemplo, usando file:// scheme, ou um caminho do Windows apontando para um arquivo/diretório), a função CrackUrlFile é chamada. Essa também é a função que continha os desvios descritos na publicação anterior no blog.
A nova vulnerabilidade
No início do CrackUrlFile, se ele receber um URL em vez de um caminho do Windows, ele criará uma cópia da entrada e, em seguida, transformará a cópia de URL em um caminho do Windows usando o PathCreateFromUrlW. O buffer de trabalho é marcado como alocado dinamicamente, de modo que ele saberia liberá-lo posteriormente. Se a função receber um caminho do Windows, ela funcionará diretamente no caminho de entrada e, portanto, não precisará liberar o ponteiro.
Durante a análise do buffer de trabalho, o buffer pode ser avançado; por exemplo, se for um caminho de dispositivo local (começa com "\\.\" ou "\\?\"), a função avança o ponteiro em quatro caracteres. Em seguida, se o nome do dispositivo for "UNC\", ele avança mais quatro caracteres. Se houver várias barras invertidas, a função também avança o buffer além das barras invertidas duplicadas.
Como parte de nossa reversão dos patches para os desvios, notamos um novo código adicionado no CrackUrlFile em julho de 2023, o que parecia não estar relacionado às nossas derivações (Figura 1).
Fig. 1: Descompilação de código recém-adicionado
Como parte da análise do caminho, a função verifica se o componente do caminho é de um caminho de unidade ou de raiz. Se sim, ele marca o caminho como local. O novo código substitui o ponteiro do buffer original por um ponteiro para o componente de caminho (o buffer avançado) se o caminho for um caminho de unidade.
Esta é a origem do bug: o ponteiro avançado é salvo. Mais tarde, o ponteiro de buffer original (PPWorkingBuffer na Figura 1) é recuperado e liberado se foi alocado dinamicamente. Uma vez que foi substituído pelo ponteiro avançado, uma chamada para free() acontece com um ponteiro que não foi retornado pelo malloc. Isso dá a um invasor uma primitiva para fornecer ao localizador de memória os metadados de um fragmento mal-intencionado.
Para que a vulnerabilidade seja acionada, primeiro precisamos especificar um URL de esquema de arquivo, com um caminho UNC. Em seguida, precisamos marcar o caminho como um caminho de unidade, então devemos usar um compartilhamento (C:). O caminho completo para acionar a vulnerabilidade terá a seguinte aparência:
file://./UNC/C:/Akamai.com/file.wav
O código fixo agora copia os bytes do componente de caminho usando RtlMoveMemory, em vez de salvar o ponteiro.
Acionamento através do Explorer
Apesar de estar fora do escopo de nossa pesquisa para encontrar esses lugares, fizemos uma rápida tentativa: Acionando-o pelo Windows Explorer.
Para isso, criamos um atalho (arquivo .lnk) apontando para o caminho vulnerável. Quando a vítima exibe o diretório no qual o arquivo de atalho reside, a vulnerabilidade é acionada no Explorer, o que leva a uma falha imediata (Figura 2).
Para testar se a sua máquina está vulnerável a este problema, baixe a nossa prova de conceito (PoC) que irá travar o Explorer. Leia com atenção as especificidades e os riscos sobre a PoC em nosso repositório de pesquisa de segurança antes do uso.
Fig. 2: O Explorer trava como resultado da PoC
Resumo
Esta é a nossa publicação final no blog sobre a pesquisa do impacto potencial do CVE-2023-23397.
Em maio de 2023, quando descobrimos o primeiro desvio, recomendamos remover o recurso abusado, uma vez que o uso do MapUrlToZone adiciona uma nova superfície de ataque. Também mencionamos que expor uma superfície de ataque de análise de som a um invasor remoto de maneira sem nenhum clique, sem qualquer área restrita, representa mais perigos para os usuários do que valor.
Em nossa pesquisa subsequente, conseguimos provar exatamente isso encontrando dois desvios, encontrando um problema de análise de som, e, por fim, encontrando uma corrupção de memória de análise de caminho do Windows.
Esperamos que você tenha aprendido coisas novas sobre caminhos do Windows, codecs de som e vulnerabilidades diferentes com essas publicações. Incentivamos outros pesquisadores a analisar patches e pensar em como eles podem ser ignorados. Não podemos confirmar se mais desvios MapUrlToZone existem.
Quer mais?
Leia nossas publicações anteriores no blog sobre este tópico:
