D-Link DNS-320L/DNS-325/DNS-327L/DNS-340L HTTP GET Request nas_sharing.cgi command injection

Falha de command injection no CGI nas_sharing.cgi de NAS D-Link legados (DNS-320L, DNS-325, DNS-327L, DNS-340L), explorável remotamente sem autenticação real graças a uma falha de lógica companheira (CVE-2024-3272) que permite logar como usuário de sistema 'messagebus' com senha vazia. É crítica na prática, não só no papel: está no catálogo KEV da CISA com exploração confirmada em massa por botnets, e o fornecedor não vai corrigir porque os produtos são EOL — a única mitigação real é desligar o dispositivo.

O endpoint /cgi-bin/nas_sharing.cgi aceita um parâmetro 'system' cujo conteúdo (decodificado de base64) é passado para uma chamada de shell no backend, sem sanitização — CWE-77, command injection clássica. O atacante controla integralmente o comando executado, limitado apenas pelo que cabe em base64 dentro do parâmetro.

O acesso a essa função exige autenticação (user/passwd) no fluxo normal do CGI, mas a CVE-2024-3272, tratada como companheira, expõe uma falha de lógica: o dispositivo valida corretamente que o usuário 'messagebus' existe e que a senha fornecida corresponde ao que está cadastrado, mas nunca verifica se esse usuário deveria conseguir autenticar via essa interface. 'messagebus' é uma conta de sistema Linux padrão (como avahi, syslog, nobody), criada sem senha e sem propósito de login interativo — não é um backdoor com credencial fixa plantada pelo fornecedor, e sim uma omissão de controle de acesso sobre uma conta de serviço. Como a senha vazia é 'correta' para essa conta, a checagem de autenticação passa.

Com essa passagem, o atacante monta uma requisição HTTP GET usando user=messagebus, passwd= vazio, e um parâmetro cmd que seleciona um código de operação (relatado como cmd=15) que roteia para a função vulnerável, entregando o comando a executar codificado em base64 no parâmetro system. O resultado é execução de comando arbitrário no contexto do processo do CGI, tipicamente com privilégios suficientes para instalar malware persistente no NAS.

O vetor é HTTP simples: uma única requisição GET não autenticada de fato (usa a conta de sistema sem senha), sem necessidade de acesso prévio, credenciais reais, ou configuração não padrão — qualquer DNS-320L/325/327L/340L exposto à internet com a interface de gerenciamento acessível é alvo direto. A complexidade de exploração é baixa: não há CSRF token, não há verificação adicional, e o PoC público (netsecfish) demonstra o payload completo.

Exploração ativa está confirmada e documentada pela GreyNoise: sensores capturaram tentativas em massa entregando scripts shell genéricos de download-e-execução que buscam binários de malware para múltiplas arquiteturas de CPU (padrão típico de operadores de botnet tipo Mirai), com uma amostra (skid.x86) recuperada e submetida ao VirusTotal. A CISA adicionou a CVE ao KEV em 11/04/2024 com prazo de mitigação de 02/05/2024, mas como o fornecedor não vai corrigir, a 'ação' recomendada é aposentar o equipamento, não aplicar patch.

O número de dispositivos vulneráveis expostos foi inicialmente estimado em ~92.000 pelo pesquisador que publicou o PoC; análise posterior da Censys revisou essa contagem para algo em torno de 5.500 dispositivos com a interface exposta publicamente — a diferença importa para avaliar exposição real na internet, mas não reduz a gravidade para quem ainda opera o equipamento.

Não existe patch e não vai existir: o fornecedor confirmou que todos os modelos afetados (e toda a linha de NAS legados listada no SAP10383) atingiram End of Service Life e não recebem mais atualizações de firmware ou segurança. A recomendação oficial e a única mitigação efetiva é retirar o equipamento de operação e substituí-lo.

Como controle compensatório temporário, se o dispositivo precisar continuar operando por necessidade operacional: remover completamente a exposição da interface de gerenciamento e do CGI à internet (sem NAT/port-forward, sem UPnP automático), restringir acesso à rede local via firewall/segmentação, e desabilitar qualquer funcionalidade de acesso remoto embutida no NAS. Isso reduz a superfície de ataque mas não corrige a falha de lógica de autenticação nem a injeção — o dispositivo continua vulnerável a qualquer atacante com acesso à rede onde ele está.

Trocar a senha do dispositivo ou desabilitar contas de usuário administrativas não mitiga nada aqui, porque a falha explora uma conta de sistema interna (messagebus) que não é gerenciada pela interface de usuários do produto — esse é o mito a descartar. Atualizar para 'a última versão disponível' também não resolve, já que não há versão corrigida para nenhum dos modelos afetados.

Em logs de acesso do NAS ou de proxy/WAF na frente dele, procurar requisições GET a /cgi-bin/nas_sharing.cgi contendo user=messagebus, passwd= vazio, e um parâmetro system com conteúdo codificado em base64 — esse padrão de parâmetros é a assinatura do exploit público. Em nível de rede/EDR no perímetro, sinais de infecção pós-exploração incluem o dispositivo iniciando conexões de saída para baixar scripts shell que tentam executar binários para múltiplas arquiteturas de CPU sequencialmente (padrão comum de botnets tipo Mirai) e tráfego HTTP de saída para servidores de distribuição de malware.

Como o mecanismo de autenticação abusado é uma conta de sistema legítima com senha vazia por design, não há um log de 'falha de autenticação' que sirva de alerta — a requisição aparece como logon válido do ponto de vista do CGI, o que torna a assinatura no payload (system= com base64, cmd=15) o indicador mais confiável disponível.