CVE-2016-6277

Roteadores domésticos Netgear (linha R6000/R7000/R8000 e alguns modelos D) executam comandos de shell arbitrários como root quando o path info passado ao script CGI em cgi-bin/ contém metacaracteres de shell, sem qualquer autenticação. É crítica de verdade: não exige login, não exige configuração não padrão, e há exploração ativa confirmada (está no catálogo KEV da CISA) com EPSS próximo de 1.0.

A falha é um command injection clássico (CWE-77): o servidor web embutido nos roteadores passa o path info da URL requisitada em /cgi-bin/ diretamente para uma chamada de sistema, sem sanitizar ponto-e-vírgula e outros metacaracteres de shell. Uma requisição para http:///cgi-bin/;COMANDO faz o COMANDO ser executado pelo interpretador de shell do firmware, com privilégios de root, porque o processo do servidor web já roda como root nesses dispositivos.

A vulnerabilidade também foi catalogada com CWE-306 (Missing Authentication for Critical Function), porque a página CGI vulnerável é acessível sem login — não existe verificação de sessão antes de processar o path info. O CERT/CC e a CISA também associam CWE-352 (CSRF) ao caso: como a exploração é um simples GET, uma página maliciosa pode disparar a requisição a partir do navegador de uma vítima que esteja na mesma rede do roteador vulnerável, sem que a vítima perceba.

O atacante controla integralmente o comando executado — não há lista de permissões nem escaping do delimitador `;`. Isso abre para qualquer ação pós-exploração: leitura/gravação de configuração, abertura de backdoor (telnetd), pivotagem para a rede interna, ou incorporação do roteador em botnet.

Existem dois vetores práticos. O primeiro é direto: um atacante com acesso à rede local do roteador (ou à interface WAN, se a administração remota estiver habilitada) envia um GET para /cgi-bin/;COMANDO e o comando roda como root imediatamente — sem autenticação, sem interação do usuário. É o vetor documentado nos PoCs públicos (exploit-db 40889 e 41598), que demonstram abrir um telnetd em porta arbitrária com `;telnetd$IFS-p$IFS'45'`.

O segundo vetor é CSRF: como a exploração é uma requisição HTTP simples para um IP local (geralmente o gateway padrão), uma página web maliciosa visitada pela vítima pode incluir uma tag ou script que dispara a requisição contra o roteador da própria rede da vítima, sem que ela saiba que possui um Netgear vulnerável. Isso elimina a necessidade de o atacante estar na mesma LAN.

O EPSS acima de 0,99 e a presença no catálogo KEV da CISA (adicionada em março de 2022) confirmam exploração em massa no mundo real — historicamente, esse tipo de falha em roteadores Netgear foi alvo de scanners automatizados e variantes de botnets estilo Mirai que buscam dispositivos expostos à internet com administração remota habilitada. Existe módulo Metasploit e template Nuclei públicos, o que baixa a barreira técnica para praticamente zero.

A correção real é atualizar para o firmware de produção (não a versão Beta) mais recente de cada modelo, disponibilizado pela Netgear na página de firmware específica do produto. A CVE original cita como corrigidas as versões Beta R6250 1.0.4.6.Beta, R6400 1.0.1.18.Beta, R6700 1.0.1.14.Beta, R7000 1.0.7.6.Beta, R7100LG 1.0.0.28.Beta, R7300DST 1.0.0.46.Beta, R7900 1.0.1.8.Beta e R8000 1.0.3.26.Beta — mas a própria Netgear alerta que essas eram correções provisórias e recomenda fortemente instalar o firmware de produção posterior, cujos números de versão exatos não constam no texto do advisory consultado. Para R6900, D6220 e D6400 a Netgear confirma que estão afetados e que há firmware de produção disponível, sem detalhar a versão vulnerável inicial. O D7000, apesar de citado na descrição original da CVE, foi posteriormente excluído da lista pela própria Netgear após novos testes.

Se a atualização não for possível de imediato, o paliativo real é desabilitar a administração remota (WAN) do roteador — ela normalmente já vem desligada por padrão, e se foi habilitada deve ser desativada, pois é o que permite exploração direta pela internet. Isso não elimina o vetor de CSRF via LAN: um cliente da rede local que visite uma página maliciosa ainda pode disparar a exploração contra o próprio roteador. Segmentação de rede e desconfiar de dispositivos IoT antigos sem suporte ajudam, mas não corrigem a falha.

O CERT/CC documentou um 'workaround' de usar a própria vulnerabilidade para matar o processo do servidor web (`;killall$IFS'httpd'`) até o próximo reboot — isso não é mitigação de verdade, é uma automutilação temporária que desliga a interface de administração web e não persiste após reinicialização. Não deve ser tratado como solução.

Em logs de servidor web do roteador ou em captura de tráfego de rede, procure por requisições HTTP para caminhos que comecem com /cgi-bin/; seguido diretamente de texto sem barra adicional — o ponto-e-vírgula logo após 'cgi-bin/' é a assinatura do ataque, especialmente combinado com sequências como `$IFS`, backticks, pipes ou nomes de binários como telnetd, busybox, wget, tftp. Módulos Metasploit e templates Nuclei públicos geram esse mesmo padrão de requisição, então correspondência de assinatura nesse formato em WAF/IDS de borda tem alta confiabilidade.

Não há um indicador de comprometimento pós-exploração único, porque o comando executado é arbitrário; monitore o próprio roteador (se exportar logs) por processos ou serviços inesperados iniciados após a requisição suspeita (telnetd, shells reversas, alterações de DNS/iptables) e por tráfego de saída anômalo do dispositivo, comum quando ele é recrutado em botnet.