Out of Cycle Security Advisory: Junos OS: Security vulnerability in J-Web and web based (HTTP/HTTPS) services
Priorize a correção. Ela está sob exploração confirmada pelo CISA.
Apply updates per vendor instructions.
Resumo
Falha de path traversal / local file inclusion (CWE-22/CWE-73) no serviço HTTP/HTTPS que dá suporte a J-Web, Web Authentication, Dynamic-VPN, Firewall Authentication Pass-Through com Web-Redirect e ZTP em Junos OS. Um atacante não autenticado com acesso de rede à interface pode ler arquivos com permissão 'world readable', injetar conteúdo no httpd.log e, se houver sessão J-Web ativa de um administrador, sequestrar essa sessão para obter acesso administrativo completo ao equipamento. Importa porque está no catálogo KEV da CISA (exploração confirmada) e porque a superfície de ataque — uma interface de gerência web exposta — é comum em ambientes que não isolam management de dados.
Detalhamento técnico
A raiz do problema está no tratamento de caminhos de arquivo pelo daemon HTTP/HTTPS que atende J-Web e os demais serviços web-based do Junos OS. Requisições podem conter sequências de traversal que escapam do diretório esperado, permitindo leitura de qualquer arquivo com permissão 'world readable' no sistema — em versões 19.3R1 e superiores isso inclui o arquivo de configuração do dispositivo, o que eleva bastante o impacto de confidencialidade (CVSS 5.9, AC:H porque a leitura da config específica exige mais trabalho do atacante).
Há um segundo vetor: o mesmo mecanismo de traversal permite injetar conteúdo controlado pelo atacante dentro do httpd.log. Como o serviço HTTP roda com o usuário de baixo privilégio 'nobody', a Juniper classifica o impacto de uma eventual execução de comando via esse log poisoning como limitado (CVSS 5.3) — mas a CISA, ao catalogar a falha no KEV, descreve o cenário de forma mais direta como permitindo execução remota de código, o que evidencia divergência entre a leitura do fornecedor (impacto contido pelo usuário nobody) e a leitura de pesquisadores/CISA (RCE).
O cenário de maior severidade (CVSS 8.8, AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) não depende de escalar privilégios do processo httpd: a falha permite obter tokens de sessão J-Web. Se um administrador estiver logado no J-Web no momento do ataque, o atacante herda esse nível de acesso — na prática, controle administrativo total do dispositivo de rede. O UI:R no vetor indica que esse cenário crítico exige alguma interação (típicamente a vítima logada acessando um recurso manipulado), não é exploração puramente remota e silenciosa em todos os casos.
Como é explorada
O vetor é de rede (AV:N), sem autenticação prévia (PR:N), contra a interface HTTP/HTTPS que atende J-Web e os serviços correlatos. O pré-requisito real que a manchete '8.8 unauthenticated' esconde é duplo: primeiro, J-Web (ou um dos outros serviços web-based listados) precisa estar habilitado no dispositivo — não é o padrão de fábrica em todas as instalações, mas é comum em ambientes que administram o equipamento via interface gráfica; segundo, para o cenário mais grave de sequestro de sessão, é necessário que um usuário — idealmente um administrador — esteja com sessão J-Web ativa no momento da exploração.
Para o cenário de leitura de arquivos 'world readable' e injeção no log, a barreira é mais baixa: basta acesso de rede à porta do serviço web. A complexidade varia conforme o objetivo — AC:L para o path traversal genérico e log poisoning, AC:H para conseguir ler especificamente o arquivo de configuração em versões 19.3R1+.
A vulnerabilidade está no catálogo KEV da CISA (adicionada em 25/03/2022, prazo de correção 15/04/2022), confirmando exploração ativa observada in-the-wild, e a entrada da CISA descreve o resultado final como execução remota de código — um passo além do que a Juniper detalha em seu próprio texto. Isso sugere que atacantes reais encadearam o path traversal com o log poisoning (ou com o roubo de sessão J-Web) para obter algo equivalente a RCE, mesmo que o processo comprometido inicialmente rode como 'nobody'.
Versões
Como se proteger
A mitigação definitiva é atualizar para as versões de Junos OS corrigidas pela Juniper, detalhadas por família de release no advisory JSA11021 — o conteúdo consultado não trouxe a matriz completa de versões afetadas/corrigidas por linha (12.3, 15.1, 17.x, 18.x, 19.x etc.), então a lista exata precisa ser conferida diretamente no JSA11021 para a versão específica em uso antes de declarar o ambiente corrigido.
Se a atualização não for imediata, o paliativo real é desabilitar J-Web, Web Authentication, Dynamic-VPN, Firewall Authentication Pass-Through com Web-Redirect e ZTP quando não forem estritamente necessários, e restringir o acesso à interface de gerência HTTP/HTTPS por ACL a uma rede de management isolada, nunca exposta à internet. Esse controle tem custo operacional (perda de conveniência de gerência via GUI a partir de qualquer rede) mas neutraliza o vetor de rede que a falha exige.
Não funciona como mitigação equivalente à correção: apenas trocar a senha de administradores ou monitorar logs sem isolar o acesso à interface — o path traversal e o log poisoning independem de credenciais, e a única defesa de rede eficaz enquanto o patch não é aplicado é impedir que a interface vulnerável seja alcançável por quem não precisa dela.
Como detectar
Em httpd.log e nos logs do serviço web do Junos OS, procurar por sequências de traversal de diretório (padrões como '../' ou suas variantes codificadas, ex. '%2e%2e%2f') em requisições HTTP/HTTPS dirigidas a J-Web, Web Authentication, DVPN, Firewall Authentication Pass-Through ou ZTP, especialmente vindas de endereços fora da rede de gerência esperada. Como parte do próprio ataque envolve injetar conteúdo no httpd.log, entradas de log com formatação anômala ou aparentemente corrompida são, por si só, indício de tentativa de exploração — e não apenas ruído.
Não há assinatura única e confiável para todos os cenários: a variante de roubo de token de sessão J-Web pode não deixar rastro distinto de uma requisição legítima se o atacante já obteve o token, então a ausência de logs suspeitos não garante que o ambiente não foi comprometido — reforça a importância de isolar a interface na rede em vez de depender só de detecção.