CVE-2019-19356

Roteador doméstico Netis WF2419 permite execução de comandos como root através da ferramenta de diagnóstico "tracert" no painel administrativo web. É uma RCE autenticada — exige acesso à interface de gerência e credenciais válidas — mas está no catálogo KEV da CISA com exploração confirmada, e o PoC público reduz a complexidade prática a quase zero para quem satisfaz os pré-requisitos.

A falha é uma injeção de comando de sistema operacional (CWE-78) no menu "System Tools" > "Diagnostic Tools" da interface web do WF2419. Essa página expõe duas ferramentas que rodam comandos UNIX no firmware: "ping" e "tracert", recebendo como parâmetro um IP ou nome de domínio digitado pelo usuário e devolvendo a saída do comando na própria página.

No campo do "ping" existe um filtro que bloqueia a injeção de operadores de shell. No campo do "tracert", esse filtro não existe ou é insuficiente: pesquisadores confirmaram que o operador "|" (pipe) passa sem sanitização e é interpretado pelo shell do dispositivo, permitindo encadear qualquer comando adicional ao comando tracert original.

O processo que processa a requisição roda como root no firmware embarcado, então qualquer comando injetado herda esse nível de privilégio — não há sandboxing, drop de privilégios ou desvinculação do usuário web do usuário do sistema. O atacante controla integralmente a string que compõe o "alvo" do tracert, que é o vetor de injeção.

O pré-requisito central, que a manchete de "RCE crítica" tende a esconder, é autenticação: o atacante precisa estar logado na interface web de administração do roteador. Isso normalmente significa acesso à rede local (LAN) ou, se a gerência remota estiver habilitada, acesso via WAN. Os pesquisadores que documentaram a falha apontam que essa autenticação pode ser obtida via senha padrão/fraca (comum em equipamentos domésticos nunca reconfigurados) ou via ataque man-in-the-middle contra a sessão de gerência — não é uma falha pré-autenticação.

Com sessão autenticada, o atacante preenche o campo de destino do "tracert" com um endereço válido seguido do operador "|" e do comando desejado; o firmware executa a cadeia completa como root e devolve a saída na página. Existe um exploit público em Python (repositório shadowgatt/CVE-2019-19356) que automatiza essa injeção, e o PacketStorm hospeda um PoC equivalente, o que baixa bastante a barreira técnica para quem já tem acesso à interface.

O resultado final é execução arbitrária de código com privilégios de root no roteador — controle total do dispositivo, possibilidade de pivotar para a rede interna, interceptar/alterar tráfego, ou incorporar o equipamento a uma botnet. A presença no catálogo KEV da CISA confirma exploração ativa em campo, coerente com o padrão histórico de botnets IoT que varrem a internet por painéis de gerência expostos com credenciais padrão.

Nenhuma das fontes consultadas (advisory do fornecedor, NVD referenciado pela CISA, PacketStorm, análise da Digital.Security) indica uma versão de firmware corrigida ou um patch oficial disponível para o WF2419. A entrada do KEV apenas instrui genericamente "aplicar atualizações conforme instruções do fornecedor", sem apontar a versão-alvo — não afirme aqui que existe correção sem confirmar diretamente no site do fabricante, e não assuma que uma versão superior à V2.2.36123 resolve o problema sem validação.

Controles compensatórios reais: desabilitar completamente a gerência remota (WAN) do roteador, restringir acesso à interface administrativa apenas à LAN confiável, trocar a senha padrão por uma senha forte e única, e segmentar a rede para que o roteador não seja alcançável por qualquer dispositivo que se conecte à LAN. Se a ferramenta de diagnóstico "tracert" não for necessária no dia a dia, isolar ou desabilitar esse recurso específico (se o firmware permitir granularidade) reduz a superfície, mas não é uma opção documentada oficialmente.

Trocar senha padrão sozinho não elimina o risco se a gerência remota estiver exposta à internet — reduz a chance de exploração por credencial fraca, mas não corrige a falta de sanitização do input. Dado o histórico de dispositivos IoT sem suporte de firmware ativo, a alternativa mais efetiva de longo prazo, se não houver patch confirmado, é substituir o equipamento por um com suporte de segurança ativo.

Em logs da interface web/administrativa do roteador, procurar requisições ao endpoint de diagnóstico ("tracert"/"ping") contendo o caractere "|" ou outros metacaracteres de shell (";", "&&", "`") no campo de IP/domínio — isso é o indicador mais direto de tentativa de exploração. Em nível de rede, monitorar acessos autenticados à porta de gerência do dispositivo (HTTP/HTTPS administrativo) originados de IPs fora da faixa de administradores esperados, especialmente se a gerência remota estiver habilitada.

Não há assinatura de exploração amplamente publicada nem CVE companion de detecção; como o ataque ocorre dentro de uma sessão autenticada legítima da interface web, tráfego de exploração se mistura facilmente com uso administrativo normal, o que torna a detecção confiável limitada sem inspeção de conteúdo dos parâmetros da requisição.