CVE-2021-25298

O Nagios XI 5.7.5 permite injeção de comandos no sistema operacional através do assistente de configuração de nuvem/VM (cloud-vm), explorável por um usuário autenticado — mesmo com privilégios não administrativos — via uma única requisição HTTP. A falha está no catálogo KEV da CISA com exploração confirmada em campo, tem módulo Metasploit e template Nuclei públicos, o que a torna trivial de operacionalizar assim que há acesso à interface web.

A vulnerabilidade (CWE-78, OS Command Injection) está em /usr/local/nagiosxi/html/includes/configwizards/cloud-vm/cloud-vm.inc.php, no estágio CONFIGWIZARD_MODE_GETSTAGE2HTML do assistente de monitoramento de nuvem (usado, por exemplo, no wizard 'digitalocean'). O parâmetro ip_address é lido diretamente da requisição via grab_array_var($inargs, 'ip_address', ''), passa por nagiosccm_replace_user_macros() — que não faz sanitização contra metacaracteres de shell — e é concatenado sem escaping na chamada exec('ping -W 2 -c 1 ' . $rp_address, ...).

Como o valor é interpolado diretamente na string de comando executada via exec() do PHP, qualquer caractere de controle de shell (ponto e vírgula, pipe, backtick, etc.) inserido em ip_address é interpretado pelo shell do sistema, permitindo encadear comandos arbitrários após o ping legítimo.

O mesmo padrão de código — variável de entrada do usuário indo direto para exec() sem sanitização — aparece em falhas irmãs identificadas na mesma pesquisa (CVE-2021-25296 no assistente windowswmi, via plugin_output_len, e CVE-2021-25297 no assistente switch, também via ip_address), o que sugere um problema sistêmico nos config wizards do Nagios XI daquela época, não um bug isolado.

O vetor é uma única requisição HTTP autenticada para monitoringwizard.php, com wizard=digitalocean (ou outro wizard da família cloud-vm), definindo update=1, nextstep=4 e um token nsp válido de sessão, seguido do payload malicioso no parâmetro ip_address (por exemplo, encadeando um comando via ponto e vírgula). O pré-requisito real e crítico é autenticação: a PoC pública documentada demonstra que funciona tanto com usuário administrador quanto com usuário não administrativo — ou seja, qualquer conta válida no Nagios XI, mesmo de baixo privilégio, basta para comprometer o servidor por completo.

A exploração não exige interação do usuário-vítima (UI:N no CVSS) nem condição de rede fora do comum além de acesso à interface web do Nagios XI. A ausência de qualquer requisito de privilégio elevado (PR:L, e mesmo assim atingível por contas de baixo nível) e a disponibilidade de módulo Metasploit e template Nuclei tornam a varredura e exploração em massa triviais, o que explica a inclusão no catálogo KEV da CISA com exploração confirmada em ambientes reais.

O resultado final é execução de comando arbitrário no contexto do processo web do Nagios XI, tipicamente levando a controle total do servidor (o painel do Nagios XI roda com privilégios suficientes para administrar hosts monitorados, credenciais de infraestrutura e, em muitos ambientes, tem visibilidade privilegiada de rede interna).

A Nagios Enterprises não publicou, nas fontes consultadas, um advisory oficial vinculando explicitamente uma versão de correção a esta CVE. A versão testada e confirmada como vulnerável é a xi-5.7.5; a linha de releases subsequente (5.8.0 em diante, e todas as versões posteriores listadas pelo fornecedor) foi lançada depois da divulgação pública das falhas dos config wizards, então a recomendação prática é atualizar para a versão mais recente disponível do Nagios XI e não permanecer em 5.7.5 ou anterior.

Como paliativo caso a atualização não seja imediata: restringir o acesso à interface web do Nagios XI (porta HTTP/HTTPS do painel) a redes de administração confiáveis, via firewall ou controle de acesso de rede, reduz a superfície — mas não elimina o risco de qualquer conta comprometida ou insider de baixo privilégio explorar a falha. Revisar e restringir a criação de contas não administrativas no Nagios XI também limita quem pode alcançar o endpoint vulnerável, já que a exploração exige apenas autenticação, não privilégio de admin.

MFA na aplicação Nagios XI não mitiga a falha em si (o problema é sanitização de input, não controle de acesso), mas reduz a chance de uma conta de baixo privilégio ser comprometida e usada como trampolim. WAF genérico à frente da aplicação pode bloquear alguns padrões de payload de shell no parâmetro ip_address, mas não é solução — é workaround imperfeito diante de um leque grande de metacaracteres possíveis.

Em logs de acesso web, procurar requisições para monitoringwizard.php com parâmetros wizard referentes a assistentes de cloud/VM (ex.: digitalocean) combinados com nextstep=4 e um campo ip_address contendo metacaracteres de shell (ponto e vírgula, pipe, backtick, cifrão-parênteses) em vez de um endereço IP válido. Em nível de sistema, comandos ping gerados pelo processo web do Nagios XI seguidos por processos filhos anômalos (netcat, shells reversos, downloads) no mesmo timestamp são indício forte de exploração bem-sucedida.

Não há assinatura de rede confiável isolada, já que a requisição é uma chamada HTTP autenticada legítima na superfície — a distinção depende do conteúdo do parâmetro ip_address, o que reforça a necessidade de inspecionar corpo de requisição, não apenas cabeçalhos ou padrões de URL.