Vol. 1 No. 20250704-644 (2025)

Nova vulnerabilidade em roteadores Juniper: alerta e mitigação

Adriano Cansian | adriano.cansian@unesp.br | 04/07/2025


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


Vol. 1 No. 20250620-619 (2025)

O Poder do SSL Deep Inspection nas Investigações de exfiltração de Dados

Hector Carlos Frigo | hector@cylo.com.br | 20/06/2025

Nos últimos meses temos recebido inúmeros alertas relatando possíveis vazamentos de dados, por se tratar de um tópico extremamente sensível, podendo comprometer operações do cliente e com alto potencial de afetar diretamente sua propriedade intelectual, aos poucos começamos a desenvolver técnicas que otimizaram nosso tempo de resposta, nos ajudando a detectar, qual volume de dados foi exfiltrado do ambiente, e o que na minha opinião é o mais importante.. QUAIS dados foram exfiltrados. Desafio que tínhamos sempre ao lidar com esse tipo de incidente (identificar quais arquivos foram movimentados para fora da empresa, sempre foi uma grande dificuldade). Com essa evolução, foi possível realizar uma melhor distinção entre os casos de incidentes reais e casos falsos positivos.

Como ponto chave da melhora do nosso processo, identificamos que a adoção do uso de SSL Deep-Inspection para todo trafego de rede, possibilita uma visualização única e mais assertiva no trafego suspeito que será investigado por nós, Analistas de SOC, essa tecnologia viabiliza o monitoramento do trafego na camada de aplicação, tornando possível observar acesso a subdiretórios, e também identificar quais ARQUIVOS estão sendo movimentados para destinos fora do ambiente da empresa.

Para uma melhor visualização desta solução em funcionamento, realizei alguns testes com um firewall da Fortinet em um ambiente de teste, o qual será descrito abaixo (Lembrando que a aplicação do Deep-Inspection deve ser semelhante independente do serviço de Firewall adotado)

Primeiro criei alguns arquivos com nomes bem tendenciosos, para realizar o teste

Após isso, realizei a criação de uma regra no firewall batizando-a de “Teste Deep Inspection”, permitindo todo trafego LAN to WAN sem restrições e por fim habilitar a função de Deep-inspection na regra.

Após a criação da regra, devemos testá-la, para isso, basta entrar em um site que possua SSL ativo e observar seu certificado digital, acessei o Google.com, que originalmente possui o certificado atribuído pelo Google Trust Services.

Com a regra de SSL Deep Inspection funcionando, espera-se observar um certificado digital emitido por nosso serviço de Firewall, e não mais o certificado original criado pela provedora do site

Certificado do google.com SEM Deep-Inspection habilitado
Certificado do google.com COM Deep-Inspection habilitado

Com a regra funcionando, vamos dar inicio ao teste prático, onde realizei o UPLOAD dos 4 arquivos que criei em minha estação de teste, para o meu Google Drive PARTICULAR (Comportamento muito comum observado em diversos alertas de Exfiltração de dados)

Upload de arquivos realizados com sucesso! Vamos ver o que os logs do Firewall têm a nos dizer…

Realizei um filtro baseado no endereço MAC da minha estação de teste, para facilitar encontrar os logs do Upload, e depois de alguns segundos de espera, lá estava… Todos os arquivos que foram movimentados para o meu Google Drive particular por meio de conexões realizadas utilizando a rede da empresa, com a regra de Deep-Inspection ativa e operante, identificados por nome e extensão do arquivo (sendo possivel também adicionar o filtro do tamanho do arquivo) simplesmente com a aplicação de uma regra facilmente configurada em nosso Firewall.

Imaginando a aplicação deste exemplo em um ambiente real, onde é extremamente necessário monitorar as ações realizadas em todos os endpoints, justamente para prevenir vazamento de propriedade intelectual, e evitar perdas devastadoras para a empresa, empregar o SSL Deep Inspection como aliado nas investigações de alerta de exfiltração de dados é altamente recomendado

É importante ressaltar que, o emprego desta tecnologia deve somente ocorrer, após o consentimento dos usuários, ou seja, os colaboradores conectados a rede, devem saber que estão sendo monitorados por sua equipe de SOC, fato pode ser adicionado a uma cláusula do contrato de trabalho por exemplo, pois a ausência desse consentimento, pode implicar diretamente a quebra do direito a privacidade, garantida principalmente pela LGPD porem abordada também em diversos outros textos de lei.

Neste pequeno exemplo, foi possivel observar o quão importante o SSL Deep-Inspection pode ser para detecção de exfiltração de dados, Ouso dizer que é uma técnologia essencial contra vazamento de informações, em um mundo onde a propriedade intelectual com certeza é um dos ativos mais valiosos da sua empresa.

Vol. 1 No. 20250606-613 (2025)

De Botnet para… jogo online?

Yuri Augusto | yuri@cylo.com.br | 06/06/2025

Recentemente o IPS detectou diversos alertas suspeitos, onde alguns dispositivos, móveis estavam se conectando à botnets. Bom… no mínimo preocupante. A botnet? Sality botnet. Isso já pareceu estranho, pois todos os artigos encontrados na internet referentes à essa bonet, são datados de 10 anos atrás ou mais ainda mais antigos que isso. Mas é aquele negócio, melhor um falso positivo investigado do que um positivo não investigado, correto?

Todas as conexões que o IPS pegou (e algumas outras não alertadas pelo sistema) eram destinadas à porta 7500 UDP. O endereço? Tencent e Zenlayer, duas empresas de cloud. O maior problema ao realizar essas investigações é a teimosia do ser humano, e aqui não foi diferente. Bati cabeça com os endereços de destino e portas usadas, nenhum resultado. Afinal, os endereços não são maliciosos.

Ao parar e descansar um pouco, as sinapses voltaram a ocorrer, descansar a mente também ajuda a assimilar a informação. Se não encontrei nada referente à essas portas, hora de olhar outros logs, por exemplo, application control. E lá estava uma nova informação relevante, “Call of Duty Mobile”, apesar de ainda não ter certeza do que estava ocorrendo, pelo menos não é algo malicioso (ufa).

Agora a pesquisa ficou mais fácil, fazer a verificação dos endereços e portas utilizadas pelo jogo. E lá estava, as informações coincidem com todas as comunicações observadas no alerta.

Informações de endereços e portas retiradas do site do jogo.

Já cheguei até aqui, então vamos fazer a prova final? Instalar no próprio celular e avaliar as conexões de rede através do firewall (de quebra ainda tira um lazer). Pronto, paranoia controlada, todas as conexões “suspeitas” estão sendo realizadas pelo jogo.

Validação realizada pelo pcap, capturado pelo firewall.

Por fim, fica aquele questionamento “excesso de zelo” ou “perca de tempo”? Em um ambiente crítico, onde uma pequena falha pode levar à danos irreparáveis, com certeza é melhor prezar pelo excesso de zelo. Nunca assuma nada, sempre investigue.

Vol. 1 No. 20250429-410 (2025)

Fortalecimento dos Aspectos de Segurança em Firewalls Palo Alto Networks

Giuliano Cardozo Medalha | giuliano@wztech.com.br | 29/04/2025


O fortalecimento de configurações relacionadas a segurança de acesso, dos firewalls Palo Alto Networks, requer uma abordagem multifacetada para aprimorar a postura de segurança, focando em configuração segura, controle de acesso e manutenção contínua.

As principais etapas incluem alterar senhas padrão, implementar políticas de senhas robustas, estabelecer administração baseada em papéis e limitar o acesso por meio de listas de controle de acesso (ACLs). Além disso, é crucial monitorar regularmente os logs do sistema e de configuração, manter atualizações de software e conteúdo em dia e proteger a interface de gerenciamento.

Abaixo seguem alguns tópicos considerados importantes, no sentido desse fortalecimento:

  1. Configuração Segura e Controle de Acesso
  • Alterar Senhas Padrão

Nunca utilize a senha padrão de administrador. Crie senhas fortes e únicas para todas as contas administrativas, evitando senhas fáceis de adivinhar.

  • Habilitar Perfis e Grupos de Administradores

Restrinja o acesso com base em papéis e responsabilidades. Configure perfis administrativos para limitar o que cada administrador pode modificar, garantindo o princípio do menor privilégio.

  • Aplicar Políticas de Senhas Fortes

Exija senhas complexas, com combinações de letras, maiúsculas, minúsculas, números e caracteres especiais.

Implemente trocas frequentes de senhas e considere métodos de autenticação externa, como LDAP ou SAML, para maior segurança.

  • Perfis de Gerenciamento de Interfaces

Desative serviços desnecessários, como ping, SSH e acesso web, em interfaces que não os requerem ( principamente as interfaces que ficam expostas pra internet ).

Configure controles de acesso baseados em IP. Restrinja o acesso às interfaces de gerenciamento apenas a endereços IP específicos e VLANs autorizados.

Coloque a interface de gerenciamento em uma VLAN segura. Limite o acesso à interface de gerenciamento apenas para o pessoal ou time autorizado. Lembrar de remover perfis de autenticação, autorizações e permissões, quando um colaborador se desligar da empresa ou do ambiente.

  • Limitar Acesso via Listas de Controle de Acesso (ACLs)

Configure regras de firewall para restringir o fluxo de tráfego com base na origem, destino e protocolo, reduzindo a superfície de ataque.

  1. Manutenção Contínua e Monitoramento
  • Manter Atualizações de Conteúdo e Software

Atualize regularmente o software e os pacotes de conteúdo do firewall para corrigir vulnerabilidades conhecidas e melhorar a proteção contra ameaças emergentes.

  • Configurar Notificações para Logs de Sistema e Configuração

Configure o firewall para enviar alertas sobre eventos críticos, como tentativas de login não autorizadas ou alterações de configuração.

  • Monitorar Logs de Sistema e Configuração

Revise regularmente os logs para identificar atividades suspeitas ou tentativas de acesso não autorizado, permitindo uma resposta rápida a incidentes.

  • Utilizar a Ferramenta de Avaliação de Melhores Práticas (BPA) da Palo Alto Networks

Essa ferramenta realiza verificações de segurança e fornece uma pontuação, ajudando a identificar áreas que precisam de melhorias na configuração do firewall.

  1. Medidas Adicionais de Segurança
  • Usar uma String de Comunidade SNMP Forte

Caso o SNMP seja necessário, escolha uma string de comunidade única e difícil de adivinhar para evitar acessos não autorizados.

  • Habilitar SNMP Apenas em Interfaces Necessárias

Ative o SNMP somente em interfaces internas onde ele é estritamente necessário, reduzindo a exposição.

  • Considerar Autenticação Externa

Utilize métodos de autenticação robustos, como LDAP ou SAML, para reforçar a segurança das credenciais administrativas.

  • Proteger a Interface de Gerenciamento

A Palo Alto Networks destaca a importância de proteger a interface de gerenciamento, que é um ponto de entrada potencial para atacantes.

  • Implementar um Mecanismo Abrangente de Logs e Alertas

Configure logs detalhados e alertas para rastrear todos os eventos significativos, facilitando a identificação de ameaças potenciais.

  • Estabelecer Protocolos de Backup e Restauração

Faça backups regulares da configuração do firewall e tenha um plano claro para restauração em caso de falhas ou incidentes.

  • Alinhar Políticas com Padrões de Conformidade

Garanta que as configurações do firewall estejam alinhadas com padrões e regulamentações do setor, como GDPR, HIPAA ou PCI-DSS, conforme aplicável.

  • Submeter Firewalls a Testes Regulares

Realize testes de penetração e auditorias de segurança periódicas para identificar e corrigir vulnerabilidades.

  • Considerar o Uso de um Centro de Operações de Segurança (SOC)

Capacidades de SOC para monitoramento e resposta a eventos de segurança, o que pode ser uma opção para organizações com recursos limitados.

Conclusão:

Ao seguir estas diretrizes de fortalecimento, é possível melhorar significativamente a postura de segurança dos firewalls Palo Alto Networks, reduzindo o risco de acesso não autorizado e atividades maliciosas. A combinação de configuração segura, monitoramento contínuo e conformidade com melhores práticas é essencial para proteger redes corporativas contra ameaças cibernéticas em constante evolução.