CVE-2020-1147
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply updates per vendor instructions.
Resumo
Falha de deserialização insegura no tratamento de XML usado pelas classes DataSet/DataTable do .NET Framework, que também afeta SharePoint Server e Visual Studio por dependerem do mesmo componente. Está no catálogo KEV da CISA com exploração confirmada e tem EPSS de 0,94 — risco real, mas o vetor exige que uma aplicação alimente XML controlado pelo atacante nessa rotina de desserialização, não é um buraco de rede aberto por padrão.
Detalhamento técnico
O problema está na forma como DataSet/DataTable leem esquemas XML (via ReadXml e correlatos). Ao processar o markup, o componente aceita atributos de esquema (como msdata:DataType, documentado publicamente por pesquisadores em torno de ferramentas como ysoserial.net) que indicam qual tipo .NET deve ser instanciado para preencher uma coluna, sem validar se esse tipo é seguro para ser criado a partir de dados não confiáveis. Isso é uma instância de CWE-502 (Deserialization of Untrusted Data): o atacante controla o nome do tipo e os dados usados para popular suas propriedades, permitindo encadear um gadget de desserialização (tipos com side-effects no construtor, setter ou finalizer) até execução de código no contexto do processo que fez a chamada.
A descrição oficial da Microsoft — 'falha ao verificar o source markup de entrada XML' — é justamente essa ausência de allowlist de tipos na leitura do esquema. Por afetar diretamente classes do próprio .NET Framework (System.Data), qualquer software que desserialize DataSet/DataTable a partir de XML não confiável herda o problema: daí a lista de produtos afetados abranger .NET Framework isolado, SharePoint (que usa DataSet/DataTable em ViewState e em componentes de WebPart) e Visual Studio (que processa arquivos de projeto/dados com o mesmo mecanismo).
O vetor CVSS informado (AV:L/AC:L/PR:N/UI:R) chama atenção: apesar do título 'Remote Code Execution', a NVD trata como ataque local com interação do usuário, porque a explotação genérica depende de convencer a vítima a abrir um arquivo ou processar conteúdo malicioso em uma aplicação vulnerável — não é um payload que chega sozinho pela rede sem essa mediação, salvo em cenários onde a própria aplicação (como SharePoint) expõe um endpoint que aceita a entrada perigosa de usuários autenticados.
Como é explorada
Existem dois cenários distintos documentados publicamente. No primeiro, genérico para .NET Framework/Visual Studio, o atacante precisa que a vítima abra um arquivo ou que uma aplicação local processe XML malicioso via DataSet/DataTable — isso justifica o UI:R e AV:L do CVSS. No segundo, específico de SharePoint (referenciado nos writeups 'SharePoint DataSet/DataTable Deserialization' e nas provas de conceito de RCE para SharePoint Server 2019), um usuário autenticado — muitas vezes com privilégios baixos — consegue submeter o XML malicioso através de funcionalidades do SharePoint que desserializam DataSet (ViewState de WebParts, endpoints SOAP/REST), obtendo execução no contexto do app pool do IIS, que costuma rodar com privilégios elevados no servidor.
Há PoC pública e módulo Metasploit disponíveis, o que reduz bastante a barreira técnica para quem já tem o pré-requisito de acesso (arquivo aberto pela vítima, ou conta autenticada no SharePoint). O EPSS de 0,94 reflete essa maturidade de exploração — está entre as CVEs com maior probabilidade observada de tentativa de exploração no mundo real.
A CISA confirma exploração ativa ao incluir a falha no KEV (adicionada em 2021-11-03), mas não classifica como usada em campanhas de ransomware conhecidas ('Unknown' no campo correspondente). Não há, nas fontes disponíveis, detalhamento público de quem exatamente foi alvo ou de qual ator explorou a falha — apenas a confirmação de exploração e o prazo de correção (2022-05-03) para agências federais dos EUA.
Versões
Como se proteger
A correção veio nas atualizações de segurança de 14 de julho de 2020 (Patch Tuesday), aplicadas de forma diferente por combinação de sistema operacional e versão do .NET Framework — não há um único número de build ou KB válido para todos os casos listados. Para saber exatamente qual atualização instalar em cada combinação (.NET Framework 2.0/3.0/3.5/3.5.1 isolados, ou 3.5 combinado com 4.6.2/4.7/4.7.1/4.7.2 no Windows 10 1607 ou Windows Server 2016), é necessário consultar o advisory oficial da Microsoft (MSRC) para o par específico de SO e versão de framework instalado — inventar aqui um número de KB seria mais perigoso do que não informar.
Para SharePoint Server e Visual Studio, o mesmo princípio se aplica: aplicar a atualização de segurança específica do produto/versão publicada em julho de 2020. Não existe paliativo de configuração conhecido e documentado nas fontes consultadas (como desabilitar um recurso ou aplicar uma flag) que neutralize a falha sem o patch — a mitigação real é a atualização do binário do .NET Framework, já que o problema está no próprio componente de desserialização, não em uma opção que possa ser desligada.
O que não funciona: restringir acesso de rede não resolve o caso SharePoint, porque a exploração passa por autenticação legítima na aplicação, não por acesso anônimo à porta. Da mesma forma, WAF genérico tem eficácia limitada contra desserialização, já que o payload malicioso é XML válido do ponto de vista de esquema — bloquear por assinatura de payload conhecido (ex.: presença de msdata:DataType apontando para tipos de gadget conhecidos) é possível como controle compensatório temporário, mas não substitui o patch.
Como detectar
Não há lista pública de IOCs específica para esta CVE nas fontes disponíveis. Como sinal indireto, vale monitorar payloads XML de DataSet/DataTable (inclusive dentro de ViewState base64 em aplicações ASP.NET/SharePoint) que referenciem tipos .NET incomuns via atributos de esquema (msdata:DataType) — especialmente tipos historicamente usados em cadeias de gadget de desserialização. Em ambientes SharePoint, processos do app pool do IIS (w3wp.exe) ou do timer service (OWSTIMER.exe) gerando processos filhos inesperados como cmd.exe ou powershell.exe é o sinal comportamental mais confiável de exploração pós-desserialização, já que a assinatura do payload em si pode variar bastante entre gadgets.