Microsoft Exchange Server Remote Code Execution Vulnerability

CVE-2021-26855 é a falha de Server-Side Request Forgery (SSRF) pré-autenticação que abre a cadeia de exploração conhecida como ProxyLogon contra o Microsoft Exchange Server. Ela permite que um atacante não autenticado, apenas enviando requisições HTTP para a porta 443 do servidor, force o Exchange a autenticar-se como o próprio sistema em componentes internos, servindo de porta de entrada para roubo de e-mail e, combinada com outras CVEs da mesma cadeia (26857, 26858, 27065), para execução remota de código completa. Foi explorada em massa por grupos de espionagem (atribuída pela Microsoft ao grupo HAFNIUM) antes da divulgação pública do patch, e depois por dezenas de outros atores, o que a torna uma das falhas de maior impacto real já registradas em servidores corporativos de e-mail.

A falha está no componente de acesso a clientes (Client Access Service / front-end HTTP proxy) do Exchange, responsável por repassar requisições recebidas na interface externa (ex: /owa, /ecp, /autodiscover, /mapi, /EWS) para os serviços de back-end que fazem o trabalho real de autenticação e processamento. O front-end confia em informações fornecidas na própria requisição HTTP — cabeçalhos e cookies do tipo X-AnonResource-Backend / X-BEResource — para decidir para qual back-end e com qual identidade a chamada deve ser encaminhada, sem validar adequadamente se quem enviou a requisição tinha permissão para especificar esse destino.

Isso é uma falha de SSRF (CWE-918): o atacante manipula o destino interno da requisição-proxy e faz o próprio servidor Exchange atuar como intermediário autenticado contra seus próprios serviços de back-end (ex: EWS, PowerShell remoto). Como o front-end e o back-end rodam na mesma máquina/floresta e o back-end confia implicitamente em chamadas vindas do front-end local, o atacante consegue fazer o Exchange executar operações — como acessar caixas de correio arbitrárias ou baixar dados — em nome de um usuário legítimo do sistema, sem apresentar credencial alguma.

O pesquisador Orange Tsai (DEVCORE), que reportou a cadeia à Microsoft em dezembro de 2020 através do programa Zero Day Initiative, descreveu o problema como decorrente da arquitetura de proxy interno do Exchange, que reutiliza a mesma pilha de autenticação NTLM/Kerberos de forma que o front-end pode ser convencido a se autenticar como usuário privilegiado (inclusive contas com privilégios de administrador do sistema) ao repassar a chamada. A CVE-2021-26855 isolada entrega SSRF; o impacto de RCE completo vem da combinação com CVE-2021-27065 (escrita arbitrária de arquivo pós-autenticação), que permite depositar um web shell no servidor.

O vetor é uma única requisição HTTP(S) para a porta 443/TCP do Exchange, sem qualquer autenticação prévia — não há necessidade de credencial, interação do usuário ou configuração não padrão. Isso explica o CVSS 9.1 com AV:N/AC:L/PR:N/UI:N: qualquer servidor Exchange exposto à internet (ou alcançável na rede pelo atacante) com o serviço de front-end HTTP ativo é alvo potencial. Isoladamente, a falha entrega SSRF que permite ler dados de caixas de correio arbitrárias (inclusive exportar e-mails de qualquer usuário) e obter tokens/cookies internos que sustentam os passos seguintes da cadeia.

Na exploração real observada em campo — atribuída pela Microsoft ao grupo HAFNIUM e posteriormente replicada por dezenas de outros atores após a divulgação pública — a CVE-2021-26855 foi usada como primeiro passo para localizar servidores back-end e extrair informações de autenticação, seguida por CVE-2021-26857 (desserialização insegura no Unified Messaging service) ou CVE-2021-27065 (escrita de arquivo pós-autenticação via ECP) para depositar web shells em diretórios do IIS, alcançando execução de código com privilégios de SYSTEM. Existem PoCs públicos, módulo Metasploit e templates Nuclei, o que baixou a barreira técnica para exploração massiva assim que os detalhes foram publicados em março de 2021.

A exploração em massa começou antes mesmo da liberação oficial dos patches — a Microsoft antecipou a correção justamente por já haver exploração ativa in-the-wild identificada por parceiros de telemetria (Volexity, DEVCORE). A CISA emitiu diretiva de emergência para agências federais dos EUA em resposta, e o CVE está no catálogo KEV com exploração confirmada.

A correção definitiva é aplicar as atualizações cumulativas de segurança liberadas pela Microsoft em 2 de março de 2021 (e atualizações posteriores que as sucederam) para a linha de CU específica instalada — não é possível corrigir sem estar em uma Cumulative Update suportada, e instalar o patch de segurança exige primeiro estar no CU correto (Exchange 2013 CU23; Exchange 2016 CU10 a CU14, conforme os produtos listados no advisory da Microsoft para este CVE — e, segundo o mesmo boletim, também Exchange Server 2019 nas CUs suportadas na época). Não há como aplicar retroativamente esse patch em CUs anteriores às listadas: é necessário atualizar o Exchange para uma CU corrigível antes de aplicar o pacote de segurança.

Se a atualização imediata não for viável, a Microsoft publicou mitigações paliativas (regras de URL Rewrite no IIS para bloquear os padrões de requisição usados no SSRF, e desativar serviços não usados como Unified Messaging, EWS ou ECP quando não necessários) — isso reduz superfície mas não elimina a vulnerabilidade em si e pode quebrar funcionalidades legítimas (OWA, ActiveSync, EWS de terceiros). Restringir o acesso ao Exchange a partir da internet (VPN, allowlist de IP) reduz a exposição, mas servidores já expostos por meses antes do patch devem ser tratados como potencialmente comprometidos, não apenas corrigidos — aplicar o patch sozinho não remove web shells ou backdoors já implantados.

O mito relevante aqui é achar que atualizar o Exchange depois do fato resolve tudo: como a exploração massiva ocorreu antes da divulgação do patch, qualquer servidor Exchange exposto entre o início da campanha (que a Microsoft e Volexity situam em janeiro de 2021) e a aplicação do patch precisa de varredura de comprometimento (web shells, contas criadas, exportação de caixas de correio) independentemente de estar corrigido hoje.

Sinais em log do IIS do Exchange: requisições HTTP para caminhos como /owa/ ou /ecp/ contendo cookies ou cabeçalhos anômalos do tipo X-AnonResource-Backend e X-BEResource, especialmente combinadas com respostas 200/301 fora do padrão esperado, e presença de arquivos .aspx recém-criados em diretórios do front-end (ex: pastas de autenticação do OWA) que não correspondem a binários legítimos do Exchange — indício de web shell (China Chopper foi amplamente observado nessa campanha). A Microsoft publicou um script de verificação (Test-ProxyLogon) e IOCs específicos para essa cadeia.

Como a exploração inicial via SSRF não deixa necessariamente rastro visível de autenticação (é justamente pré-autenticação), a ausência de erro de login nos logs não indica ausência de exploração — o sinal mais confiável é a varredura de artefatos pós-exploração (web shells, novos usuários, exportações de mailbox, processos w3wp.exe gerando filhos suspeitos como cmd.exe ou csc.exe) e não apenas o tráfego de rede em si.