Autor: Adriano Cansian

Com a Colaboração de: Giuliano Medalha (por Wztech) e Gabriele Zancheta Scavazini, Guilherme Bofo, Guilherme Romanholo Bofo, Matheus Bordino Moriel e Kim Morgan (por UNESP ACME! Cybersecurity Research)

1. Resumo

Testes internos, realizados em laboratório, em roteadores Juniper rodando Junos OS 24 e Junos OS 23, em 27/06/2025 8h10m BRT, identificaram que conexões SSH originadas a partir da porta TCP 22 (com destino à porta 22 do roteador) permitem o bypass das regras de firewall configuradas na interface loopback, mesmo com termos explícitos de descarte dos pacotes. A vulnerabilidade permite que atacantes ignorem restrições de acesso, comprometendo a proteção do plano de controle. Até o momento, não há evidências de exploração ativa, mas a gravidade exige ação imediata.

Essa descoberta foi informada ao Juniper Security Incident Response Team em 27/06/2025, sendo solicitado registro de CVE, havendo recebida a seguinte resposta, até o momento:

I can confirm now for you that engineering leadership is aware of the reported issue and have requested their staff to begin investigating it.  Once I have an update from them, I will contact you with next steps (security incident ID # SIR-2025-0520).

2. Detalhamento da descoberta

Este relato, baseado em uma discussão interna entre analistas de rede e de segurança, e pode conter imprecisões. Utilize-a por sua conta e risco.

Para explicar o problema, apresentamos uma análise resumida sobre o funcionamento dos planos de controle e forwarding em equipamentos Juniper, com foco na aplicação e limitações de filtros de firewall na interface loopback. Também abordamos a descoberta de uma vulnerabilidade crítica no SSH, que permite o bypass das regras de segurança configuradas, e destaca as ações necessárias para verificar a correção do problema em versões mais recentes do sistema Junos.

2.1. Contexto da arquitetura Juniper

• Equipamentos Juniper operando com o sistema Junos OS apresentam arquitetura modular, com separação entre o plano de forwarding (data plane) e o plano de controle (control plane). A interface lógica loopback é utilizada como ponto de interconexão entre esses dois planos, sendo normalmente protegida por filtros de firewall (firewall filters) no modo input, com o objetivo de restringir o acesso aos daemons do plano de controle — como o SSH, SNMP, RPD, entre outros.
• Esses filtros seguem uma lógica sequencial de aplicação das regras, sendo comum configurar regras específicas para permitir ou bloquear tráfego com base em IP de origem, protocolos e portas de origem/destino.

2.2. Limitações do Firewall Filter na Interface de Loopback

• É recomendado aplicar um firewall filter na interface loopback, no modo input, para proteger o roteador contra acessos indesejados.
• O filtro atua sobre todo o tráfego que tenta abrir conexão com os daemons internos do roteador, funcionando como uma camada de proteção para o equipamento e seus acessos.
• O firewall filter da Juniper opera de forma sequencial, lendo e aplicando termos (regras) na ordem em que são configurados.
• Uma regra típica pode permitir apenas determinados IPs de origem na porta 22 para SSH.

2.3. Descoberta da Vulnerabilidade no SSH

Durante testes de rotina, foi identificado o seguinte comportamento:

• Conexões SSH estabelecidas com porta de origem aleatória (acima de 1024) são corretamente analisadas pelos filtros da interface loopback, sendo bloqueadas ou permitidas conforme esperado.
• Entretanto, quando a conexão SSH é iniciada com a porta de origem TCP 22, os pacotes não são inspecionados ou bloqueados pelos filtros, mesmo quando há regras explícitas de descarte (discard) para esse tipo de tráfego.
• Esse comportamento resulta na evasão completa das políticas de segurança configuradas no plano de controle, permitindo o acesso direto ao serviço SSH do roteador a partir de origens não autorizadas.
• Assim, se a conexão SSH for originada a partir da porta 22 (supondo que a porta de destino do SSH no Juniper também seja 22), todos os bloqueios configurados no firewall filter são ignorados, mesmo com regras explícitas de descarte.
• A falha é considerada grave, pois permite o bypass das regras de segurança, comprometendo a proteção do equipamento.

Estimativa de CVSS v3.1

Base Score: 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L)

• AV:N – Vetor de ataque pela rede
• AC:L – Baixa complexidade de ataque
• PR:N – Sem privilégios necessários
• UI:N – Sem interação do usuário
• S:U – Escopo não alterado
• C:H / I:H / A:L – Impacto alto em confidencialidade e integridade, baixo em disponibilidade

3. Mitigação recomendada

Incluir explicitamente protocol tcp ao usar source-port, para evitar ambiguidade ou configurações inválidas.

Manter cada termo autônomo, sem combinar source-port com outras condições conflitantes (como port) no mesmo termo.

Aplicar o filtro na interface lo0 no modo input, conforme a prática padrão para proteger o plano de controle.

Testar a configuração em ambiente controlado, garantindo que o filtro está funcionando conforme esperado em versões relevantes do Junos OS.

Segundo recomendado pela Juniper, até que haja uma confirmação oficial da fabricante e o lançamento de um patch corretivo, recomenda-se aplicar as seguintes medidas preventivas para mitigar o risco de evasão das regras de firewall na interface loopback:

3.1. Ajuste no filtro de proteção ao plano de controle (PROTECT-RE)

O filtro de firewall aplicado à interface lógica lo0, no modo input, deve ser atualizado para bloquear explicitamente pacotes TCP com porta de origem 22, antes de qualquer regra que permita acesso SSH.

Importante: esse termo deve ser posicionado antes de qualquer outro termo que aceite conexões SSH.

Exemplo de configuração estilo CLI (Junos OS):

# Novo termo — bloqueia pacotes com source-port 22
set firewall family inet filter PROTECT-RE term BLOQUEIA-SRC-22 from protocol tcp
set firewall family inet filter PROTECT-RE term BLOQUEIA-SRC-22 from source-port 22
set firewall family inet filter PROTECT-RE term BLOQUEIA-SRC-22 then syslog
set firewall family inet filter PROTECT-RE term BLOQUEIA-SRC-22 then discard

# Termo já existente — acesso SSH permitido para IPs autorizados
set firewall family inet filter PROTECT-RE term ACEITA-SSH from source-address 198.51.100.0/24
# 198.51.100.0/24 : IP reservado para exemplo (RFC 5737)
set firewall family inet filter PROTECT-RE term ACEITA-SSH from protocol tcp
set firewall family inet filter PROTECT-RE term ACEITA-SSH from port ssh
set firewall family inet filter PROTECT-RE term ACEITA-SSH then count accept-ssh
set firewall family inet filter PROTECT-RE term ACEITA-SSH then accept

# Aplicação do filtro na interface de loopback
set interfaces lo0 unit 0 family inet filter input PROTECT-RE

Estrutura resultante (sintaxe hierárquica)

term BLOQUEIA-SRC-22 {
    from {
        protocol tcp;
        source-port 22;
    }
    then {
        syslog;
        discard;
    }
}

term ACEITA-SSH {
    from {
        source-address 198.51.100.0/24;  
# 198.51.100.0/24 : IP reservado para exemplo (RFC 5737)
        protocol tcp;
        port ssh;
    }
    then {
        count accept-ssh;
        accept;
    }
}

ATENÇÃO: A condição source-port só é válida quando utilizada juntamente com protocol tcp, conforme documentado oficialmente pela Juniper.

3.2. Mitigação alternativa para o serviço ssh

Alterar a porta padrão do serviço SSH para uma porta não convencional:

set system services ssh port 2222

3.3. Restrições adicionais

Restringir o acesso à interface de gerenciamento por meio de ACLs específicas, VPNs, ou túneis criptografados.

Monitorar logs de acesso SSH e realizar testes contínuos em laboratório para verificar se o comportamento persiste em versões atualizadas do Junos OS.

4. Verificação de informações

Com base nas informações disponíveis até 04 de julho de 2025, não há registros públicos de uma vulnerabilidade específica no Junos OS que permita o bypass de filtros de firewall na interface loopback para conexões SSH com porta de origem 22.

A vulnerabilidade mais próxima relatada é a CVE-2023-48795 (Terrapin SSH Attack), que afeta o protocolo SSH em geral e foi corrigida em versões recentes do Junos OS.

Recomendamos verificar o site de segurança da Juniper (www.juniper.net/security) ou contatar a Juniper SIRT (sirt@juniper.net) para confirmar se essa vulnerabilidade foi reportada e se há um CVE associado. Além disso, são recomendados mais testes em laboratório com as versões mais recentes do Junos (e.g., 24.4R1, lançada em abril de 2025) para confirmar se o problema persiste.

Considerações finais

A mitigação continua válida e reforçada com base na documentação oficial. A instrução está segura para uso em ambientes que implementam filtros Junos OS 23 ou 24. No entanto, é importante destacar que:

• A configuração deve ser testada em diferentes plataformas (MX, EX, PTX etc.), pois algumas séries podem ter limitações específicas .
• A Juniper costuma publicar suporte por família de plataformas. Certifique-se de validar se o equipamento em uso suporta source-port conforme documentado.
• Em versões Evolved do Junos (ex. 24.x), deve haver suporte automático, mas a combinação com next-header tcp também é recomendada quando aplicável.

Última atualização: 25/6/2025 17:22 BRT

Adriano Cansian

Adriano Mauro Cansian, Doutor em Física Computacional e Professor Associado e pesquisador da UNESP – Universidade Estadual Paulista, possui 30 anos de experiência em pesquisa, desenvolvimento e ensino de segurança cibernética. Fundador e coordenador do Laboratório ACME! Cybersecurity Research, e revisor das revistas “Computers & Security” e “International Journal of Forensic Computer Science“, consultor e membro de vários comitês e organizações técnicas para promover a pesquisa em segurança da informação, além de atuar como voluntário em organizações de governança da Internet.

diario.cylo.com.br/author/adriano-cansian/