CVE-2020-0618

Falha de desserialização insegura (CWE-502) no ViewState do SQL Server Reporting Services (SSRS), que permite execução remota de código no contexto da conta de serviço do Report Server. O CVSS de 9.8 sugere ataque trivial e não autenticado, mas o próprio catálogo KEV da CISA descreve o requisito real: o atacante precisa de uma conta autenticada, mesmo com privilégios mínimos, no portal/Report Manager do SSRS.

O SSRS processa requisições de página (relatórios, portal web) usando o mecanismo de ViewState do ASP.NET para manter estado entre requisições. O componente falha ao validar/desserializar corretamente o ViewState recebido do cliente, permitindo que um payload manipulado seja desserializado pelo servidor antes de qualquer verificação de integridade suficiente — o clássico padrão de CWE-502 (Deserialization of Untrusted Data).

Como o processo de desserialização instancia objetos .NET a partir de dados controlados pelo atacante, é possível construir uma cadeia de gadgets que, ao ser reconstruída pelo runtime, executa código arbitrário. O código resultante roda com os privilégios da conta de serviço do Report Server (SQL Server Reporting Services service account), não com os privilégios do usuário autenticado que enviou a requisição — daí a gravidade mesmo exigindo autenticação prévia.

A superfície de ataque é o próprio protocolo de comunicação entre o navegador e o SSRS Web Portal/Report Server, especificamente os endpoints que processam page requests e devolvem/recebem o campo __VIEWSTATE. O atacante controla o conteúdo desse campo; o servidor confia nele o suficiente para desserializar antes de validar completamente sua origem.

O vetor é HTTP(S) contra a interface web do SSRS (Report Manager / Web Portal). O pré-requisito central — e a informação mais importante que a manchete de CVSS 9.8 omite — é autenticação: o atacante precisa de uma conta válida no SSRS, ainda que com permissões baixas (ex.: apenas visualizar relatórios). Não é necessário acesso administrativo nem configuração não padrão além de ter o serviço exposto e acessível na rede.

Com uma sessão autenticada, o atacante envia uma requisição de página contendo um ViewState malicioso; o servidor desserializa o payload e executa a cadeia de gadgets embutida, resultando em RCE no contexto da conta de serviço do Report Server — que em muitos ambientes tem privilégios elevados no SQL Server e no sistema operacional subjacente, permitindo movimento lateral e comprometimento do banco.

Existe PoC pública, módulo Metasploit e template Nuclei, o que reduz a complexidade de exploração a praticamente zero para quem já possui uma credencial válida. A CISA incluiu a falha no catálogo KEV em setembro de 2024 — quatro anos após a publicação — indicando exploração ativa recente, não apenas teórica, provavelmente aproveitando ambientes SSRS legados nunca corrigidos e credenciais obtidas por outros meios (phishing, reuso de senha, contas de serviço fracas).

A correção definitiva é aplicar a atualização de segurança da Microsoft de fevereiro de 2020 para a linha de branch específica em uso (GDR ou CU) de SQL Server 2014 SP3 e SQL Server 2016 SP2. Não há número de build de correção detalhado nas fontes consultadas para cada branch — confirme a versão exata instalada e aplique o patch correspondente listado no advisory MSRC antes de considerar o ambiente corrigido, já que GDR e CU seguem trilhas de atualização diferentes e um patch de uma trilha não cobre a outra.

Se a atualização não puder ser aplicada imediatamente, o paliativo real é reduzir a exposição: restringir acesso de rede à interface do SSRS (Report Manager/Web Portal) a hosts e usuários estritamente necessários, revisar e minimizar quem possui contas autenticáveis no SSRS, e monitorar/registrar autenticações e requisições anômalas. Isso reduz a janela de ataque mas não elimina a vulnerabilidade — qualquer conta autenticada válida ainda pode explorar a falha.

A orientação da CISA no KEV é explícita: aplicar a mitigação do fornecedor ou descontinuar o uso do produto se não houver mitigação disponível — reforçando que não existe workaround de configuração que neutralize o problema sem o patch. Não confundir isolamento de rede com correção: reduzir superfície não impede exploração por um usuário interno ou por credencial comprometida.

Nos logs do SSRS/Report Server e do servidor web (IIS, se aplicável), procurar requisições POST anômalas para endpoints de relatórios com campos __VIEWSTATE de tamanho ou estrutura fora do padrão, especialmente vindos de contas com histórico de uso mínimo do portal. Exceções de desserialização registradas nos logs de aplicação do Reporting Services, ou processos filhos inesperados sendo gerados a partir do serviço do Report Server (ReportingServicesService.exe), são indicadores fortes de tentativa de exploração — mas não há assinatura de rede única e confiável documentada nas fontes consultadas, o que torna a detecção dependente de logging de aplicação habilitado e de correlação com autenticações incomuns.