CVE-2021-40655

Falha de disclosure de informação no roteador D-Link DIR-605 (revisão de hardware B2, firmware 2.01MT): o endpoint /getcfg.php responde a uma requisição POST forjada devolvendo dados de configuração do dispositivo, incluindo usuário e senha de administração, sem exigir autenticação válida. É um roteador doméstico legado, mas está no catálogo KEV da CISA por exploração confirmada em campo, o que eleva sua relevância mesmo com CVSS 'apenas' alto (7.5) e sem impacto em integridade/disponibilidade.

A vulnerabilidade é classificada como CWE-863 (Incorrect Authorization). O painel de gerência web do DIR-605 expõe /getcfg.php, um endpoint historicamente usado em diversos firmwares D-Link da mesma linhagem de código para exportar blocos de configuração do dispositivo. No firmware 2.01MT dessa revisão B2, o controle de acesso a esse endpoint não valida corretamente se a requisição partiu de uma sessão administrativa autenticada — uma requisição POST construída manualmente, sem cookie de sessão válido, é aceita e processada da mesma forma que uma chamada legítima do painel.

O atacante controla o conteúdo da requisição POST enviada ao endpoint. A resposta do dispositivo inclui, entre outros dados de configuração, as credenciais de administração armazenadas (usuário e senha), em texto plano ou facilmente recuperável. Não há evidência nas fontes analisadas de que a falha permita escrita de configuração ou execução de comandos — o impacto documentado é estritamente leitura/exposição de dados (C:H, I:N, A:N no vetor CVSS confirma isso).

O fornecedor não publicou boletim técnico detalhando a causa raiz exata da falta de validação; a descrição pública, tanto do NVD quanto da CISA, se limita a afirmar que a requisição forjada ao /getcfg.php expõe as credenciais, sem especificar parâmetros ou estrutura interna do endpoint.

O vetor é de rede (AV:N), sem necessidade de autenticação prévia (PR:N) e sem interação do usuário (UI:N), o que explica o CVSS 7.5 mesmo sendo 'apenas' disclosure. O único pré-requisito real é acesso à interface de gerência web do dispositivo — na prática, a rede local do roteador ou, em configurações onde a administração remota está habilitada, a internet. Não há indicação nas fontes de que a exploração exija configuração não padrão além dessa exposição da interface administrativa.

A complexidade técnica é baixa: a exploração consiste em enviar uma requisição POST forjada ao endpoint, sem necessidade de bypass de sessão sofisticado, engenharia social ou encadeamento com outras falhas. Existe template Nuclei público e um repositório de PoC referenciado (github.com/Ilovewomen/D-LINK-DIR-605), o que reduz ainda mais a barreira de entrada para exploração em massa via scanners automatizados.

A CISA incluiu a CVE no catálogo KEV confirmando exploração ativa observada, embora não classifique o uso como associado a campanhas de ransomware conhecidas. O resultado final da exploração é a obtenção das credenciais administrativas do roteador, que podem ser reutilizadas para login completo no painel — abrindo caminho para reconfiguração do dispositivo, pivotamento na rede local ou uso do roteador como parte de botnet, embora esses passos subsequentes não fazerem parte da CVE em si.

Não há patch do fornecedor. O DIR-605 (incluindo a revisão B2 com firmware 2.01MT) é produto legado e, segundo a própria nota da CISA no catálogo KEV, todas as revisões de hardware já atingiram fim de vida (EOL) ou fim de suporte (EOS). A orientação oficial registrada pela CISA é retirar e substituir o equipamento — não existe atualização de firmware corrigindo a falha a ser aplicada.

Como controle compensatório para quem ainda opera o dispositivo por necessidade: desabilitar completamente a administração remota (acesso à interface de gerência via WAN), restringir o acesso à interface web apenas à LAN confiável, e segmentar o roteador em VLAN isolada de outros ativos críticos. Trocar a senha padrão não resolve a falha, já que o problema é a ausência de controle de autorização no endpoint, não uma senha fraca — mesmo com senha forte, a requisição forjada ainda expõe as credenciais armazenadas.

Não há indicação nas fontes de mitigação via WAF ou regra de borda específica publicada pelo fornecedor. Bloquear ou filtrar POST para /getcfg.php em um proxy/firewall na frente do dispositivo é um paliativo técnico razoável enquanto a substituição do hardware não ocorre, mas depende de existir esse ponto de inspeção na topologia — não é algo nativo do roteador.

O sinal mais direto a procurar é requisição HTTP POST para o caminho /getcfg.php no roteador, especialmente originada de IPs fora da rede local ou sem correlação com uma sessão administrativa previamente autenticada no painel. Como o dispositivo tem log limitado (típico de CPE doméstico) e não há relato de assinatura de exploração publicada em detalhe pelo fornecedor, a detecção confiável depende de captura de tráfego de rede (ex. na borda) ou de logs do próprio roteador, quando disponíveis — muitos ambientes não terão nenhuma dessas fontes, o que torna a detecção retroativa pouco confiável nesse cenário específico.