CVE-2018-15811
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply updates per vendor instructions.
Resumo
CVE-2018-15811 afeta o DotNetNuke (DNN) Platform nas versões 9.2 a 9.2.1: o produto usa um algoritmo de criptografia fraco para proteger parâmetros de entrada recebidos do cliente (CWE-326, Inadequate Encryption Strength). A falha está no catálogo KEV da CISA — ou seja, houve exploração confirmada in the wild — e conta com módulo Metasploit, template Nuclei e PoC pública, o que a torna trivial de explorar em massa contra instâncias não atualizadas.
Detalhamento técnico
O NVD e a CISA classificam a causa raiz como CWE-326: o DNN usa um esquema criptográfico inadequado para proteger parâmetros que trafegam entre cliente e servidor (a descrição oficial não especifica qual algoritmo nem qual parâmetro exatamente, e essa informação não foi encontrada em advisory técnico detalhado do fornecedor nas fontes consultadas). O vetor CVSS oficial (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) é revelador: o impacto pontuado é só de confidencialidade — sem interação do usuário, sem autenticação, o atacante consegue ler ou decifrar dados que deveriam estar protegidos por essa criptografia fraca. Integridade e disponibilidade aparecem como 'None' na pontuação oficial.
Isso contrasta com o material de exploração público catalogado: o registro do PacketStorm associado a essa falha se chama 'DotNetNuke Cookie Deserialization Remote Code Execution', descrevendo uma cadeia em que a fraqueza criptográfica permite forjar ou adulterar um parâmetro/cookie protegido, e o conteúdo resultante — quando aceito pelo servidor — é desserializado sem validação suficiente, abrindo caminho para execução de código. Não há, nas fontes lidas, o detalhe de código-fonte (arquivo/método) que implementa a criptografia fraca nem qual classe/handler faz a desserialização; portanto, a mecânica exata do salto de 'ler dado cifrado' para 'RCE' não está documentada publicamente com granularidade suficiente para reprodução responsável aqui.
Em resumo: o que o fornecedor e o CVSS oficial documentam é uma falha de confidencialidade por criptografia fraca; o que ferramentas de exploração e pesquisadores de terceiros divulgam é uma cadeia mais severa, culminando em RCE. Quem avalia risco deve considerar o pior cenário demonstrado publicamente, não apenas o score oficial.
Como é explorada
O vetor é de rede, sem necessidade de autenticação e sem interação do usuário (AV:N/PR:N/UI:N), com complexidade de ataque baixa (AC:L) segundo o CVSS oficial — condições que tornam a falha atrativa para varredura automatizada. A existência de módulo Metasploit, template Nuclei e PoC pública reduz a barreira técnica praticamente a zero: qualquer atacante com acesso HTTP à instância vulnerável pode tentar a exploração sem etapas de reconhecimento sofisticadas.
O registro no catálogo KEV da CISA confirma exploração ativa observada no mundo real, com prazo de correção definido pela agência (adicionado em 2021-11-03, prazo 2022-05-03) — isso é evidência de exploração documentada, não hipótese. O resultado prático relatado varia conforme a fonte: o CVSS oficial aponta vazamento/decriptação de dados protegidos; os exploits catalogados (nome do arquivo PacketStorm) descrevem execução remota de código via desserialização do parâmetro/cookie forjado, o que é o cenário mais grave e o que deve orientar a priorização de correção.
Não há, nas fontes consultadas, indicação de pré-condição de configuração não padrão (módulo específico habilitado, permissão elevada etc.) — a descrição oficial trata isso como falha inerente às versões 9.2 a 9.2.1, expostas via HTTP padrão.
Versões
Como se proteger
A mitigação primária é atualizar o DNN Platform para uma versão além da faixa vulnerável (9.2–9.2.1). As fontes consultadas (release notes do GitHub e página de segurança da DNN Software) não trazem, no conteúdo lido, o número exato da versão que corrige especificamente esta CVE — confirme no advisory oficial do fornecedor (dnnsoftware.com/community/security/security-center) e no changelog de releases antes de considerar o ambiente corrigido; não assuma que qualquer patch release resolve sem checar a nota específica.
Como controle compensatório, na ausência de atualização imediata: restringir exposição da aplicação DNN à internet (colocar atrás de autenticação de rede ou VPN), monitorar/bloquear via WAF assinaturas associadas aos exploits públicos catalogados (Metasploit/Nuclei), e revisar logs de acesso por tentativas de manipulação de parâmetros/cookies incomuns. Nenhuma dessas medidas substitui o patch — são paliativos que reduzem superfície, não eliminam a falha de criptografia subjacente.
Não há indicação nas fontes de que desabilitar algum módulo específico do DNN mitigue a falha — trate qualquer afirmação nesse sentido como não verificada até confirmação no advisory oficial.
Como detectar
Sinal mais direto de tentativa de exploração é a presença, em logs de acesso web, de requisições contendo os padrões de payload usados pelo módulo Metasploit ou pelo template Nuclei associados a esta CVE, e erros de servidor (5xx) originados de falha na desserialização de parâmetros/cookies manipulados. As fontes consultadas não trazem um indicador de comprometimento (IOC) específico e documentado publicamente — nome de parâmetro, string de assinatura ou padrão de cookie — portanto, na ausência de acesso ao template Nuclei ou ao módulo Metasploit em uso no ambiente de detecção, não há sinal confiável e citável para diferenciar tráfego malicioso de tráfego legítimo com certeza.