CVE-2013-7331

Falha no controle ActiveX Microsoft.XMLDOM do Internet Explorer que permite a uma página web maliciosa descobrir, por meio de códigos de erro distintos, se determinados caminhos locais, compartilhamentos UNC, hosts de intranet ou IPs internos existem na máquina da vítima. Não gera execução de código nem acesso a conteúdo — é reconhecimento silencioso do ambiente da vítima, mas foi decisivo em pelo menos uma campanha real de espionagem porque permitia identificar produtos de segurança instalados antes de decidir se valia a pena disparar um exploit mais agressivo.

O Microsoft.XMLDOM é um objeto ActiveX que o Internet Explorer instancia sem exigir confirmação do usuário (diferente de outros controles). Ele expõe métodos de carregamento de documentos XML que aceitam como argumento caminhos de arquivo, compartilhamentos UNC ou URLs no esquema res://. Quando o carregamento falha, o objeto retorna códigos de erro/parseError que variam de forma previsível dependendo do motivo da falha — 'arquivo não encontrado' é um erro diferente de 'acesso negado' ou 'caminho existe mas não é XML válido'.

Essa diferença de código de erro funciona como um oráculo binário: um atacante que controla a página HTML pode tentar carregar, por exemplo, C:\Program Files\ ou \\host-interno\share e, pela distinção entre os erros, inferir se aquele caminho, host ou IP existe na máquina do visitante — mesmo sem qualquer permissão de leitura sobre o conteúdo. É uma falha clássica de CWE-200 (exposição de informação), diagnóstica por natureza: não lê arquivos, não executa nada, só confirma ou nega presença.

O atacante controla totalmente a lista de caminhos, nomes de host ou IPs testados, e como a técnica pode ser automatizada em JavaScript dentro da própria página maliciosa, é possível varrer dezenas ou centenas de caminhos em segundos, construindo um mapa do que está instalado na máquina (softwares de segurança, softwares específicos de determinado setor, topologia de rede interna) sem qualquer interação além da vítima abrir a página no IE.

A vulnerabilidade foi relatada publicamente por Soroush Dalili em abril de 2013, mas só recebeu o identificador CVE-2013-7331 e atenção ampla depois de ser observada em exploração ativa em fevereiro de 2014 — daí o descompasso entre o ano do CVE e a data de exploração.

A exploração exige apenas que a vítima abra, no Internet Explorer, uma página HTML controlada pelo atacante — não há necessidade de autenticação, configuração não padrão ou privilégio elevado. O vetor documentado foi watering hole: em fevereiro de 2014, o site do Veterans of Foreign Wars dos EUA foi comprometido e passou a servir a página maliciosa a visitantes, numa campanha que a FireEye rastreou como 'Operation SnowMan', atribuída ao grupo conhecido como DeputyDog.

Nessa campanha, a falha do XMLDOM não foi o payload final: funcionou como etapa de reconhecimento antes da entrega de um exploit de execução remota de código via 0-day do Adobe Flash (CVE-2014-0322). O atacante usava os erros do XMLDOM para verificar a presença de produtos de segurança instalados na máquina da vítima e, com base nisso, decidia se valia a pena disparar o exploit do Flash — uma forma de evitar detecção em ambientes instrumentados ou sandboxes de pesquisadores. O próprio catálogo KEV da CISA resume o impacto prático como 'permite detectar aplicações antimalware'.

Complexidade de exploração é baixa (AC:L, sem privilégios, sem interação especial do usuário) e existe módulo público no Metasploit, o que reduz a barreira para reuso da técnica fora do contexto original de espionagem. Isoladamente, o impacto é discovery de informação (confidencialidade baixa/parcial); o dano real depende de encadeamento com outra vulnerabilidade que dependa desse reconhecimento, como ocorreu em 2014.

No momento da divulgação original (fevereiro de 2014), o CERT/CC declarou explicitamente não conhecer uma solução prática para o problema — não havia flag de configuração ou desativação isolada do comportamento de erro do XMLDOM sem quebrar funcionalidade. A correção definitiva veio via atualização cumulativa do Internet Explorer, boletim MS14-052 (KB2977629), publicada em setembro de 2014 — cerca de sete meses após a exploração ativa observada, o que deixou uma janela de exposição considerável para quem dependia só de patch do fornecedor.

Como mitigação estrutural, o problema desapareceu com a descontinuação do Internet Explorer como navegador padrão e a desativação de controles ActiveX legados; ambientes que ainda mantêm IE em modo de compatibilidade ou aplicações internas que dependem dele continuam expostos se não tiverem os patches acumulados aplicados. Restringir ou desabilitar a execução de controles ActiveX no zonas de segurança do IE (Internet/Intranet) reduz a superfície, mas é controle geral, não específico desta falha, e pode quebrar aplicações legadas que dependem de ActiveX.

Não existe mitigação de rede eficaz (WAF ou proxy) porque a exploração ocorre inteiramente no lado do cliente, dentro do motor de renderização do IE — o servidor do atacante só entrega HTML/JS comum. A defesa real é não usar IE para navegação geral, aplicar KB2977629 (ou qualquer cumulativo posterior que o inclua) em sistemas que ainda dependem do navegador, e tratar a presença de IE em endpoints como superfície de ataque legada a ser eliminada, não apenas corrigida.

Não há assinatura de rede confiável e específica para esta falha: a exploração ocorre no lado do cliente, dentro do IE, via chamadas de script ao objeto Microsoft.XMLDOM testando caminhos e capturando códigos de erro — o tráfego HTTP em si é indistinguível de uma página comum a menos que se analise o conteúdo JavaScript entregue. Em ambientes corporativos, procurar por páginas que instanciam repetidamente o ActiveX Microsoft.XMLDOM com múltiplas tentativas de load() para caminhos locais, UNC ou res:// em sequência rápida é o padrão comportamental a inspecionar via análise de conteúdo/sandboxing, não via log de rede tradicional.

Como a exploração conhecida (Operation SnowMan) usou esta falha em conjunto com um exploit de Flash para entrega final, times de resposta devem correlacionar qualquer indício desse reconhecimento com atividade subsequente do Flash Player ou outros processos filhos anômalos do IE — a ausência desse encadeamento não descarta uso da falha isoladamente para fingerprinting, apenas indica que o incidente não seguiu o padrão documentado em 2014.