CVE-2020-0646

Falha de validação de entrada no Microsoft .NET Framework que permite execução remota de código, catalogada pela Microsoft como '.NET Framework Remote Code Execution Injection Vulnerability'. Está no catálogo KEV da CISA (CWE-91, injeção de XML) por exploração confirmada em campo, mas a exploração documentada publicamente ocorre via SharePoint — que usa o Windows Workflow Foundation do .NET Framework para processar workflows em formato XOML — e não como RCE anônimo direto contra o runtime do .NET isolado. O CVSS 9.8 (PR:N, sem interação do usuário) reflete o cenário genérico do framework, não necessariamente o vetor real mais explorado.

A causa raiz é falta de validação/sanitização adequada de marcação XAML/XOML processada pelo Windows Workflow Foundation, componente do .NET Framework. O CISA KEV classifica a falha como CWE-91 (Injeção de XML / Blind XPath Injection), o que é consistente com a natureza do problema: dados de entrada tratados como estruturas de workflow são interpretados sem os limites de tipo e escopo esperados, permitindo que marcação controlada pelo atacante seja compilada e executada pelo mecanismo de workflow.

O vínculo mais documentado publicamente (referenciado no PacketStorm como 'SharePoint Workflows XOML Injection') é o uso do SharePoint como consumidor do Workflow Foundation: o SharePoint permite a criação e importação de workflows definidos em XOML, e o processamento desse XOML pelo runtime do .NET Framework é o ponto onde a injeção ocorre. Um workflow malicioso, ao ser compilado/executado pelo servidor, pode escapar do sandbox de expressões esperado e disparar execução de código arbitrário no contexto do processo que hospeda o workflow (tipicamente o worker process do IIS/SharePoint).

A Microsoft não publicou detalhes profundos de código-fonte no advisory (texto completo do MSRC não constava nas fontes revisadas), mantendo a descrição genérica de 'falha de validação de entrada'. Isso limita a precisão de qualquer descrição de mecanismo interno específico do parser XOML/Workflow Compiler além do que pesquisadores externos já correlacionaram.

O vetor mais citado por pesquisadores e refletido em módulos de exploração públicos exige acesso autenticado a um ambiente SharePoint com permissão para criar, importar ou publicar workflows (nível de permissão equivalente a Designer/Editor do site) — não é uma exploração anônima pura contra a rede, mesmo que o CVSS oficial marque PR:N. O atacante cria ou modifica um workflow XOML malicioso e o submete ao mecanismo de workflow do SharePoint; ao ser processado pelo Workflow Foundation, o conteúdo injetado é executado no contexto do processo do servidor, que em muitas instalações roda com privilégios elevados (identidade do application pool).

Existe PoC pública e módulo Metasploit associados à falha, o que reduz a complexidade prática de reprodução para quem já possui as credenciais/permissões de pré-requisito. A CISA confirma exploração ativa em campo (motivo da inclusão no KEV), mas não há indicação de uso em campanhas de ransomware conhecidas segundo o próprio catálogo.

O resultado final da exploração é execução de código arbitrário no servidor que hospeda o workflow (ou, em cenários fora do SharePoint, no processo que compila/executa o XAML malicioso via .NET Framework), o que normalmente se traduz em comprometimento total do host afetado.

A ação primária é aplicar as atualizações de segurança da Microsoft do ciclo de janeiro de 2020 (Patch Tuesday) correspondentes à combinação exata de sistema operacional e versão do .NET Framework instalada — as combinações afetadas variam por build do Windows (10 1607, 1709, Server 2016) e por versão do .NET Framework (3.0, 3.5, 3.5.1, e as combinações 3.5+4.6.2/4.7/4.7.1/4.7.2). Não foram confirmados nesta pesquisa os números exatos de KB por combinação; use o Microsoft Update Catalog/WSUS filtrando pela build e versão do .NET instalada para obter o pacote correto.

Como controle compensatório quando o patch não pode ser aplicado imediatamente em ambientes com SharePoint: restringir a permissão de criação/edição de workflows a um grupo mínimo de usuários confiáveis, já que o vetor documentado depende dessa capacidade; isso reduz a superfície mas não elimina a falha subjacente no processamento de XOML pelo .NET Framework.

Não funciona como mitigação: desativar apenas recursos de interface do SharePoint sem revogar a permissão de gestão de workflows, nem confiar em WAF genérico de camada HTTP, já que a injeção ocorre na camada de processamento de workflow/XAML do runtime, não em um padrão de payload HTTP trivialmente assinável.

Em ambientes SharePoint, monitorar criação/edição/importação de workflows (arquivos XOML) por usuários fora do padrão esperado, especialmente uploads ou modificações feitas fora de fluxos administrativos normais. No lado de host, procurar por processos filhos anômalos gerados pelo worker process do IIS/SharePoint (w3wp.exe) imediatamente após operações de workflow, o que indicaria execução de código pós-injeção. Não há assinatura de rede genérica confiável para a falha em si, já que o vetor documentado atua na camada de aplicação/processamento de workflow, não em um padrão de pacote de rede distinto.