CVE-2020-0688

Falha de deserialização no Exchange Control Panel (ECP) do Microsoft Exchange Server que permite execução remota de código como SYSTEM. Exige autenticação — qualquer conta de caixa de correio válida, mesmo sem privilégios administrativos — o que reduz o requisito de acesso, mas ainda assim é considerada crítica porque compromete o servidor inteiro, não apenas a caixa do usuário autenticado. Está no catálogo KEV da CISA com exploração confirmada e possui módulo Metasploit e PoC públicos desde fevereiro de 2020.

O problema está no mecanismo de ViewState do ASP.NET usado pela aplicação web ECP do Exchange. Segundo a Zero Day Initiative (ZDI-20-258), o produto falha em gerar uma chave criptográfica única durante a instalação — a mesma chave (ou um valor derivado de forma previsível) é usada para assinar/validar o ViewState em instalações diferentes. Isso quebra a garantia de integridade que o MAC do ViewState deveria oferecer.

Como a chave de validação é previsível, um atacante consegue forjar um ViewState malicioso que passa a verificação de integridade do ASP.NET. O ASP.NET então desserializa esse ViewState — que contém dados controlados pelo atacante — instanciando objetos arbitrários. Esse padrão é uma deserialização de dados não confiáveis clássica (CWE-502), viabilizada por uma chave criptográfica fixa/previsível (CWE-321/CWE-330). A CISA classifica a falha sob CWE-287 (Improper Authentication), enfatizando que a raiz é a ausência de unicidade da chave gerada no install, mas o impacto prático é execução de código via desserialização.

O pool de aplicação do ECP no IIS roda com privilégios de SYSTEM, então qualquer código desserializado e executado nesse contexto herda esse nível de acesso — daí o CVSS C:H/I:H/A:H mesmo com PR:L (privilégio baixo) no vetor.

A exploração exige autenticação: o atacante precisa de credenciais válidas de uma conta com caixa de correio no Exchange (não precisa ser administrador) e acesso de rede ao endpoint ECP, normalmente exposto junto com o OWA em implantações com Exchange voltado à internet. Não há interação de usuário adicional (UI:N) além do próprio atacante autenticado enviando a requisição.

Com credenciais em mãos, o atacante monta uma requisição ao ECP contendo um ViewState malicioso assinado com a chave previsível/fixa da instalação, forçando o ASP.NET a desserializar um payload que resulta em execução de comando no contexto do processo do app pool — SYSTEM. Isso dá controle total do servidor Exchange, não apenas da conta usada para autenticar, o que é o salto de privilégio real da falha.

Há PoC pública, módulo Metasploit e a vulnerabilidade está no catálogo KEV da CISA, confirmando exploração ativa em campanhas reais — inclusive combinada com técnicas de obtenção de credenciais de baixo privilégio (phishing, spraying) como passo prévio, já que a barreira de entrada é justamente ter qualquer conta válida.

A correção é aplicar as atualizações de segurança de fevereiro de 2020 da Microsoft para a linha específica de Exchange em uso (2010 SP3, 2013, 2016 CU14/CU15, 2019 CU3/CU4 conforme listado no advisory). Não há paliativo equivalente a patch: a raiz do problema é a chave de validação gerada de forma insegura no install, e não existe flag de configuração documentada pela Microsoft que regenere essa chave corretamente sem aplicar a atualização.

Como mitigação compensatória enquanto o patch não é aplicado, restringir o acesso ao ECP (e ao OWA/ECP combinados) apenas a redes confiáveis ou VPN reduz a superfície de exposição, já que a maioria dos cenários de exploração observados depende de alcançar o endpoint remotamente pela internet. Isso não corrige a falha, apenas limita quem pode tentar.

MFA e políticas de senha forte não neutralizam esta vulnerabilidade — o pré-requisito é qualquer conta autenticada válida com caixa de correio, e uma vez a sessão estabelecida a exploração ocorre no nível da aplicação web, não no processo de login. Segmentar contas por privilégio também não ajuda, pois PR:L basta.

Requisições autenticadas ao endpoint /ecp/ com parâmetros __VIEWSTATE anormalmente grandes ou malformados, vindas de contas com histórico de uso atípico do ECP, são um indício. Em nível de sistema, o processo do app pool do ECP (w3wp.exe rodando como MSExchangeECPAppPool) gerando processos filho inesperados (cmd.exe, powershell.exe, csc.exe) é um sinal forte de exploração bem-sucedida, já que a execução de código ocorre no contexto desse worker process. Não há assinatura de rede única e confiável documentada nas fontes consultadas — a detecção depende de correlacionar logs de IIS/ECP com telemetria de processo no host.