Cisco Small Business RV320 and RV325 Routers Information Disclosure Vulnerability

Falha de controle de acesso na interface web de gerência dos roteadores Cisco RV320/RV325 permite que um atacante remoto, sem autenticação, baixe o arquivo de configuração completo do dispositivo ou um pacote de diagnóstico — ambos contendo hash de senha dos usuários administrativos e segredos de VPN/IPsec. Importa porque o hash exposto não precisa ser quebrado: ele funciona como credencial equivalente para logar na própria interface, e milhares desses roteadores ficaram expostos diretamente à Internet, o que tornou a falha alvo de scanning em massa e a colocou no catálogo KEV da CISA.

A interface de gerência é implementada por programas CGI no firmware. Dois endpoints concentram o problema: /cgi-bin/config.exp (exporta a configuração) e /cgi-bin/export_debug_msg.exp (exporta um pacote de diagnóstico). Ambos deveriam exigir sessão autenticada, mas checagens de controle de acesso incompletas nas URLs permitem chamá-los diretamente — falha classificável como CWE-284 (Improper Access Control) / CWE-200 (Exposure of Sensitive Information).

O ponto central da CVE-2019-1653, segundo a RedTeam Pentesting (que originalmente reportou uma vulnerabilidade irmã, corrigida por Cisco no firmware 1.4.2.19), é que a correção da Cisco foi incompleta: ela bloqueou apenas requisições HTTP GET e passou a rejeitar o User-Agent 'curl'. Uma requisição HTTP POST com um User-Agent diferente de 'curl' continua acessando os mesmos CGIs sem qualquer autenticação, tanto em 1.4.2.19 quanto em 1.4.2.20.

O conteúdo retornado por config.exp inclui seção [SYSTEM] com HOSTNAME, DOMAINNAME, USERNAME e PASSWD (hash MD5), além de parâmetros de VPN/IPsec. O endpoint export_debug_msg.exp entrega um blob cifrado com AES-128-CBC usando senha fixa embutida no firmware ('NKDebug12#$%'); ao decifrar com OpenSSL e extrair o tar resultante, o atacante obtém o mesmo nk_sysconfig com usuário e hash de senha, mais logs e demais arquivos de diagnóstico.

O atacante não controla nenhum parâmetro de exploração relevante além do corpo da requisição (submitbkconfig=0 ou submitdebugmsg=1) e do cabeçalho User-Agent — não há injeção de dados do usuário no processamento, é puramente ausência de autorização no CGI.

O vetor é uma requisição HTTP ou HTTPS direta à interface de gerência do roteador — não exige conta, sessão prévia ou qualquer interação do usuário legítimo. O único pré-requisito real é alcançar a porta de administração do dispositivo na rede; como muitos RV320/RV325 têm a gerência remota habilitada por padrão ou por má configuração, isso frequentemente significa expor a falha à Internet pública. O badpackets.net registrou mais de 9.000 dispositivos RV320/RV325 alcançáveis e vulneráveis nessa condição em 2019.

A exploração é trivial: uma requisição POST malformada específica para /cgi-bin/config.exp ou /cgi-bin/export_debug_msg.exp, com um User-Agent qualquer diferente de 'curl', devolve a configuração ou o pacote de diagnóstico. Não há necessidade de força bruta, escalonamento ou timing — é acesso direto a dado sensível. O resultado final é a posse do hash de senha administrativa (que serve diretamente para autenticação na própria interface, sem quebra) e de segredos de VPN/IPsec, o que abre caminho para login administrativo completo e pivotagem para a rede interna atrás do roteador.

A presença no catálogo KEV da CISA, junto com módulo Metasploit e template Nuclei públicos, confirma exploração ativa e ferramentas de weaponização amplamente disponíveis. Há também um terceiro advisory relacionado (RV320/RV325 Unauthenticated Remote Code Execution) que documenta uma injeção de comando separada nos mesmos dispositivos; na prática, campanhas observadas em 2019 combinaram a divulgação de credenciais desta CVE com essa falha de RCE para comprometer o dispositivo por completo, não apenas ler sua configuração.

O advisory oficial da Cisco (cisco-sa-20190123-rv-info) anunciou firmware corrigido para o vetor original via GET, mas a RedTeam Pentesting demonstrou em 27/03/2019 que o bypass via POST com User-Agent alterado continuava funcional nas versões 1.4.2.19 e 1.4.2.20, e listou 'Fixed Versions: none' até aquela data — ou seja, a correção da Cisco vigente na época era inadequada. Não temos confirmação, nas fontes disponíveis, de qual versão de firmware posterior corrige definitivamente o bypass por POST; antes de considerar o dispositivo corrigido, valide diretamente contra o advisory da Cisco a versão mais recente disponível e teste os dois endpoints.

O paliativo real, recomendado tanto pela Cisco quanto pela RedTeam, é impedir que clientes não confiáveis alcancem a interface web do dispositivo: desabilitar a gerência remota/WAN da interface administrativa e restringi-la a redes internas confiáveis via ACL/firewall. Esse controle tem custo baixo (perde-se apenas gerência remota) e neutraliza a exploração independente de a correção de firmware ser completa ou não.

O que não funciona: bloquear o User-Agent 'curl' — essa foi exatamente a mitigação insuficiente aplicada pela própria Cisco no firmware 1.4.2.19/1.4.2.20, e é trivialmente contornada trocando o cabeçalho User-Agent do cliente HTTP.

Nos logs de acesso HTTP/HTTPS do dispositivo (quando disponíveis), procure requisições POST para /cgi-bin/config.exp com corpo contendo 'submitbkconfig=0' ou para /cgi-bin/export_debug_msg.exp com 'submitdebugmsg=1', originadas de IPs externos e sem sessão autenticada prévia — especialmente com User-Agent atípico (o PoC público usa o valor 'kurl', uma variação deliberada para escapar do filtro de 'curl'). Como esses roteadores SOHO raramente exportam logs para um SIEM central, a ausência de sinal não indica ausência de exploração; monitoramento de rede perimetral (NetFlow/IDS observando tráfego HTTP para a porta de administração do dispositivo a partir da Internet) é o controle mais confiável quando o log local não existe.