Hiperlinks file:// manipulados podem acionar COM no Windows, provocar autenticação NTLM via SMB e abrir caminho para execução de código por aplicativos usados como servidores COM.
| Componente | Microsoft Outlook em ambientes Windows 10 e Windows 11 com Microsoft 365 e Office 2021, com impacto potencial em softwares que usam MkParseDisplayName() ou MkParseDisplayNameEx() de forma insegura. |
| Vetor | Clique do usuário em hiperlink file:// especialmente formado com caminho UNC remoto e delimitador !, fazendo o Outlook tratar o valor como moniker composto e consultar objetos COM. |
| Impacto | Vazamento de informações NTLM durante acesso SMB na porta 445 e possibilidade condicionada de execução remota de código quando o servidor COM acionado processa conteúdo explorável sem o modo protegido. |
| Prioridade | Aplicar a atualização de segurança de fevereiro de 2024 para Outlook, bloquear SMB de saída quando não houver necessidade operacional e revisar aplicações que analisam entradas não confiáveis com APIs COM de moniker. |
| CVE | CVE-2024-21413, corrigida no Patch Tuesday de fevereiro de 2024 com pontuação CVSS 9.8. |
| Artefatos | file://, caminho UNC remoto, delimitador !, ole32!MkParseDisplayName(), FileMoniker, ItemMoniker, SMB na porta 445 e processo WINWORD.EXE em modo de servidor COM. |
A falha CVE-2024-21413 expõe um comportamento perigoso no Microsoft Outlook ao processar hiperlinks que parecem apontar para recursos de arquivo, mas que acabam sendo interpretados pelo subsistema COM do Windows como monikers compostos. Em vez de apenas bloquear o acesso a um recurso remoto referenciado por file://, o Outlook pode remover o prefixo do protocolo, entregar o restante da cadeia para ole32!MkParseDisplayName() e iniciar a resolução de um objeto COM. A presença do caractere ! altera a interpretação do valor, separando um FileMoniker baseado em um caminho UNC remoto de um ItemMoniker associado a um item dentro do objeto. Esse detalhe transforma um clique em uma transição entre o cliente de e-mail, a camada COM e um aplicativo servidor capaz de abrir e analisar conteúdo controlado pelo invasor.
O primeiro impacto confirmado é a tentativa de acesso a um compartilhamento remoto via SMB, o que pode expor informações de autenticação NTLM do usuário durante a negociação de rede. O risco aumenta quando o arquivo referenciado é manipulado por um aplicativo COM, como o Word no caso de conteúdo RTF, porque o processamento ocorre em segundo plano e sem o Modo de Exibição Protegido do Office. A pesquisa demonstrou crash em WINWORD.EXE usando um arquivo RTF de prova de conceito não explorável, suficiente para confirmar que o conteúdo remoto é aberto e analisado. A execução de código depende de uma falha explorável no servidor COM acionado, mas o vetor reduz a interação necessária para uma única ação do usuário e remove uma barreira defensiva importante.
O comportamento defensivo esperado do Outlook é tratar protocolos conhecidos de maneira diferente conforme o risco. Links hxxp:/// e hxxps:/// são enviados ao navegador padrão, enquanto protocolos de aplicação considerados sensíveis podem gerar aviso ao usuário. Para file:// apontando diretamente para arquivo remoto, o aplicativo testado não acessou o recurso e exibiu erro ao usuário. A condição vulnerável aparece quando o hiperlink usa um caminho UNC remoto combinado com ! e texto adicional. Nessa forma, o bloqueio observado para o acesso remoto simples deixa de ser efetivo e o Outlook continua a resolução por meio do mecanismo de moniker.
A chamada relevante é MkParseDisplayName(), função do COM usada para analisar um nome de exibição e localizar o objeto correspondente. Quando a cadeia contém !, a semântica passa a ser a de moniker composto: a primeira parte referencia um arquivo remoto, e a segunda parte referencia um item dentro daquele objeto. No cenário com extensão RTF, o Word é acionado como servidor COM para resolver o objeto. Esse servidor abre o arquivo remoto e inicia o parsing do conteúdo, o que desloca o risco para a robustez do aplicativo servidor. Se esse parser tiver uma vulnerabilidade de corrupção de memória ou outra falha explorável em modo COM, o clique no e-mail pode ser suficiente para atingir execução de código.
A gravidade operacional está na combinação de três propriedades. Primeiro, há contato de rede com infraestrutura remota por SMB na porta 445, permitindo exposição de material NTLM se a rede permitir esse tráfego de saída. Segundo, o processamento do documento ocorre fora do caminho tradicional de anexo, que normalmente acionaria o Modo de Exibição Protegido para conteúdo vindo de origem externa. Terceiro, o problema não é limitado conceitualmente ao Word; qualquer software capaz de atuar como servidor COM e registrado para o tipo de objeto acionado pode ampliar a superfície se analisar entrada controlada de forma insegura.
O problema foi confirmado em ambientes Windows 10 e Windows 11 com Microsoft 365 e Office 2021. Outras edições do Office são tratadas como provavelmente expostas no material técnico, mas a reportagem não deve assumir versões específicas sem validação própria. A superfície imediata envolve usuários do Outlook que recebem mensagens HTML com hiperlinks malformados e têm conectividade de saída suficiente para alcançar um recurso SMB externo. A exploração prática também depende de um aplicativo COM instalado e associado ao tipo de conteúdo referenciado, além de um defeito explorável no processamento desse conteúdo quando aberto como servidor COM.
Além do Outlook, o padrão inseguro merece revisão em aplicações Windows que aceitam entrada de usuário, texto de documento, mensagens, campos de configuração ou conteúdo importado e repassam esse valor para MkParseDisplayName() ou MkParseDisplayNameEx(). A documentação dessas APIs já alerta para o risco de analisar entrada controlada por atacante. Portanto, o bug é uma vulnerabilidade corrigida no Outlook, mas também representa uma classe de abuso no ecossistema COM quando software de terceiros transforma texto não confiável em resolução de objeto sem validação estrita.
- Clientes Outlook vulneráveis antes da atualização de segurança de fevereiro de 2024.
- Ambientes que permitem SMB de saída para redes externas pela porta 445.
- Aplicativos Office ou de terceiros registrados como servidores COM para tipos de arquivo acessados por moniker.
- Softwares que repassam hiperlinks, caminhos, campos importados ou conteúdo de mensagens para
MkParseDisplayName()ouMkParseDisplayNameEx().
A detecção deve combinar telemetria de e-mail, endpoint, rede e criação de processos. Em mensagens, o sinal mais relevante é a presença de hiperlinks file:// com caminho UNC remoto e delimitador !, principalmente quando o conteúdo aparece em HTML recebido de remetentes externos. No endpoint, a sequência de interesse é o Outlook acionando COM e, em seguida, processos do Office em segundo plano, como WINWORD.EXE, para manipular conteúdo remoto. Esse padrão é diferente do fluxo normal de abertura explícita de anexo pelo usuário e pode aparecer sem janela visível do documento.
Na rede, conexões SMB de estáções de trabalho para destinos externos devem ser raras em ambientes corporativos bem segmentados. Tentativas de saída pela porta 445 logo após o usuário interagir com uma mensagem no Outlook são fortes candidatas a investigação. A análise não precisa depender de IoCs fixos, porque o vetor permite infraestrutura arbitrária. O foco deve estar no protocolo, no processo de origem, na proximidade temporal com atividade de e-mail e no uso de caminhos remotos não esperados.
Em engenharia e AppSec, o hunting deve incluir busca estática por uso de MkParseDisplayName() e MkParseDisplayNameEx() em bases de código Windows, especialmente quando os argumentos derivam de campos externos. A revisão deve verificar se há allowlist de protocolos, bloqueio de UNC remoto, normalização antes da análise, rejeição de monikers compostos e isolamento do processamento. Wrappers internos que escondem essas APIs também precisam ser auditados, porque a exposição pode estar em camadas de utilitários e não diretamente no código de interface.
- E-mails HTML contendo
file://, caminho UNC e caractere!no mesmo hiperlink. - Outlook criando ou acionando processos Office em segundo plano após clique em link.
- Conexões SMB de saída pela porta 445 originadas de estáções de usuário.
- Eventos de autenticação NTLM para destinos externos ou não reconhecidos.
- Uso de
MkParseDisplayName()ouMkParseDisplayNameEx()com dados vindos de entrada não confiável.
A correção principal é instalar a atualização de segurança do Outlook publicada no Patch Tuesday de fevereiro de 2024 para CVE-2024-21413. Como a pontuação CVSS informada é 9.8 e o vetor reduz a interação a um clique, a priorização deve cobrir estáções de trabalho, servidores de área de trabalho remota, ambientes VDI e imagens corporativas usadas para provisionamento. A aplicação do patch precisa ser acompanhada por verificação de versão e por validação de que clientes desconectados, máquinas fora de domínio e instalações de Office gerenciadas separadamente também receberam a atualização.
A contenção de rede é uma defesa importante mesmo com patch aplicado. Bloquear SMB de saída para a Internet reduz a chance de vazamento NTLM e dificulta a cadeia que depende de arquivo remoto. Essa medida deve ser implementada em firewalls de borda, proxies compatíveis, controles de endpoint e políticas de segmentação, respeitando exceções formais para fluxos legados que realmente precisem de SMB fora da rede interna. Onde NTLM ainda for necessário, logs de autenticação e alertas para destinos incomuns ajudam a identificar tentativas anteriores ou exploração parcial.
Para desenvolvedores de software Windows, a mitigação exige tratar qualquer uso de moniker como operação sensível. Entradas externas não devem ser encaminhadas diretamente para APIs COM de parsing. Quando a funcionalidade for indispensável, o código deve restringir protocolos aceitos, negar caminhos UNC remotos por padrão, rejeitar monikers compostos quando não forem necessários e registrar decisões de bloqueio para auditoria. Aplicações que processam e-mails, documentos, tickets, mensagens, URLs importadas ou conteúdo colaborativo devem receber revisão prioritária, porque esses caminhos frequentemente misturam texto controlado por terceiros com automação local.
- Aplicar a atualização oficial do Outlook para
CVE-2024-21413e validar a cobertura no parque instalado. - Bloquear SMB de saída pela porta 445 para destinos externos, salvo exceções aprovadas e monitoradas.
- Criar detecções para links
file://com UNC remoto e!em mensagens recebidas. - Auditar código que usa
MkParseDisplayName()ouMkParseDisplayNameEx()com entrada externa. - Investigar eventos NTLM e criação de processos Office em segundo plano associados a interações recentes no Outlook.
0 Comentários