Sitecore Products ViewState Deserialization Vulnerability

A falha não está no código do Sitecore, mas numa prática de implantação: guias de deployment da Sitecore publicados até 2017 traziam um ASP.NET machine key de exemplo fixo, que muitos administradores copiaram para produção sem gerar uma chave própria. Quem usa essa chave amostra perde a proteção do ViewState do ASP.NET, permitindo que qualquer atacante sem autenticação crie payloads que o servidor deserializa como legítimos, resultando em execução remota de código. A CISA confirma exploração ativa em campo, incluindo instalação de backdoors e movimento lateral.

O ASP.NET usa um campo oculto __VIEWSTATE para persistir estado de página entre requisições. Esse campo é criptografado e assinado com um machine key configurado no web.config; o servidor confia que qualquer ViewState que valide a assinatura veio de uma página legítima gerada por ele mesmo. Se o machine key for previsível ou público — como o valor de exemplo distribuído em guias de instalação da Sitecore de 2017 ou anteriores —, um atacante pode gerar a assinatura correta para um payload arbitrário, e o servidor o deserializa sem suspeitar. Isso é uma instância clássica de CWE-502 (Deserialization of Untrusted Data).

A superfície de ataque encontrada pela Mandiant foi a página /sitecore/blocked.aspx, um componente legítimo do Sitecore que existe para avisar sobre bloqueios de licenciamento e é acessível sem autenticação. Como qualquer página ASP.NET com ViewState habilitado, ela aceita POSTs contendo o campo __VIEWSTATE, e é justamente esse ponto de entrada — não uma falha exclusiva dessa página específica — que viabiliza o ataque em qualquer endpoint com ViewState ativo no host comprometido.

O problema não é uma falha de parsing ou de lógica de negócio: é a ausência de segredo real protegendo a integridade do ViewState. Uma vez com o machine key em mãos (seja porque está em um guia público, seja porque foi extraído de outro deployment com a mesma configuração padrão), o atacante usa ferramentas públicas de geração de gadget chains .NET (como ysoserial.net) para montar um payload de deserialização que, ao ser processado pelo servidor, executa código arbitrário no contexto do processo IIS/w3wp.

Pré-requisito central: o servidor Sitecore precisa estar usando o machine key de exemplo exposto nos guias de deployment antigos (2017 ou anteriores) — não é uma vulnerabilidade que afete qualquer instalação Sitecore por padrão, mas sim aquelas que nunca substituíram esse valor por uma chave gerada de forma única. Isso inclui, segundo a Mandiant, deployments do Sitecore XP 9.0 e do Active Directory 1.4 e versões anteriores que usaram o guia com a chave amostra. Não é necessária autenticação nem qualquer configuração adicional além de o endpoint com ViewState estar exposto na internet.

Na exploração observada pela Mandiant, o atacante varreu o servidor em busca de endpoints, convergiu para /sitecore/blocked.aspx (acessível sem login) e enviou um POST com um __VIEWSTATE malicioso construído com o machine key conhecido. O IIS registrou isso como falha de verificação de ViewState (Event ID 1316) nos logs do Windows, mas a falha de verificação não impediu a execução: o payload continha um assembly .NET embutido (rastreado pela Mandiant como WEEPSTEEL) que, ao ser deserializado, executou código de reconhecimento — coleta de informações de sistema, disco, rede e processos, exfiltradas disfarçadas de resposta __VIEWSTATE benigna.

A campanha documentada evoluiu de RCE inicial para reconhecimento de host, arquivamento do diretório raiz da aplicação web (visando arquivos como o web.config, que contém o próprio machine key), reconhecimento de rede e Active Directory com SharpHound, criação de contas administrativas locais, dump de hives SAM/SYSTEM, movimento lateral via RDP com credenciais comprometidas e persistência via DWAgent e tunelamento com Earthworm. A CISA classifica isso como exploração ativa confirmada e exige mitigação por agências federais até 25/09/2025.

A mitigação real é substituir o machineKey exposto por um valor único e gerado de forma segura no web.config de cada instalação Sitecore afetada — não existe patch de código que resolva isso, porque o problema é uma chave compartilhada publicamente, não um bug de lógica. A Sitecore confirma que implantações atualizadas passaram a gerar automaticamente uma chave única durante a instalação, e que clientes identificados como afetados foram notificados diretamente. Organizações devem verificar se seu web.config usa algum valor de machineKey que corresponda ao publicado nos guias de deployment antigos (2017 ou anteriores) e, se sim, gerar uma chave nova e rotacionar imediatamente, invalidando sessões e ViewStates existentes.

Como controle compensatório, restringir ou desabilitar o acesso público a endpoints com ViewState desnecessários (como páginas de erro/licenciamento que não precisam estar expostas), aplicar EnableViewStateMac e criptografia de ViewState corretamente configurados, e colocar WAF/regras de bloqueio para POSTs anômalos com payloads __VIEWSTATE grandes em endpoints não esperados ajudam a reduzir a superfície, mas não substituem a rotação da chave — se o atacante já tem o machine key, essas medidas são apenas atrito, não bloqueio.

Não funciona como mitigação apenas atualizar para uma versão mais nova do Sitecore sem verificar e trocar o machine key: a vulnerabilidade persiste enquanto a chave de exemplo estiver em uso, independentemente da versão do produto instalada.

Nos logs de eventos do Windows (Application), procure pelo Event ID 1316 com a mensagem 'Viewstate verification failed' — a Mandiant observou esse evento coincidindo com o payload malicioso mesmo antes da exploração ter sucesso, já que a falha de verificação registrada no log não impede a execução do código deserializado. Nos logs do IIS, POSTs para endpoints com ViewState (a campanha observada usou /sitecore/blocked.aspx) sem sessão prévia esperada, especialmente vindos de fontes externas, são suspeitos, assim como campos __VIEWSTATE anormalmente grandes (o exemplo documentado tinha 27.760 bytes codificados).

A ausência desses sinais não garante ausência de exploração: se o machine key exposto foi usado, a técnica é praticamente indistinguível de tráfego legítimo do ASP.NET a menos que se monitore explicitamente por falhas de verificação de ViewState e correlação com criação de arquivos .dll incomuns ou atividade de reconhecimento (WEEPSTEEL) subsequente, como arquivamento de diretórios, criação de contas locais e uso de ferramentas como SharpHound, DWAgent ou Earthworm.