CVE-2018-18325
Corrige ahora. Ella está bajo explotación confirmada por CISA y tiene exploit funcional público.
Apply updates per vendor instructions.
Resumen
Falha em versões 9.2 a 9.2.2 do DotNetNuke (DNN) onde a criptografia usada para proteger parâmetros de entrada (cookies de personalização) é fraca e previsível, permitindo que um atacante remoto e não autenticado forje esses valores. É a correção incompleta de uma falha anterior (CVE-2018-15811), e está no catálogo KEV da CISA por exploração confirmada em ambiente real — apesar de o CVSS oficial (7.5, impacto só em confidencialidade) subestimar o alcance prático da falha.
Detalle técnico
A vulnerabilidade é classificada como CWE-326 (Inadequate Encryption Strength). O DNN protege parâmetros de entrada — incluindo dados armazenados no mecanismo de 'Personalization' baseado em cookie — usando um algoritmo de criptografia fraco. A CVE-2018-15811 tentou corrigir esse problema, mas a correção foi incompleta: o algoritmo continuou fraco o suficiente para permitir que um atacante recupere ou forje o conteúdo criptografado sem conhecer segredos específicos da instalação.
Cómo se explota
O vetor é rede pura, sem autenticação e sem interação do usuário (AV:N/AC:L/PR:N/UI:N), o que bate com o padrão de exploração reportado: o atacante manipula diretamente o cookie/parâmetro protegido enviado ao servidor. Pesquisadores e a comunidade de exploração (PoC pública no PacketStorm, módulo Metasploit e template Nuclei) documentaram que essa fraqueza criptográfica é usada como peça de uma cadeia mais ampla — 'DotNetNuke Cookie Deserialization RCE' — na qual o atacante, aproveitando a previsibilidade da criptografia, consegue produzir um valor de cookie válido contendo um objeto serializado malicioso; ao ser desserializado pelo servidor, isso resulta em execução remota de código. Essa cadeia completa vai além do que a pontuação CVSS oficial da NVD reflete (que marca apenas impacto de confidencialidade), então a divergência entre a nota NVD e o risco real demonstrado por pesquisadores é o ponto mais importante desta CVE.
A presença no catálogo KEV da CISA confirma exploração ativa. Não há indicação nas fontes revisadas de pré-condições de configuração não padrão — o recurso afetado (parâmetros protegidos por criptografia/personalização) parece estar habilitado por padrão nas versões afetadas, o que amplia a superfície de risco para qualquer instalação DNN 9.2–9.2.2 exposta à internet.
Versiones
Cómo protegerse
O fornecedor orienta atualizar conforme instruções oficiais (DNN Security Center). A faixa vulnerável documentada é 9.2 a 9.2.2; nas fontes revisadas não foi possível confirmar com certeza qual foi a primeira versão que corrige definitivamente o algoritmo de criptografia — recomenda-se conferir diretamente o advisory do DNN Security Center e o changelog de releases do projeto no GitHub antes de assumir uma versão específica como corrigida. Dado que essa CVE já é a segunda tentativa de correção de uma mesma classe de problema (após a CVE-2018-15811 incompleta), vale confirmar na release notes se o fix atual substitui o algoritmo de criptografia por um mecanismo moderno com autenticação de integridade (não apenas troca de chave).
Como paliativo quando a atualização não é imediata: restringir exposição do painel de administração e de rotas que processam personalização à rede interna/VPN, e monitorar/bloquear via WAF cookies ou parâmetros anormalmente grandes ou com padrões de codificação (base64/hex) fora do esperado para o nome de cookie de personalização do DNN. Isso reduz a superfície mas não corrige a causa raiz — a criptografia fraca continua presente até a atualização de versão.
Cómo detectar
Não há assinatura pública amplamente documentada e confiável nas fontes revisadas. Como indício, buscar em logs de acesso web valores de cookie de personalização anormalmente grandes, malformados ou com blobs codificados fora do padrão esperado, seguidos de exceções de desserialização nos logs de eventos da aplicação/IIS, ou execução inesperada de processos filhos do worker process (w3wp.exe) em servidores DNN. A existência de módulo Metasploit e template Nuclei sugere que scanners automatizados podem gerar requisições de teste características, mas nenhuma assinatura específica foi confirmada nas fontes consultadas.