CVE-2017-8759

Falha de execução remota de código no Microsoft .NET Framework, explorada in-the-wild desde setembro de 2017 via documentos do Office (RTF no Word, e depois demonstrado também via PPSX/PPTX no PowerPoint). O problema está na camada de parsing de WSDL do .NET, não no Office em si — o Office é só o vetor de entrega que aciona o componente vulnerável. Está no catálogo KEV da CISA com exploração confirmada e PoC pública amplamente disponível, o que a torna prioridade mesmo tendo CVSS 'apenas' 7.8 e exigir interação do usuário.

A vulnerabilidade está no método IsValidUrl da classe WsdlParser, dentro de System.Runtime.Remoting, componente do .NET Framework responsável por interpretar arquivos WSDL (Web Services Description Language) durante a geração de proxies de cliente SOAP. Quando um WSDL contém múltiplas definições de endereço, o parser normalmente comenta as definições subsequentes ao gerar o código-fonte C# correspondente (via PrintClientProxy). Antes da correção, IsValidUrl garante apenas que a string esteja entre aspas, mas não filtra sequências CRLF (\r\n).

Isso permite que um atacante, controlando o conteúdo do WSDL, injete uma sequência CRLF seguida de código C# arbitrário dentro da string que será escrita no arquivo .cs gerado. Esse arquivo é posteriormente compilado pelo csc.exe e carregado como DLL pelo processo que solicitou o proxy — no cenário explorado, o Microsoft Word ou PowerPoint. O resultado é execução de código no contexto do usuário que abriu o documento, sem exigir qualquer exploração de memória: é uma falha de validação de entrada (CWE-20, conforme classificado pela CISA) que se transforma em geração e compilação de código atacante-controlado.

O vetor de entrega documentado pela FireEye (que descobriu a exploração em campanhas reais) usa um objeto OLE2Link/StdOleLink embutido em um arquivo RTF, cujo moniker aponta para uma URL remota servindo o WSDL malicioso — mecanismo de ativação de moniker similar ao usado na família CVE-2017-0199. A NCC Group demonstrou, em análise pública, que a mesma técnica de moniker é portável para o formato PPSX/PPTX do PowerPoint, usando um 'OLE Verb' de animação para ativar automaticamente o objeto vinculado ao abrir a apresentação — evidenciando que a superfície de exploração não se limita ao RTF, ao contrário do que a cobertura inicial sugeria.

O vetor prático é um documento malicioso (RTF para Word, ou PPSX/PPTX para PowerPoint) enviado por e-mail ou disponibilizado para download. O documento contém um objeto OLE vinculado (StdOleLink) cujo caminho foi substituído por um moniker que aponta para um recurso remoto controlado pelo atacante. Ao abrir o arquivo — no PPSX isso pode ocorrer de forma automática, sem clique adicional, pois o slideshow inicia e o 'OLE Verb' ativa o objeto — a aplicação Office solicita o recurso remoto, que devolve um WSDL contendo a injeção CRLF. O .NET Framework compila esse WSDL malformado, executando o payload injetado.

Pré-requisito real: interação do usuário para abrir o arquivo (o CVSS reflete isso com UI:R) e acesso de rede de saída do host até o servidor do atacante (para buscar o WSDL/HTA/SCT remoto) — não há exploração puramente de rede sem essa etapa de entrega e abertura. AV:L no vetor CVSS reflete que a exploração ocorre através do processamento local do arquivo pela aplicação, não por um serviço de rede exposto. Não é necessária autenticação nem configuração fora do padrão: qualquer instalação padrão do .NET Framework nas versões afetadas, combinada com Office instalado, é suscetível.

A exploração já foi observada em campanhas reais antes da divulgação pública (documentada pela FireEye), e existe toolkit público (bhdresh/CVE-2017-8759) que automatiza a geração do RTF malicioso e a entrega de payload via Metasploit/meterpreter, reduzindo a barreira técnica para reprodução. O resultado final é execução de código arbitrário no contexto do usuário — de onde normalmente segue movimentação lateral, persistência ou entrega de segunda etapa (o CISA KEV não indica uso confirmado em ransomware, mas classifica como 'Unknown', não descartado).

A correção definitiva é aplicar as atualizações de segurança da Microsoft de setembro de 2017 para as versões afetadas do .NET Framework (2.0, 3.5, 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7), distribuídas via Windows Update / Microsoft Update Catalog conforme a combinação de sistema operacional e versão do .NET instalada. O advisory da Microsoft (MSRC) lista os KBs específicos por combinação de Windows e versão do .NET — como cada ambiente tem uma combinação diferente, o número de KB exato varia e deve ser confirmado no boletim oficial para o seu SO/versão, não há uma única 'versão corrigida' numérica do .NET Framework que substitua as anteriores da mesma forma que um patch de aplicação.

Como paliativo quando a atualização não é imediata: bloquear ou restringir a execução de csc.exe e a criação de proxies SOAP a partir de processos do Office (via AppLocker, WDAC ou regras de EDR) reduz a superfície, já que a cadeia de exploração depende da compilação dinâmica de C#. Desabilitar a abertura automática de conexões externas em documentos do Office (bloqueio de rede de saída para processos winword.exe/powerpnt.exe, ou Attack Surface Reduction rules que bloqueiam criação de processos filho por aplicações do Office) também mitiga o vetor de entrega, sem corrigir a falha em si.

Não funciona como mitigação: desabilitar apenas macros do Office — a exploração não usa VBA/macro, usa ativação de objeto OLE/moniker, então políticas de bloqueio de macro não têm efeito algum aqui. Da mesma forma, atualizar somente o Office sem atualizar o .NET Framework não resolve, pois a vulnerabilidade está no framework, não no Office.

Sinais de tentativa de exploração incluem: documentos RTF ou de apresentação (PPSX/PPTX) contendo objetos OLE2Link/StdOleLink cujo destino, em vez de um caminho de arquivo local, é uma URL externa ou moniker do tipo script:/http: apontando para recurso remoto (visível ao inspecionar os arquivos .rels dentro do pacote OOXML ou os campos de objeto vinculado em RTF); tráfego de saída de winword.exe ou powerpnt.exe para hosts externos solicitando arquivos com conteúdo WSDL, .hta ou .sct; e, no host, execução de csc.exe (compilador C#) tendo como processo pai winword.exe, powerpnt.exe ou explorer.exe pouco depois da abertura do documento — essa cadeia de processo é o indicador mais confiável, já que a compilação dinâmica é etapa obrigatória da exploração.

Como a técnica de moniker é compartilhada com outras vulnerabilidades da mesma família (ex. CVE-2017-0199), regras de detecção baseadas apenas em 'presença de OLE2Link' geram falsos positivos/negativos entre essas CVEs distintas — a NCC Group destaca esse ponto explicitamente; é necessário correlacionar com o conteúdo do recurso remoto buscado (WSDL malformado com CRLF) ou com a cadeia de processo csc.exe para diferenciar.