CVE-2021-25296

Falha de injeção de comandos do sistema operacional (CWE-78) no wizard de configuração do Windows WMI do Nagios XI 5.7.5, explorável por qualquer usuário autenticado — incluindo contas sem privilégio de administrador. O CVSS de 8.8 reflete corretamente o impacto (RCE total no servidor), mas o vetor real exige sessão autenticada válida, não é pré-autenticação como muita gente assume ao ver 'crítica'.

O bug está em /usr/local/nagiosxi/html/includes/configwizards/windowswmi/windowswmi.inc.php, parte do fluxo de criação de 'wizards' de monitoramento que o Nagios XI usa para gerar comandos de checagem via WMI em hosts Windows. O parâmetro plugin_output_len, recebido da requisição HTTP que grava o wizard (monitoringwizard.php?wizard=windowswmi), é concatenado diretamente nas strings $disk_wmi_command, $service_wmi_command e $process_wmi_command sem qualquer sanitização ou escaping de metacaracteres de shell.

Essas três strings são passadas para exec() do PHP, que invoca um shell do sistema. Como o valor do atacante entra na string do comando antes de ser executado, qualquer ponto e vírgula, pipe ou operador de shell dentro de plugin_output_len é interpretado pelo interpretador de comandos, não tratado como dado. Não há whitelist de caracteres, escaping via escapeshellarg/escapeshellcmd, nem validação de que o valor é numérico (apesar de o campo semanticamente representar um tamanho de saída, um inteiro).

O mesmo padrão de falha (concatenação de input em exec() dentro de outros wizards de configuração) foi encontrado pelo mesmo pesquisador em outros arquivos do produto (switch.inc.php, cloud-vm.inc.php), tratados sob CVEs distintas (CVE-2021-25297, CVE-2021-25298). Isso indica um problema sistêmico de sanitização nos config wizards da versão, não um caso isolado."

A exploração exige um HTTP request autenticado para monitoringwizard.php com update=1, nextstep=3, wizard=windowswmi e um token nsp válido (token de sessão/CSRF do wizard, obtido durante o fluxo normal de uso da interface). O PoC público demonstra que a conta usada não precisa ter privilégio de administrador — qualquer usuário com acesso de login à interface web do Nagios XI consegue disparar a injeção, o que casa com PR:L no vetor CVSS.

O atacante controla o parâmetro plugin_output_len; ao inserir um valor como um número seguido de ponto e vírgula e um comando shell, o comando é concatenado à linha executada por exec() e roda com os privilégios do processo web do Nagios XI (tipicamente o usuário do Apache/nginx que serve a aplicação). Não há necessidade de interação de terceiros nem de condição de rede especial além de acesso HTTP(S) ao painel — daí AV:N/AC:L/UI:N no vetor.

A CVE está no catálogo KEV da CISA, confirmando exploração ativa observada, e existe módulo público no Metasploit e template Nuclei, o que baixa bastante a barreira técnica: hoje a exploração é praticamente automatizável contra qualquer instância exposta com credenciais válidas (inclusive de baixo privilégio, phishadas ou reaproveitadas de outro vazamento). O resultado final é execução arbitrária de comando no host do Nagios XI, abrindo caminho para shell reverso e pivotagem — Nagios XI tipicamente tem visibilidade e credenciais de monitoramento sobre outros ativos da rede, tornando o servidor um alvo de alto valor pós-exploração.

O fornecedor lista xi-5.8.0 como a versão publicada imediatamente após a 5.7.5 (lançada por volta de 15/01/2021, um mês após a 5.7.5); não há advisory oficial da Nagios nas fontes consultadas que declare explicitamente 'a CVE-2021-25296 é corrigida na versão X', então trate a atualização para a série 5.8.x ou posterior como a linha de base recomendada e confirme no changelog oficial da Nagios antes de considerar o ambiente corrigido — não assuma a correção apenas pelo número da versão.

Se a atualização imediata não for possível, o controle compensatório real é restringir quem tem conta na interface do Nagios XI e revisar contas com login válido, já que a falha não exige privilégio de admin — qualquer usuário autenticado é vetor suficiente. Reduzir superfície: desabilitar ou remover o acesso ao wizard windowswmi se ele não for usado, e colocar a interface administrativa do Nagios XI atrás de uma rede restrita (VPN/allowlist), fora de exposição direta à internet.

O que NÃO funciona como mitigação: exigir apenas MFA no login não neutraliza o problema, porque o ataque ocorre pós-autenticação com qualquer conta válida — MFA reduz o risco de credencial roubada, mas não corrige a falta de sanitização. Da mesma forma, confiar em 'só admins têm acesso' é falso pressuposto: o próprio PoC documenta exploração com conta não-administrativa.

Nos logs de acesso do servidor web (Apache/nginx) que serve o Nagios XI, procure requisições para /nagiosxi/config/monitoringwizard.php com wizard=windowswmi e parâmetro plugin_output_len contendo metacaracteres de shell (;, |, &, `, $(), >, <) em vez de um valor numérico puro — isso é anômalo e forte indicador de tentativa de exploração, dado que o PoC público usa exatamente esse padrão.

No nível de processo, monitore o usuário do servidor web (tipicamente apache/nginx/nagios) para execução de shells reversos, netcat, bash -i ou downloads via curl/wget disparados sem relação com os plugins WMI legítimos — o exec() vulnerável roda comandos que fogem do padrão esperado dos binários de checagem WMI do Nagios. Se os logs de aplicação do Nagios XI não estiverem retidos ou o acesso HTTPS não for decriptado em algum ponto de inspeção, não há sinal de rede confiável para detectar a exploração — a única visibilidade robusta vem de log de acesso à aplicação e monitoramento de processos no host."