CVE-2017-9822

Falha de deserialização insegura no cookie de personalização do DotNetNuke (DNN) que permite execução remota de código no servidor, sem exigir acesso a áreas administrativas. Afeta qualquer instalação DNN anterior à versão 9.1.1 exposta publicamente. Está no catálogo KEV da CISA por exploração confirmada em campo, tem módulo Metasploit e template Nuclei prontos, o que reduz a barreira de exploração a praticamente zero para quem sabe identificar a instância.

O DNN processa um cookie de personalização (usado para lembrar preferências de sessão do usuário) desserializando seu conteúdo no servidor com componentes do .NET Framework — o padrão documentado publicamente para essa falha é o uso de ObjectStateFormatter/LosFormatter sobre dados vindos diretamente do cookie, sem validação de origem ou de tipo. Isso é uma instância clássica de deserialização de dados não confiáveis (CWE-502); a CISA classifica a entrada no KEV como CWE-20 (validação inadequada de entrada), o que reflete a causa raiz mais ampla: o servidor confia em uma estrutura recebida do cliente e a reconstrói em objetos .NET sem checagem.

O vetor é HTTP: o atacante envia uma requisição com um cookie de personalização forjado contendo uma cadeia de gadgets .NET serializada. Ao ser desserializado pelo servidor, esse payload aciona execução de código arbitrário no contexto do processo IIS/ASP.NET que hospeda o DNN — sem necessidade de autenticação prévia na prática relatada por pesquisadores e refletida no módulo Metasploit e no PoC público, já que o cookie é processado antes de qualquer verificação de sessão autenticada. O vetor CVSS oficial associado a esta CVE registra PR:L (privilégio baixo exigido), o que diverge do que a maioria das análises técnicas e do exploit público descrevem como um fluxo essencialmente não autenticado contra o endpoint que processa o cookie; vale considerar essa divergência ao avaliar exposição real do seu ambiente.

A exploração não depende de configuração exótica: qualquer instância DNN vulnerável, exposta à rede, com o cookie de personalização habilitado (comportamento padrão), é candidata. É por isso que a falha está no KEV da CISA com exigência de correção obrigatória — há exploração ativa documentada, e a combinação de PoC público + módulo Metasploit + template Nuclei torna a varredura em massa trivial. O resultado final da exploração é execução de código com os privilégios do processo web, o que normalmente significa controle total do site e, dependendo da configuração do servidor, possibilidade de movimento lateral.

A correção do fornecedor é atualizar para DNN 9.1.1 ou versão posterior. Não há, nas fontes disponíveis, um workaround de configuração documentado pelo fornecedor que substitua o patch — a página oficial de security center da DNN Software trata do caso, mas o conteúdo detalhado não foi verificado aqui, portanto não se deve assumir mitigação alternativa sem consultar o advisory diretamente.

Se a atualização imediata não for viável, controles compensatórios genéricos (WAF bloqueando cookies anormalmente longos ou com padrões de payload de deserialização .NET conhecidos, restrição de exposição do site à internet, monitoramento de processos w3wp.exe/IIS iniciando processos filhos inesperados) reduzem o risco mas não eliminam a vulnerabilidade subjacente. Como está no KEV, o prazo de correção definido pela CISA para agências federais dos EUA foi 2022-05-03 — um bom proxy de urgência para qualquer ambiente exposto, dado o histórico de exploração ativa.

Procure por requisições HTTP contendo cookies de personalização (nome associado ao DNNPersonalization) com tamanho ou estrutura anômala, especialmente conteúdo binário/base64 longo que não corresponde ao padrão leve esperado de um cookie de preferências. Processos w3wp.exe (ou equivalente do pool de aplicação do site DNN) que geram processos filho inesperados (cmd.exe, powershell.exe) logo após uma requisição HTTP são um forte indicador de exploração bem-sucedida.

Não há assinatura de rede universalmente confiável sem inspecionar o conteúdo do cookie especificamente, já que o payload de deserialização varia conforme a cadeia de gadgets usada pelo atacante — isso é uma limitação real de detecção baseada só em padrão de tráfego, e reforça que a mitigação primária é a atualização, não a detecção.