CVE-2025-29635

Vulnerabilidade de command injection no endpoint /goform/set_prohibiting dos roteadores D-Link DIR-823X, versões de firmware 240126 e 240802, que permite execução arbitrária de comandos no sistema operacional do dispositivo. Está no catálogo KEV da CISA como exploração confirmada e associada a campanhas de botnet (variante Mirai) contra dispositivos D-Link expostos. O vetor CVSS (PR:H) indica que o atacante precisa de privilégios/autenticação no dispositivo — não é uma falha pré-autenticação trivial, apesar da gravidade do impacto.

A falha é classificada como CWE-77 (Neutralização Inadequada de Elementos Especiais usados em um Comando). O endpoint /goform/set_prohibiting, parte da interface de gerenciamento web do DIR-823X (função de bloqueio/restrição de acesso, dado o nome), recebe parâmetros via requisição POST que são concatenados sem sanitização em uma chamada de shell no binário CGI do firmware — padrão comum em roteadores D-Link, onde formulários web viram scripts que invocam binários do sistema (iptables, busybox, etc.) usando os valores enviados pelo cliente diretamente na string de comando.

O atacante controla o conteúdo de um ou mais campos do POST que são passados a essa chamada de sistema, permitindo injetar metacaracteres de shell (ponto e vírgula, pipe, backtick) para encadear comandos arbitrários com os privilégios do processo do servidor web, tipicamente root em firmware de roteador embarcado.

O vetor CVSS 3.1 (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H) documenta que a exploração exige rede (AV:N), é de baixa complexidade (AC:L), não precisa de interação do usuário (UI:N), mas exige privilégios altos (PR:H) — ou seja, o atacante precisa estar autenticado na interface de administração do dispositivo antes de enviar o POST malicioso. Isso reduz a superfície de ataque real a cenários onde o painel admin está exposto e credenciais foram obtidas (senha padrão, credencial fraca, ou vulnerabilidade de autenticação separada).

O exploit consiste em enviar uma requisição POST autenticada para /goform/set_prohibiting com um parâmetro manipulado contendo comandos de shell embutidos. Como o dispositivo é um roteador SOHO tipicamente exposto na porta de gerenciamento web (às vezes acessível pela WAN por má configuração), o principal pré-requisito prático é obter uma sessão autenticada — o que costuma ser trivial em campanhas automatizadas, já que muitos DIR-823X seguem com credenciais padrão ou senhas fracas nunca alteradas.

A presença no catálogo KEV da CISA confirma exploração ativa. O artigo referenciado da Akamai indica, pelo título, uma campanha de botnet Mirai utilizando essa CVE para comprometer dispositivos D-Link em massa — padrão típico dessas campanhas é escanear a internet por painéis expostos, tentar credenciais padrão/força bruta e, uma vez autenticado, disparar o POST malicioso para baixar e executar um loader Mirai, incorporando o dispositivo a uma botnet DDoS.

Existe um template Nuclei público para a falha, o que baixa a barreira de detecção/exploração automatizada por scanners de vulnerabilidade e por atacantes oportunistas. O resultado final da exploração é execução de comando com privilégios do processo do servidor de gerenciamento — geralmente equivalente a root no firmware, com controle total do roteador (interceptação de tráfego, pivô para a rede interna, uso em botnet).

As fontes disponíveis não trazem uma versão de firmware corrigida publicada pelo fornecedor. A CISA, no registro KEV, observa que o produto pode estar em fim de vida (EoL) ou fim de suporte (EoS) e recomenda, quando não houver mitigação disponível do fornecedor, descontinuar o uso do dispositivo. Há um advisory da D-Link referenciado (SAP10469) tratando desta CVE — consulte-o diretamente para confirmar se existe atualização de firmware para o modelo e versão específicos antes de assumir que o problema está resolvido.

Como controle compensatório, restrinja o acesso à interface de administração do dispositivo (desative gerenciamento remoto/WAN, permita acesso apenas de IPs de confiança na LAN, segmente o roteador numa VLAN de gerência isolada) e troque credenciais padrão por senhas fortes e únicas — como a exploração exige autenticação (PR:H), eliminar credenciais fracas e acesso remoto ao painel neutraliza a maior parte do risco prático mesmo sem patch.

Não existe mitigação via firewall de aplicação (WAF) nesse cenário, já que o dispositivo é o próprio alvo e não está atrás de um WAF típico de aplicação web corporativa; um IPS/firewall de borda que bloqueie POSTs para /goform/set_prohibiting provenientes da WAN é o controle de rede mais realista para quem não pode substituir o equipamento imediatamente. Trocar senha sem restringir a exposição da interface de gerenciamento não é suficiente isoladamente, pois não elimina o vetor de injeção — apenas dificulta a etapa de autenticação prévia.

Monitorar logs do servidor web/gerenciamento do dispositivo (ou tráfego de rede voltado à interface de administração) por requisições POST para /goform/set_prohibiting contendo metacaracteres de shell (;, |, `, $(), &&) nos parâmetros do formulário — esse é o indicador mais direto de tentativa de exploração. Como há template Nuclei público, também é comum observar varreduras automatizadas testando esse endpoint em lote antes de qualquer tentativa de autenticação bem-sucedida.

Em ambientes onde o dispositivo já foi comprometido, procurar por sinais pós-exploração típicos de botnets Mirai: processos ou binários desconhecidos rodando com nomes genéricos, conexões de saída para IPs/portas atípicas (C2), uso anômalo de CPU/banda e reinicializações não programadas. Não há assinatura de exploração universalmente confiável sem acesso ao binário CGI vulnerável para confirmar o parâmetro exato injetado — a ausência de detalhe público completo sobre o payload limita a certeza de qualquer regra de detecção baseada só na descrição oficial.