CVE-2017-5521

Falha de exposição de informação sensível (CWE-200) em roteadores NETGEAR: ao cancelar a tela de login do painel administrativo, o dispositivo redireciona para uma página que expõe um token de recuperação de senha, e esse token entregue a /passwordrecovered.cgi retorna usuário e senha de admin em texto claro. Importa porque não exige nenhuma credencial prévia — só acesso à interface web, seja via LAN/WLAN, seja remotamente se a gestão remota estiver habilitada — e está confirmada como explorada ativamente (KEV da CISA).

O mecanismo de recuperação de senha desses roteadores gera um token de sessão associado ao processo de autenticação. Quando o usuário abre o painel de administração e cancela o prompt de autenticação HTTP (em vez de fornecer credenciais), o firmware assume erroneamente que se trata de um fluxo legítimo de 'esqueci minha senha' e redireciona para um endpoint (variando por modelo, algo como .../unauth.cgi?id=TOKEN) que expõe esse token na resposta. Esse token não é vinculado a nenhuma prova de identidade adicional além de ser previsível/capturável na própria resposta HTTP.

Com o token em mãos, uma requisição (GET ou, em alguns modelos, POST) para /passwordrecovered.cgi?id=TOKEN retorna diretamente o par usuário/senha do administrador do roteador, sem qualquer verificação de sessão anterior. A falha existe porque o fluxo de recuperação foi implementado assumindo que só quem 'esqueceu a senha' legitimamente chegaria a essa página — mas nada impede um atacante de simplesmente cancelar o login para acionar o mesmo caminho.

A única barreira efetiva é a funcionalidade de 'perguntas de segurança' (security questions) da recuperação de senha: se o usuário configurou previamente essa opção, o fluxo de token é substituído por perguntas que o atacante não pode responder, e isso persiste mesmo que a opção seja desativada depois — o roteador continua exigindo as perguntas. Ou seja, a mitigação funcional é um recurso do próprio produto, não um patch que remove a superfície.

O CVSS 8.1 com AC:H reflete que a exploração depende de descobrir o endpoint/token correto por modelo (não é uniforme entre firmwares) e, em alguns casos, do método HTTP exigido — mas PR:N e UI:N confirmam que não é preciso nenhuma credencial ou interação da vítima além do acesso à interface web.

Vetor: requisições HTTP diretas ao servidor de gestão web do roteador. Pré-requisito real é acesso à interface administrativa — via rede local/Wi-Fi na configuração padrão, ou pela internet caso o recurso de 'remote management' esteja habilitado (desligado por padrão pela NETGEAR, mas frequentemente ativado por usuários avançados ou ISPs). Não exige autenticação nem qualquer interação da vítima.

Na prática, a exploração é de duas etapas: uma requisição para acionar/capturar o token de recuperação (cancelando o diálogo de autenticação) e uma segunda requisição para /passwordrecovered.cgi com esse token, que devolve as credenciais de admin em texto claro. Existe PoC pública (script Python divulgado pela Trustwave SpiderLabs e replicado no Exploit-DB), módulo Metasploit e template Nuclei, o que reduz a complexidade prática a quase zero para quem já sabe o endpoint do modelo-alvo.

A falha está no catálogo KEV da CISA como exploração confirmada em campo — historicamente associada a varreduras massivas de roteadores domésticos expostos à internet (remote management ligado), usadas para tomada de controle do dispositivo, redirecionamento de DNS/tráfego, ou como pé inicial em botnets IoT. Se a recuperação de senha com perguntas de segurança estiver configurada, a exploração falha nesse fluxo.

Atualizar o firmware para a versão corrigida específica de cada modelo — a NETGEAR publicou firmwares por modelo (R8500, R8300, R7000, R6400, R7300DST, R7100LG, R6300v2, WNDR3400v3, WNR3500Lv2, R6250, R6700, R6900, R8000, e outros incluídos posteriormente como R7900, WNDR4500v2, R6200v2, WNDR3400v2, D6220, D6400, C6300). As versões exatas corrigidas variam por modelo e devem ser conferidas na página de firmware de cada produto no site da NETGEAR; o Exploit-DB lista, por exemplo, R7000 corrigido a partir de V1.0.7.2_1.1.93, R6300v2 a partir de V1.0.4.6_10.0.76, R8500 a partir de V1.0.2.64_1.0.62, D6400 a partir de V1.0.0.52_1.0.52 — mas essa lista não é exaustiva nem oficial da NETGEAR, apenas o que os pesquisadores documentaram.

Para modelos sem firmware corrigido disponível (a NETGEAR lista vários, incluindo R6200, R6300, VEGN2610, AC1450, WNR1000v3, WNDR3700v3, WNDR4000, WNDR4500, D6300, D6300B, DGN2200Bv4, DGN2200v4), o próprio fornecedor recomenda como paliativo: habilitar manualmente o recurso de recuperação de senha com perguntas de segurança E garantir que a gestão remota esteja desabilitada. A NETGEAR é explícita: a exposição persiste se qualquer uma das duas condições não for cumprida. Para o modelo a cabo C6300, o firmware corrigido (2.01.18) depende do provedor de internet, não de atualização direta pelo usuário.

Não funciona como mitigação apenas desabilitar a recuperação de senha depois de já tê-la configurado com perguntas de segurança — o comportamento seguro (exigir as perguntas) persiste mesmo com a opção 'desligada' na interface, então isso não é um risco adicional, mas também reforçar que simplesmente reiniciar ou resetar sem reconfigurar as perguntas de segurança reabre a exposição. Dispositivos em fim de vida sem patch disponível e sem possibilidade de aplicar o workaround devem ser removidos de operação, conforme orientação da própria entrada no catálogo KEV da CISA.

Nos logs do servidor web do roteador (quando disponíveis) ou em captura de tráfego de rede, o padrão de exploração é uma sequência rápida de duas requisições HTTP: uma ao endpoint de recuperação (variando por modelo, contendo algo como unauth.cgi?id=) seguida imediatamente por uma requisição a /passwordrecovered.cgi?id= — sem que tenha havido uma tentativa de login bem-sucedida antes. A maioria desses dispositivos SOHO tem logging local mínimo ou inexistente, então a detecção prática costuma depender de monitoramento de rede (IDS/IPS ou captura de tráfego) que sinalize acesso a esses caminhos específicos vindos de IPs externos (indicando gestão remota exposta) ou de hosts não administrativos na LAN.