De uma vulnerabilidade para outra: A Análise de patches do Outlook revela uma falha importante na API do Windows
Contribuições editoriais e adicionais por Tricia Howard
Resumo executivo
O pesquisador da Akamai Ben Barnea encontrou uma nova vulnerabilidade importante em um componente do Internet Explorer, designada CVE-2023-29324 com uma pontuação básica CVSS de 6,5.
A vulnerabilidade causa uma função de API do Windows – MapUrlToZone – para pensar incorretamente que um caminho remoto é um local.
O MapUrlToZone é comumente usado como uma medida de segurança. Em particular, ele foi usado para atenuar a vulnerabilidade crítica do Outlook CVE-2023-23397 corrigida no Patch Tuesday de março.
Um invasor não autenticado na Internet pode usar a vulnerabilidade para coagir um cliente Outlook a se conectar a um servidor controlado pelo próprio invasor. Isso resulta em roubo de credenciais NTLM. É uma vulnerabilidade de clique zero, o que significa que ela pode ser acionada sem interação do usuário.
Todas as versões do Windows são afetadas pela vulnerabilidade. Como resultado, todas as versões do cliente Outlook no Windows são exploráveis. No entanto, de acordo com a Microsoft, os servidores Exchange com a atualização de março omitem o recurso vulnerável, impedindo assim que clientes vulneráveis sejam explorados.
O problema foi divulgado com responsabilidade à Microsoft e corrigido na Patch Tuesday de maio de 2023.
Introdução
Entre as vulnerabilidades abordadas como parte da Patch Tuesday de março de 2023, foi uma crítica do Outlook designada CVE-2023-23397.
A vulnerabilidade permite que um invasor coaja um cliente do Outlook para se conectar ao servidor do invasor. Ao fazer isso, o cliente envia credenciais NTLM para a máquina, o que permite que o invasor descubra a senha off-line ou a use em um ataque de retransmissão. Essa vulnerabilidade pode ser explorada remotamente pela Internet sem qualquer interação do usuário (clique zero).
Conforme avaliado pelo Microsoft Threat Intelligence, um agente de ameaça russo usou a vulnerabilidade em ataques direcionados contra várias organizações nos setores do governo europeu, transportes, energia e militar durante aproximadamente um ano.
Como parte da nossa análise do patch, descobrimos uma maneira de ignorar a correção dessa vulnerabilidade crítica. Nesta publicação do blog, discutiremos a vulnerabilidade original, o patch e o desvio para o patch.
A vulnerabilidade original
A vulnerabilidade do Outlook que foi corrigida em março é acionada quando um invasor envia um e-mail contendo um lembrete com um som de notificação personalizado. Esse som personalizado é especificado pelo invasor como um caminho, usando a propriedade MAPI estendida PidLidReminderFileParameter. Um invasor pode especificar um caminho UNC que faria com que o cliente recuperasse o arquivo de som de qualquer servidor SMB. Como parte da conexão com o servidor SMB remoto, a hash Net-NTLMv2 é enviada em uma mensagem de negociação.
Para corrigir o problema, o código agora chama MapUrlToZone para verificar se o caminho não se refere a um URL da Internet. Se isso acontecer, o som de lembrete padrão será usado em vez do som personalizado.
Desviando da atenuação
Primeiro, vamos analisar o fluxo de código relevante no Outlook. Duas funções importantes são chamadas como parte do carregamento do arquivo de som personalizado:
MapUrlToZone – Retorna a zona do URL; usado para determinar se o caminho é local, intranet ou confiável (e não Internet)
CreateFile – Abre uma alça para o arquivo de som
Nota: SearchPath Também chamado anteriormente de CreateFile, mas lida com o caminho de maneira semelhante; portanto, para facilitar a compreensão, vamos consultar apenas CreateFile aqui.
Para encontrar um desvio, precisamos encontrar um caminho que o MapUrlToZone consideraria local, intranet ou uma zona confiável, e que o CreateFile também trataria como um domínio da Internet.
Para chamar MapUrlToZone, podemos usar o seguinte script PowerShell que chama a função através de Modelo de Objeto de Componente (COM).
Para verificar se o MapUrlToZone é uma atenuação adequada, podemos testá-lo chamando-o no mesmo caminho que acionou a vulnerabilidade, um caminho UNC absoluto com um domínio da Internet. MapUrlToZone retorna 3, indicando que o caminho está na zona da Internet, conforme esperado.
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\Akamai.com\file.wav')
3
Podemos experimentar e ajustar nosso caminho UNC usando um caminho do dispositivo local:
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\Akamai.com\file.wav')
3
Como visto acima, o MapUrlToZone ainda identifica o caminho como uma zona da Internet; portanto, ele ainda seria bloqueado, como a correção desejada.
No entanto, ao adicionar outra “\” depois de “UNC\”, o MapUrlToZone agora retorna 0, o que significa um caminho local:
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\\Akamai.com\file.wav')
0
Então, o MapUrlToZone conclui que este URL é local. Agora, a pergunta importante é: Qual será o veredito de CreateFile para este URL? Ele acessará um arquivo local ou fará o download por meio do SMB?
Rufem os tambores...
Fig. 1: Simular uma chamada CreateFile com o caminho UNC, levando a uma solicitação DNS
Legal! Uma solicitação de DNS foi enviada para recuperar o IP de Akamai.com (Figura 1). Parece que encontramos um caminho que o MapUrlToZone conclui como local, mas faz com que o CreateFile dispare uma solicitação para a Internet!
Agora, vamos disparar a vulnerabilidade original do Outlook, desta vez ignorando a atenuação adicional.
Fig. 2: Acionamento do evento de calendário, levando à autenticação NTLM em um servidor remoto
Como você pode ver na Figura 2, quando o lembrete aparecer, o Outlook se conecta ao servidor remoto que leva à autenticação NTLM.
De acordo com a Microsoft, os servidores Exchange com a atualização de software de março instalada irão descartar a propriedade PidLidReminderFileParameter,eliminando o recurso de arquivo de som personalizado. Assim, somente máquinas que executam clientes Outlook com um servidor Exchange sem patch são vulneráveis a esse problema.
A causa raiz
Esse problema parece ser um resultado do tratamento complexo de caminhos no Windows.
O MapUrlToZone chama a função CreateUri, que converte incorretamente o caminho '\\.\UNC\\Akamai.com\file.wav' para ‘/.//UNC//Akamai.com/file.wav’.
Para ver qual acesso é acionado pelo último caminho, podemos usar o script ConvertDosPathToNtPath de autoria de James Forshaw publicação do blog.
PS C:\Users\research1> ./DosToRelativeNT.exe /.//UNC//Akamai.com/file.wav
Converting: '/.//UNC//Akamai.com/file.wav'
To: '\??\C:\UNC\Akamai.com\file.wav'
Type: RtlPathTypeRooted
FileName: file.wav
FullPathName: 'C:\UNC\Akamai.com\file.wav'
Agora podemos ver que esse caminho aponta para um diretório chamado “UNC” na unidade C: local. Este é obviamente um diretório local, e por isso MapUrlToZone retorna 0.
Por outro lado, CreateFile primeiro converte o caminho original de um caminho do DOS em um caminho NT chamando RtlpDosPathNameToRelativeNtPathName. Mais uma vez, o uso do script nos permite observar o resultado dessa conversão.
PS C:\Users\research1> ./DosToRelativeNT.exe \\.\UNC\\Akamai.com\file.wav
Converting: '\\.\UNC\\Akamai.com\file.wav'
To: '\??\UNC\Akamai.com\file.wav'
Type: RtlPathTypeLocalDevice
FileName: file.wav
FullPathName: '\\.\UNC\Akamai.com\file.wav'
Observe que, neste momento, o resultado não aponta para uma unidade local. Então, por que uma solicitação SMB é acionada? Como pode ser visto no trecho acima, o caminho resultante é '\??\UNC\Akamai.com\file.wav'. O acesso a esse caminho NT fará com que o gerenciador de objetos encaminhe a solicitação de ES para o driver Multiple UNC Provider (MUP). (Isso ocorre porque a entrada de diretório de objeto global para “UNC” é um link simbólico para “\Device\Mup”.) Como RtlpDosPathNameToRelativeNtPathName foi removido ou colapsou a “\”, o caminho agora contém apenas o nome de domínio da Internet.
Acreditamos que esse tipo de confusão pode causar vulnerabilidades em outros programas que usam o MapUrlToZone em um caminho controlado pelo usuário e, em seguida, usar uma operação de arquivo (como CreateFile ou uma API semelhante) no mesmo caminho. Além disso, não podemos excluir outros problemas que surgem em programas que chamam CreateUri.
Detecção e mitigação
A Microsoft publicou uma orientação abrangente para a detecção e atenuação da vulnerabilidade original do Outlook. A partir da nossa observação, todos os métodos especificados são aplicáveis à nova vulnerabilidade, pois não dependem do URL especificado na propriedade PidLidReminderFileParameter .
Resumo
Essa vulnerabilidade é mais um exemplo de verificação de patch, levando a novas vulnerabilidades e desvios. Especificamente para essa vulnerabilidade, a adição de um caractere possibilita uma derivação crítica do patch.
Esperamos que o recurso de som de lembrete personalizado seja totalmente removido, pois representa mais riscos de segurança do que fornece valor aos usuários. Trata-se de uma superfície de ataque de análise de mídia de clique zero que pode conter vulnerabilidades críticas de corrupção de memória. Considerando como o Windows é onipresente, eliminar uma superfície de ataque tão madura quanto essa pode ter alguns efeitos muito positivos.
Como parte dos nossos esforços contínuos para proteger nossos clientes e a comunidade, continuaremos a analisar as vulnerabilidades de patches e outros sistemas. Para acompanhar a mais recente pesquisa de segurança da Akamai, siga-nos no Twitter.
Gostaríamos de agradecer à Microsoft pela cooperação e resposta rápida ao lidar com esse problema.
