CVE-2023-25280

Injeção de comandos OS no endpoint /ping.ccp dos roteadores D-Link DIR-820, explorável via parâmetro ping_addr para obter shell root no dispositivo. Está no catálogo KEV da CISA com exploração confirmada em ambiente real, e o próprio produto é classificado pela CISA como end-of-life/end-of-service — não existe correção do fornecedor, só descontinuação.

A falha (CWE-78) está na função sub_49EDF8 dentro do binário /sbin/ncc2 do firmware. Quando o parâmetro ccp_act da requisição para /ping.ccp é definido como pingV4Msg, a função ccp_ping invoca sub_49EDF8, que lê o conteúdo do parâmetro ping_addr e o concatena diretamente em uma chamada de system() para montar o comando de ping — sem sanitização adequada do valor recebido.

Existe uma tentativa de filtro, implementada pela função hasInjectionString, mas ela é incompleta: não bloqueia caracteres como %0a (quebra de linha/novo comando) e $ (expansão de shell), permitindo que um atacante insira comandos arbitrários no meio do valor esperado como endereço de destino do ping.

O atacante controla integralmente o conteúdo de ping_addr enviado no corpo da requisição HTTP POST para /ping.ccp. Como o comando roda no contexto do processo do firmware (que tem privilégios de root na maioria desses dispositivos embarcados), a injeção resulta em execução de comando arbitrário como root, sem etapa intermediária de escalonamento.

O vetor é uma requisição POST para /ping.ccp com ccp_act=pingV4Msg e ping_addr contendo o payload injetado (por exemplo, usando %0a para quebrar o comando de ping original e encadear outro comando, como baixar um binário via wget ou abrir uma shell reversa/telnetd em porta arbitrária). A exploração documentada publicamente demonstra uso para baixar arquivos remotos e para abrir um telnetd escutando em uma porta alta, dando shell root persistente.

Há uma divergência relevante entre fontes sobre pré-requisito de autenticação: a descrição da CISA no KEV classifica a falha como explorável por atacante remoto não autenticado. Já a prova de conceito publicada inclui o cabeçalho Cookie: hasLogin=1 na requisição de exemplo, o que sugere que o pesquisador testou (ou o fluxo normal da interface web assume) uma sessão logada. Não há confirmação nas fontes de que o endpoint valida efetivamente esse cookie antes de processar a requisição — é possível que o valor seja ignorado ou trivialmente contornável, o que casaria com a classificação de 'não autenticado' da CISA, mas isso não foi verificado nas fontes disponíveis.

A exploração não exige nenhuma configuração não padrão do dispositivo: a interface de administração exposta e o endpoint /ping.ccp fazem parte do firmware padrão. O único requisito real é acesso de rede à interface administrativa do roteador (LAN ou, se exposta, WAN/internet). O código de exploração é público (GitHub) e há template Nuclei, o que reduz a barreira de automação em massa — coerente com o EPSS próximo de 0.98 e a presença no catálogo KEV.

Não há patch do fornecedor. A CISA classifica o DIR-820 como produto end-of-life/end-of-service e recomenda como ação oficial descontinuar o uso do equipamento — não existe versão de firmware corrigida a aplicar.

Como controle compensatório real, para quem não puder substituir o dispositivo imediatamente: isolar a interface de administração do roteador de qualquer acesso externo (desabilitar administração remota/WAN), restringir acesso à LAN de gestão por firewall/VLAN separada, e monitorar/bloquear requisições POST para /ping.ccp na borda da rede. Essas medidas reduzem a superfície mas não eliminam o risco caso um atacante já tenha pé na rede interna.

O que não funciona como mitigação: apenas exigir login na interface web não é garantia de proteção, dado que a evidência disponível não confirma que o endpoint valida a sessão corretamente antes de processar o parâmetro ping_addr. Regras de WAF genéricas que filtram apenas caracteres comuns de injeção (;, |, &) também são insuficientes, já que o próprio filtro nativo do firmware (hasInjectionString) já falha especificamente contra %0a e $ — qualquer controle compensatório precisa cobrir esses caracteres explicitamente.

Nos logs do próprio dispositivo ou em captura de tráfego voltado à interface de administração, o indicador é uma requisição POST para /ping.ccp com corpo contendo ccp_act=pingV4Msg e o parâmetro ping_addr trazendo sequências anômalas como %0a, $, ou comandos de shell (wget, telnetd, busybox) embutidos no valor que deveria ser apenas um endereço IP/host.

Como o dispositivo é tipicamente um roteador doméstico/SOHO sem logging centralizado robusto, não há garantia de rastro confiável após o fato — a ausência de log não indica ausência de exploração. Em ambientes com proxy ou gateway de gestão na frente do dispositivo, inspecionar tráfego para a porta de administração web em busca desse padrão é a única forma prática de detecção proativa.