CVE-2017-9822

CVE-2017-9822

O DNN (também conhecido como DotNetNuke) antes da versão 9.1.1 tem capacidade de execução remota de código por meio de cookies, também conhecido como "2017-08 (Importante) Possível execução remota de código em sites DNN".

Informações principais

Produto afetado: DotNetNuke (DNN Platform) – um CMS/portal .NET popular.
Data de divulgação: Julho de 2017.
Gravidade: Crítica (CVSS ~9.8).
Tipo de vulnerabilidade: XML External Entity (XXE) / Desserialização insegura → Execução remota de código (RCE).
Impacto: antes da versão 9.1.1, é possível executar código remotamente por meio do cookie

alt

O que é DotNetNuke?
O DotNetNuke é um CMS (sistema de gerenciamento de conteúdo) web gratuito e de código aberto escrito em C# e baseado na plataforma .NET. O DotNetNuke é muito popular e amplamente usado na Internet porque você pode implantar uma versão web do DNN em poucos minutos, sem precisar de muito conhecimento técnico. Outra função importante do DotNetNuke é a capacidade de criar ou importar módulos personalizados de terceiros, criados em VB.NET ou C#
É possível instalar o DNN em uma stack composta por Windows Server, IIS, ASP.NET e SQL Server para Windows. O DNN também suporta o registro de novos usuários com verificação por e-mail, mas você precisa configurar um servidor SMTP válido para que esse recurso de segurança funcione. Principais recursos do DNN
• Arquitetura modular: o DNN permite fácil expansão com a instalação de módulos (módulos de funcionalidade) desenvolvidos pela comunidade. Os administradores podem carregar novos módulos pela interface de administração (envio de pacotes .zip) ou extraí-los diretamente em uma pasta no servidor.
• Administração de usuários: o sistema oferece recursos de segurança e permissões detalhadas (roles/permissions) para portais e módulos. Contas de usuário, funções e permissões são gerenciadas de forma centralizada no DNN.
• Gerenciamento de conteúdo: suporte a edição WYSIWYG, gerenciamento de artigos, imagens, documentos… Há um sistema de workflow/publicação (publicação de artigos por fluxo de aprovação) e versionamento de conteúdo. O conteúdo é armazenado em um banco de dados (SQL Server) compartilhado.
• API e integração extensível: o DNN fornece uma API .NET para os desenvolvedores criarem módulos personalizados (WebForms, MVC, Razor) e integrarem serviços externos. Há uma vasta gama de bibliotecas de terceiros disponíveis (temas de interface, módulos de comércio eletrônico, fóruns etc.) para expandir as funcionalidades.
• Interface e temas: o sistema de skins (temas) separa conteúdo – interface, permitindo um design web flexível. Os sites criados com o DNN podem mudar de aparência trocando os skins.
• Mecanismo de instalação de módulos: os módulos do DNN são empacotados em arquivos ZIP e podem ser instalados pela interface de administração ou por extração manual. O DNN suporta tanto módulos compilados (.NET DLL) quanto módulos Razor dinâmicos; todo módulo pode ter o acesso concedido ou revogado por meio das configurações de permissão em cada página .

Configuração do ambiente

Sistemas operacionais: Windows 10
.NET Framework: 4.5.1+
Servidor web: Microsoft IIS 10
Servidor de banco de dados: Microsoft® SQL Server® 2019 Express, SQL Server Management Studio
Versão do DotNetNuke 9.1.0
Você pode usar os seguintes Google dorks para encontrar versões do DotNetNuke implantadas e disponíveis na Internet e verificá-las com base no site:
inurl:dnn.js
inurl:dnn.modalpopup.js
inurl:dnn.servicesframework.js
inurl:dnn.xml.js
inurl:dnncore.js
inurl:/Portals/0/
inurl:/DesktopModules/
inurl:/DNNCorp/
inurl:/DotNetNuke
inurl:/tabid//Default.aspx
inurl:/tabid//language/*/Default.aspx
intext:"by DNN Corp "
Você pode seguir este artigo para montar o ambiente

Configuração para depuração

Ajuste as propriedades do assembly para as propriedades "depuráveis"; isso é essencial porque, em tempo de execução, algumas otimizações são aplicadas e acabam atrapalhando a depuração: alguns breakpoints podem não ser atingidos ou algumas variáveis podem não existir.
Carregue a DotNetNuke.dll no dnSpy (32 bits), depois selecione Edit Assembly Attributes (C#)

alt

Altere a linha de
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
Para
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]

alt

Depois, selecione Compile e salve este módulo de volta no local original.
Em seguida, execute o dnSpy com privilégios de administrador e selecione Debug -> Attach to Process

alt

Selecione o processo w3wp.exe

alt

O motivo de precisarmos anexar esse processo para depurar é que os aplicativos web no IIS normalmente usam worker processes. Eles são responsáveis por processar as requisições web enviadas ao servidor web IIS para cada application pool; pode haver vários worker processes em uma máquina, e todos têm o mesmo nome: w3wp.exe. Uma observação importante: às vezes não há nenhum processo w3wp em execução; o IIS só inicia os worker processes quando recebe a primeira requisição web.

alt