CreateRCE – Outra vulnerabilidade no CreateUri
Sumário 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 para 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 na 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 em outros setores faz dela um alvo grande (e lucrativo) para os invasores. Dessa forma, fizemos uma extensa pesquisa sobre o conjunto de produtos e protocolos, encontrando vulnerabilidades e criando ferramentas para ajudar na detecção e atenuação.
Como parte dessa 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 vulnerabilidades de RCE anterior precisava encadear duas vulnerabilidades para obter uma primitiva de RCE de clique zero, essa vulnerabilidade pode fazer isso sozinha. 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 da Patch Tuesday de março de 2023 estava uma vulnerabilidade crítica do Outlook descoberta pela própria Microsoft (atribuída como CVE-2023-23397), que foi explorada por um agente de ameaças patrocinado pelo Estado russo chamado Forest Blizzard.
Em dezembro de 2023, a Microsoft e o Polish Cyber Command publicaram que perceberam 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 a correção para essa vulnerabilidade foi lançada, encontramos dois desvios, além de 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 por lidar com um som de lembrete personalizado adiciona uma chamada ao MapUrlToZone. A chamada verifica se o URL fornecido, especificado por meio da propriedade MAPI estendida PidLidReminderFileParameter, não aponta para um recurso da Internet.
Embora isso atenue a vulnerabilidade inicial, acrescenta uma nova superfície de ataque, a própria função MapUrlToZone; controlamos o caminho que está sendo passado para o MapUrlToZone.
Como parte da análise feita pelo MapUrlToZone, ele chama o CreateUri. O CreateUri cria um objeto IUri que representa um URI (Uniform Resource Identifier, identificador uniforme de recursos). Para criar o objeto, a função sabe analisar os URLs e alguns dos caminhos do DOS Windows.
Quando CreateUri é chamado com um caminho de arquivo (por exemplo, usando o esquema file:// ou um caminho do Windows que aponta para um arquivo/diretório), a função CrackUrlFile é chamada. Essa também é a função que continha os desvios descritos na postagem anterior do blog.
A nova vulnerabilidade
No início do CrackUrlFile, se ele receber um URL em vez de um caminho do Windows, criará uma cópia da entrada e, em seguida, transformará a cópia do URL em um caminho do Windows usando 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 da nossa reversão dos patches para os desvios, notamos um novo código adicionado a CrackUrlFile em julho de 2023, que parecia não estar relacionado aos nossos desvios (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. Posteriormente, o ponteiro do buffer original (PPWorkingBuffer na Figura 1) é recuperado e liberado se tiver sido 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 da nossa pesquisa para encontrar esses lugares, fizemos uma rápida tentativa: Acionando-o pelo Windows Explorer.
Para isso, criamos um atalho (arquivo .lnk) que aponta 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).
Fig. 2: O Explorer trava como resultado da PoC
Para testar se sua máquina é vulnerável a esse problema, você pode baixar nossa prova de conceito (PoC) que irá travar o Explorer. (Leia atentamente os detalhes e os riscos sobre a PoC no nosso relatório de pesquisa de segurança antes de usá-lo).
Resumo
Esta é nossa publicação final no blog sobre a pesquisa do impacto potencial da CVE-2023-23397.
Em maio de 2023, quando descobrimos o primeiro desvio, recomendamos a remoção do recurso abusado, pois 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 do que valor para os usuários.
Em nossa pesquisa posterior, conseguimos provar isso exatamente encontrando dois desvios, um problema de análise de som e, por fim, 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 descartar o fato de que existam mais desvios de MapUrlToZone.
Quer mais?
Leia nossas publicações anteriores no blog sobre este tópico:
