ZyXEL NAS products running firmware version 5.21 and earlier are vulnerable to pre-authentication command injection in weblogin.cgi

Injeção de comandos OS pré-autenticação no script weblogin.cgi de dispositivos NAS da ZyXEL, explorável remotamente sem credenciais via requisição HTTP GET ou POST manipulada. É crítica de fato: CVSS 9.8 aqui não é exagero de marketing, porque a cadeia de exploração leva a execução como root através de um utilitário setuid presente no firmware, mesmo o servidor web não rodando como root.

A falha é CWE-78 (OS Command Injection). O executável CGI weblogin.cgi, responsável pelo processo de autenticação na interface web dos dispositivos NAS ZyXEL, recebe um parâmetro username e passa esse valor para uma chamada de sistema sem sanitização adequada de caracteres especiais de shell. Um atacante que controla o conteúdo do campo username pode injetar metacaracteres (separadores de comando) e fazer o servidor web executar comandos arbitrários no sistema operacional subjacente.

O servidor web nos dispositivos afetados não roda com privilégios de root, o que teoricamente limitaria o impacto. Porém a ZyXEL inclui nesses firmwares um utilitário com bit setuid que pode ser invocado para executar qualquer comando com privilégios de root. Isso transforma uma injeção de comando com privilégios de processo web em execução arbitrária de código como root — a escalada de privilégio não depende de uma segunda falha, é uma característica do próprio firmware.

O vetor de ataque não exige nenhuma etapa de autenticação prévia: o parâmetro vulnerável é processado antes de qualquer verificação de login válida, daí 'pré-autenticação' no nome.

Pré-requisito de rede: o atacante precisa alcançar a porta HTTP/HTTPS (80/tcp ou 443/tcp) da interface web do dispositivo. Não é necessária conta válida, não há restrição de configuração não padrão conhecida — a vulnerabilidade está no fluxo padrão de login. Não há complexidade de exploração relevante: é uma injeção de comando clássica via campo de formulário, e existe PoC pública, além de template Nuclei, o que reduz a barreira técnica a praticamente zero.

O CERT/CC destaca um detalhe importante: a exposição não precisa ser direta à internet. Como a exploração ocorre via requisição HTTP simples (GET ou POST), técnicas de CSRF/DNS rebinding a partir de um navegador em uma rede interna podem acionar a requisição maliciosa contra um dispositivo NAS que só é acessível na LAN — ou seja, simplesmente visitar uma página web maliciosa pode comprometer um NAS ZyXEL alcançável pelo cliente, mesmo sem exposição direta à internet.

Há exploração confirmada em campo: a vulnerabilidade está no catálogo KEV da CISA (adicionada em 2022-03-25, prazo de correção 2022-04-15) e a divulgação original em 2020 partiu de Alex Holden (Hold Security), que identificou exploit já circulando antes da correção do fornecedor — ou seja, foi tratada como 0-day ativo desde o início.

A ZyXEL disponibilizou atualizações de firmware para NAS326, NAS520, NAS540 e NAS542 — aplicar a atualização é a mitigação primária para esses modelos. Modelos NSA210, NSA220, NSA220+, NSA221 (e outros da linha NSA mais antiga, como NSA310/310S/320/320S/325/325v2, também citados pelo CERT/CC) já estavam fora de suporte no momento da correção e podem não ter recebido patch — para esses, não há atualização de firmware disponível como opção.

Como paliativo real quando o patch não é aplicável ou não existe: bloquear acesso às portas 80/tcp e 443/tcp da interface web do dispositivo via firewall, e garantir que nenhuma máquina com acesso a essa interface tenha também acesso à internet — isso neutraliza tanto o ataque direto quanto o vetor indireto via navegador (CSRF/DNS rebinding). Isolar o NAS em uma VLAN sem rota para a internet é o controle compensatório mais efetivo quando a atualização não é possível.

Cuidado ao atualizar: o próprio processo de atualização de firmware da ZyXEL usa um canal inseguro (FTP) para buscar as atualizações, e os arquivos são verificados apenas por checksum, não por assinatura criptográfica. Um atacante com controle de DNS ou roteamento pode, em tese, entregar firmware malicioso durante esse processo — então a atualização deve ser feita em rede confiável. Isolar a interface web sem restringir a origem do tráfego que chega até ela (ex.: apenas mudar a porta padrão) não é mitigação eficaz, já que o exploit funciona por requisição HTTP direta ao endpoint vulnerável.

Como o vetor é uma requisição HTTP simples ao weblogin.cgi com o parâmetro username contendo metacaracteres de shell (separadores de comando), o sinal a procurar em logs do servidor web é a presença de caracteres não usuais (como aspas, pipes, ponto-e-vírgula, backticks ou sequências de escape) no campo username de requisições GET/POST para esse endpoint. A existência de template Nuclei público para esta CVE também indica que scanners automatizados de massa podem gerar tráfego de teste característico contra /weblogin.cgi em varreduras da internet.

Como o vetor indireto (via navegador/CSRF) não deixa rastro no log do dispositivo-alvo que aponte para a origem real do ataque, e como não há indicador único e confiável documentado pelas fontes consultadas para diferenciar exploração bem-sucedida de tentativa falha, a ausência de log anômalo não deve ser interpretada como evidência de que o dispositivo não foi comprometido.