Autor: 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.

Vol. 1 No. 20250822-906 (2025)

Vulnerabilidade da Cisco de 2018 Continua Sendo Fortemente Explorada em 2025

Adriano Cansian | adriano.cansian@unesp.br | 22/08/2025

Ação Urgente

Se você gerencia dispositivos Cisco, verifique imediatamente se o Smart Install está ativado e aplique mitigações, especialmente dado as explorações recentes por atores estatais. Consulte o advisory oficial para versões específicas:

 https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20180328-smi2.html. 

Informações Gerais

Estamos cientes que, apesar de ter sido divulgada há mais de sete anos, a vulnerabilidade CVE-2018-0171 no recurso Smart Install do software Cisco IOS e IOS XE permanece uma ameaça ativa, com explorações recentes por grupos cibernéticos apoiados por governos estrangeiros. Essa falha crítica permite que atacantes remotos não autenticados causem negação de serviço (DoS) ou executem código arbitrário em dispositivos afetados, facilitando o roubo de configurações de rede e o estabelecimento de acesso persistente. 

Recentemente, agências como o FBI e a Cisco emitiram alertas sobre o uso contínuo dessa vulnerabilidade por atores estatais russos e chineses, enfatizando a necessidade urgente de mitigações em dispositivos legados ou não atualizados. 

A vulnerabilidade CVE-2018-0171 tem uma pontuação EPSS (Exploit Prediction Scoring System) de aproximadamente 0.909, o que corresponde a uma probabilidade de exploração de cerca de 91%. O seu percentil de EPSS é de 98.1%, colocando-a no percentil 100 em termos de probabilidade de exploração.

CaracterísticaDetalhe
CVE IDCVE-2018-0171
Pontuação EPSS0.90926 – 0.90994 (90.994%)
Percentil EPSS98.1% – 100%
GravidadeCrítica
Vetor CVSS v3.1CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Pontuação Base CVSS v3.19.8

Detalhes da Vulnerabilidade

A CVE-2018-0171 surge de uma validação inadequada de dados em pacotes recebidos pelo recurso Smart Install, que é projetado para simplificar a instalação e configuração automática de switches Cisco. Um atacante pode explorar a falha enviando pacotes maliciosos para a porta TCP 4786, causando um overflow de buffer que leva a recargas inesperadas do dispositivo, crashes ou execução remota de código (RCE). 

•  Vetor de Ataque: Remoto, sem autenticação necessária. Basta que o dispositivo esteja exposto à rede com o Smart Install ativado (padrão em muitos modelos antigos).

•  Impacto Técnico: Pode resultar em extração de arquivos de configuração via TFTP, injeção de comandos ou implantação de implantes como o SYNful Knock para persistência. 

•  Sistemas Afetados: Switches e roteadores Cisco rodando IOS ou IOS XE com Smart Install ativado, incluindo modelos industriais como os Rockwell Automation Stratix. Dispositivos end-of-life (EOL) são particularmente vulneráveis, pois não recebem mais atualizações.

A fraqueza está associada ao CWE-119 (buffer overflow) e CWE-20 (validação inadequada de entrada), tornando-a explorável por meio de provas de conceito (PoCs) públicas disponíveis desde 2018. 

Explorações Recentes e Contexto Histórico

Embora corrigida pela Cisco em março de 2018, a CVE-2018-0171 continua sendo explorada em 2025 devido à persistência de dispositivos não patchados em infraestruturas críticas.

•  Atividade Russa (Static Tundra / FSB Center 16): Desde 2022, o grupo russo Static Tundra, ligado ao FSB, explora ativamente a vulnerabilidade para comprometer milhares de dispositivos globais, incluindo roteadores em telecomunicações, educação e manufatura nos EUA, Ásia, África e Europa. Eles usam SNMP para acesso inicial, roubam configurações e implantam túneis GRE para persistência, com foco intensificado em alvos ucranianos desde a guerra Rússia-Ucrânia.  O FBI emitiu um alerta em 20 de agosto de 2025, destacando ataques a infraestrutura crítica. 

•  Atividade Chinesa (Salt Typhoon): Em dezembro de 2024 e janeiro de 2025, o grupo chinês Salt Typhoon explorou a CVE-2018-0171 em conjunto com credenciais roubadas para infiltrar redes de telecomunicações nos EUA, persistindo por mais de três anos.  IPs maliciosos de origens como Suíça e EUA foram observados em tentativas de exploração. 

Essas campanhas demonstram como vulnerabilidades antigas em dispositivos legados facilitam espionagem cibernética em escala global, com alertas recentes da CSA de Singapura e Cyber.gc.ca reforçando a urgência. 

Impacto e Riscos

•  Severidade: CVSS 9.8 (Crítica), com alta exploitability devido à ausência de autenticação e PoCs públicas. Probabilidade de exploração (EPSS) é elevada, especialmente em redes expostas.

•  Consequências: Roubo de dados sensíveis, DoS em infraestrutura crítica, pivoteamento para outros sistemas e implantação de malware persistente. Setores como telecom, energia e governo são os mais afetados, com potencial para interrupções em massa.

•  Por Que Ainda Relevante?: Milhões de dispositivos Cisco EOL ou não patchados permanecem online, detectáveis via ferramentas como Shodan, facilitando scans em massa.

Recomendações e Mitigação

A Cisco recomenda ações imediatas para mitigar o risco:

•  Correções Principais: Aplique patches de 2018 para versões suportadas de IOS/IOS XE. Para dispositivos EOL, migre para modelos atuais.  Consulte o advisory oficial para versões específicas: https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20180328-smi2.html. 

•  Workarounds: Desative o Smart Install com o comando no vstack no modo de configuração global. Bloqueie a porta TCP 4786 via ACLs ou firewalls. Desative SNMP se não essencial, ou use versões seguras (v3 com autenticação).  

•  Melhores Práticas: Realize scans regulares de vulnerabilidades, monitore tráfego na porta 4786 e adote hardening de rede (ex.: senhas fortes, SSH em vez de Telnet). Use ferramentas como Cisco Talos para inteligência de ameaças.  

•  Detecção: Verifique logs por acessos SNMP suspeitos ou tentativas na porta 4786.

Epílogo

Essa vulnerabilidade destaca a importância de gerenciar patches em dispositivos de rede, mesmo anos após a divulgação.  Organizações com dispositivos Cisco devem priorizar auditorias imediatas, especialmente em ambientes OT ou de infraestrutura crítica, para evitar compromissos por atores como Static Tundra ou Salt Typhoon.

Referências

•  Cisco Security Advisory: Cisco IOS and IOS XE Software Smart Install Remote Code Execution Vulnerability. Disponível em: https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20180328-smi2.html

•  NVD – CVE-2018-0171 Detail. Disponível em: https://nvd.nist.gov/vuln/detail/cve-2018-0171

•  FBI: Russian Government Cyber Actors Targeting Networking Devices. Disponível em: https://www.ic3.gov/PSA/2025/PSA250820

•  CyberScoop: Russian cyber group exploits seven-year-old network vulnerabilities. Disponível em: https://cyberscoop.com/russian-static-tundra-hacks-cisco-network-devices-cve-2018-0171/

•  The Hacker News: FBI Warns FSB-Linked Hackers Exploiting Unpatched Cisco. Disponível em: https://thehackernews.com/2025/08/fbi-warns-russian-fsb-linked-hackers.html

•  Cisco Talos: Russian state-sponsored espionage group Static Tundra. Disponível em: https://blog.talosintelligence.com/static-tundra/

Vol. 1 No. 20250817-901 (2025)

Vulnerabilidade Crítica de Execução Remota de Código no Fortinet FortiSIEM

Adriano Cansian | adriano.cansian@unesp.br | 17/08/2025

Estamos cientes que a Fortinet emitiu um alerta sobre uma vulnerabilidade de gravidade crítica que afeta seu produto FortiSIEM. A falha foi catalogada como a vulnerabilidade CVE-2025-25256, e permite que um invasor não autenticado execute comandos remotamente no sistema operacional dos dispositivos afetados.

A vulnerabilidade recebeu uma pontuação CVSS de 9.8, refletindo seu potencial de impacto máximo. A exploração bem-sucedida pode resultar no comprometimento total do equipamento, permitindo que o invasor execute código arbitrário com privilégios elevados.

Apesar da Fortinet não haver especificados indicadores de comprometimento (IoCs), temos a confirmação de que já existe pelo menos um código de exploit funcional para esta falha, o que significa que ataques ativos estão em andamento. Isso eleva drasticamente a urgência para a aplicação das devidas correções.

Detalhes Técnicos da Vulnerabilidade

  • Causa Raiz: A falha reside em uma vulnerabilidade de injeção de comando no sistema operacional, que pode ser acionada por meio de solicitações CLI (Interface de Linha de Comando) especialmente criadas para esse fim.
  • Vetor de Ataque: O ataque pode ser realizado remotamente, sem a necessidade de qualquer tipo de autenticação prévia, tornando qualquer sistema vulnerável exposto à internet um alvo fácil.
  • Impacto: A exploração permite a Execução Remota de Código (RCE), dando ao atacante controle total sobre o sistema FortiSIEM.

Versões Afetadas

A vulnerabilidade impacta muitas versões do FortiSIEM. As organizações que utilizam as seguintes versões devem tomar ações imediatas:

VersionAffectedSolution
FortiSIEM 7.4Not affectedNot Applicable
FortiSIEM 7.37.3.0 through 7.3.1Upgrade to 7.3.2 or above
FortiSIEM 7.27.2.0 through 7.2.5Upgrade to 7.2.6 or above
FortiSIEM 7.17.1.0 through 7.1.7Upgrade to 7.1.8 or above
FortiSIEM 7.07.0.0 through 7.0.3Upgrade to 7.0.4 or above
FortiSIEM 6.76.7.0 through 6.7.9Upgrade to 6.7.10 or above
FortiSIEM 6.66.6 all versionsMigrate to a fixed release
FortiSIEM 6.56.5 all versionsMigrate to a fixed release
FortiSIEM 6.46.4 all versionsMigrate to a fixed release
FortiSIEM 6.36.3 all versionsMigrate to a fixed release
FortiSIEM 6.26.2 all versionsMigrate to a fixed release
FortiSIEM 6.16.1 all versionsMigrate to a fixed release
FortiSIEM 5.45.4 all versionsMigrate to a fixed release

Recomendações e Mitigação

A recomendação principal e mais eficaz é a atualização imediata dos sistemas para as versões corrigidas disponibilizadas pela Fortinet.

Para ambientes onde a aplicação do patch não pode ser realizada imediatamente, a Fortinet sugere uma mitigação temporária: restringir o acesso à porta 7900 (phMonitor) do FortiSIEM, limitando a exposição a redes confiáveis e bloqueando o acesso externo.

Dada a existência de um exploit ativo, a inação não é uma opção. Recomenda-se que todos os administradores de sistemas Fortinet validem suas versões e apliquem os patches de segurança com a máxima prioridade para proteger seus ativos contra comprometimento.

Referências:

fortiguard.fortinet.com: https://fortiguard.fortinet.com/psirt/FG-IR-25-152 

Vol. 1 No. 20250817-898 (2025)

Vulnerabilidade no Software Cisco FMC em conjunto com RADIUS

Adriano Cansian | adriano.cansian@unesp.br |

Publicada em 14 de agosto de 2025, a vulnerabilidade CVE-2025-20265 é uma falha de segurança crítica encontrada no software Cisco Secure Firewall Management Center (FMC) que permite a um invasor remoto e não autenticado injetar e executar comandos arbitrários no dispositivo. A vulnerabilidade recebeu o valor de pontuação máxima de 10.0 no Common Vulnerability Scoring System (CVSS), classificando-a como “CRÍTICA”, e demandando atenção imediata.

Atualização em 19/08/2025 09:33 GMT-3:

  1. Publicação do EPSS: A CVE-2025-20265 obteve EPSS estável de 0.481%
  2. Baixo Risco de Exploração: probabilidade baixa de exploração nos próximos 30 dias
  3. Monitoramento Contínuo: Recomenda-se continuar acompanhando nos próximos dias/semanas. Utilize esse [LINK].

Pré-condição importante:

Entretanto, antes que se entre em pânico, é importante saber que existe uma pré-condição específica e indispensável para que a vulnerabilidade CVE-2025-20265 possa ser explorada: O software Cisco Secure Firewall Management Center (FMC) deve estar configurado para usar autenticação externa via RADIUS.

Isso se aplica tanto para o acesso à interface de gerenciamento baseada na web quanto para o acesso via SSH.

Se o sistema não estiver usando RADIUS para autenticação (por exemplo, se estiver usando contas de usuário locais, LDAP ou SAML), ele não está vulnerável a esta falha específica, mesmo que esteja executando uma versão de software afetada. A rota de ataque depende inteiramente da maneira como o subsistema RADIUS processa as credenciais de login.

IMPORTANTE: mesmo que você não utilize autenticação RADIUS, certifique-se que ela não está habilitada. Veja as instruções no apêndice desse texto, mais abaixo.

Pontos principais:

Causa: A falha ocorre devido ao tratamento inadequado da entrada do usuário durante a fase de autenticação no subsistema RADIUS. Um invasor pode explorar isso enviando entradas criadas especificamente ao inserir credenciais para serem autenticadas no servidor RADIUS configurado.

Fraqueza: CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component (‘Injection’)

Impacto: Uma exploração bem-sucedida pode permitir que o invasor execute comandos com um alto nível de privilégio, levando a uma possível comprometimento completo do sistema.

Produtos Afetados: As versões 7.0.7 e 7.7.0 do software Cisco Secure FMC são afetadas se tiverem a autenticação RADIUS ativada para a interface de gerenciamento baseada na web, gerenciamento SSH ou ambos.

Descoberta: A vulnerabilidade foi descoberta por um engenheiro de software da Cisco durante testes de segurança internos. Até o momento, a Cisco não tem conhecimento de nenhuma exploração desta vulnerabilidade em ataques reais.

Probabilidade de exploração: no momento de escrita desse alerta (17.ago.2025 18:30 GMT-3) a análise do EPSS que indica a probabilidade de exploração encontra-se pendente. O sistema EPSS atualiza suas pontuações diariamente, e é provável que um valor para esta CVE seja disponibilizado em breve, dada a sua alta criticidade. Até o momento não existe exploit público de ataque disponível, até onde se sabe.

Solução principal:

A correção para essa vulnerabilidade é simples. A forma mais eficaz e recomendada de corrigi-la é instalar as atualizações de software fornecidas pela Cisco. Os administradores devem atualizar seus sistemas para uma versão de software que não esteja vulnerável.

A empresa lançou versões corrigidas do software Cisco Secure Firewall Management Center (FMC) que resolvem essa falha. Consulte a recomendação do fabricante em https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-radius-rce-TNBKf79

Mitigação:

Se não for possível aplicar a atualização de software imediatamente, a Cisco recomenda as seguintes ações para mitigar o risco:

  1. Desativar a Autenticação RADIUS: A vulnerabilidade só pode ser explorada se a autenticação externa via RADIUS estiver habilitada. A principal mitigação é desativar o RADIUS para o acesso de gerenciamento (tanto para a interface web quanto para o SSH).
  2. Usar Métodos de Autenticação Alternativos: Em vez de RADIUS, os administradores podem configurar outros métodos de autenticação que não são afetados por esta vulnerabilidade, como:
    • Contas de usuário locais.
    • Autenticação externa via LDAP (Lightweight Directory Access Protocol).
    • Logon Único (SSO) usando SAML (Security Assertion Markup Language).

Referências

APÊNDICE – Como verificar se a autenticação RADIUS está habilitada no Cisco

1. Passo a Passo para Verificação via interface web

O processo consiste em duas etapas principais:

  1. Verificar se existe um servidor RADIUS configurado e ativo.
  2. Confirmar se esse servidor RADIUS está sendo usado para autenticação.

Etapa 1: Localizar e Inspecionar os Servidores de Autenticação Externa

Primeiro, você precisa ver onde os servidores de autenticação externa, como RADIUS, LDAP ou SAML, são configurados.

  1. Faça login na interface web do seu FMC.
  2. Navegue até a página de Autenticação Externa:
    • No menu superior, clique em System (Sistema).No menu suspenso, clique em Users (Usuários).Na página de Usuários, clique na aba External Authentication (Autenticação Externa).
    O caminho é: System > Users > External Authentication.
  3. Analise a Lista de Objetos de Autenticação:
    • Nesta página, você verá uma lista de todos os “objetos” de autenticação externa que foram criados.
    • Procure por qualquer objeto na lista cujo Authentication Method (Método de Autenticação) seja RADIUS.
  4. Verifique o Status do Objeto RADIUS:
    • Depois de encontrar um objeto RADIUS, olhe para a coluna Status.
    • Se o círculo de status estiver verde e o texto disser Enabled (Habilitado), significa que o FMC tem uma configuração RADIUS funcional e ativa.
    O que isso significa até agora? Você confirmou que o FMC está configurado para se comunicar com um servidor RADIUS. Agora, precisamos verificar se ele está realmente usando essa configuração para logins.

Etapa 2: Verificar se o RADIUS é o Método de Login Padrão

Mesmo que um servidor RADIUS esteja habilitado, ele pode não estar em uso. Ele precisa ser definido como o método de autenticação para os logins da interface web ou do SSH.

  1. Permaneça na mesma página (System > Users > External Authentication).
  2. Role a página para baixo até encontrar a seção chamada Default Authentication (Autenticação Padrão).
  3. Examine as Configurações Padrão:
    • Esta seção permite que você defina qual método de autenticação será usado por padrão para diferentes tipos de acesso.
    • Procure pelas opções:
      • Web: Para logins na interface gráfica.
      • SSH: Para logins via linha de comando.
  4. Verifique se o RADIUS está selecionado:
    • Olhe para os menus suspensos ao lado de Web e SSH.
    • Se algum desses menus estiver configurado para usar o objeto de autenticação RADIUS que você identificou na Etapa 1, então a autenticação RADIUS está ativa e em uso para esse tipo de acesso.

Para estar vulnerável à CVE-2025-20265, as seguintes condições devem ser verdadeiras na interface web:

(Condição 1 / Etapa 1): Você tem um objeto de autenticação externa com o método RADIUS que está Habilitado (Enabled)

AND

(Condição 2 / Etapa 2): Na seção Default Authentication, o menu suspenso para Web ou SSH (ou ambos) está selecionado para usar esse objeto RADIUS.

Se ambas as condições forem atendidas e sua versão de software for uma das afetadas (como 7.7.0 ou 7.0.7), seu sistema está vulnerável e requer ação imediata.

2. Passo a Passo para Verificação via CLI

A configuração de autenticação externa não é gerenciada por um único comando “show” simples. Você precisará inspecionar os arquivos de configuração diretamente ou usar utilitários do sistema. A maneira mais confiável é usar o FMC expert mode para acessar o shell do Linux e, em seguida, consultar o banco de dados de configuração. O método recomendado via CLI é:

  1. Acesse a CLI do FMC: Conecte-se ao seu dispositivo FMC usando SSH.
  2. Entre no Modo expert: No prompt da CLI, digite o comando expert. Isso lhe dará acesso ao shell do Linux subjacente.Bash> expert
  3. Execute o Comando de Consulta ao Banco de Dados: O FMC armazena suas configurações em um banco de dados. Você pode consultá-lo diretamente para encontrar as configurações de autenticação RADIUS. O comando a seguir usa mysql para consultar a tabela auth_modules no banco de dados usm_db e filtra por módulos RADIUS.Copie e cole o seguinte comando completo no prompt do expert mode: 
% sudo /usr/local/sf/bin/sf-mysql -e 'SELECT name, is_enabled, is_default_web, is_default_cli FROM usm_db.auth_modules WHERE type="Radius"'

Como Interpretar a Saída

O comando retornará uma tabela. Preste atenção nas seguintes colunas para cada servidor RADIUS configurado (identificado pela coluna name):

  • is_enabled: Se o valor for 1, o objeto de autenticação RADIUS está habilitado. Se for 0, está desabilitado.
  • is_default_web: Se o valor for 1, este servidor RADIUS é usado para a autenticação padrão da interface web.
  • is_default_cli: Se o valor for 1, este servidor RADIUS é usado para a autenticação padrão do acesso SSH/CLI.

Exemplo de Saída Vulnerável:

Plain Text

+-------------------+------------+------------------+------------------+
| name              | is_enabled | is_default_web   | is_default_cli   |
+-------------------+------------+------------------+------------------+
| ServidorRADIUS_Corp |          1 |                1 |                1 |
+-------------------+------------+------------------+------------------+

Neste exemplo:

  • O objeto “ServidorRADIUS_Corp” está habilitado (is_enabled = 1).
  • Ele é usado para autenticação web (is_default_web = 1).
  • Ele é usado para autenticação CLI/SSH (is_default_cli = 1).

Se você vir is_enabled como 1 e pelo menos um dos is_default_web ou is_default_cli também como 1, seu sistema está usando autenticação RADIUS e está vulnerável (se estiver em uma versão de software afetada).

Se a tabela estiver vazia ou se todos os valores nas colunas is_enabled, is_default_web e is_default_cli forem 0, então a autenticação RADIUS não está ativa e você não está exposto a esta vulnerabilidade específica.

Este método CLI é ideal para verificações rápidas, auditorias ou para uso em scripts de automação.

<FIM DO DOCUMENTO>

Vol. 1 No. 20250808-789 (2025)

Vulnerabilidade no Microsoft Exchange Server

Adriano Cansian | adriano.cansian@unesp.br | 08/08/2025

INTRODUÇÃO

Estamos cientes de uma vulnerabilidade de alta gravidade, a qual permite que um agente de ameaça cibernética com acesso administrativo a um servidor Microsoft Exchange local aumente privilégios explorando configurações híbridas vulneráveis. Essa vulnerabilidade, se não for corrigida, pode afetar a integridade da identidade do serviço Exchange Online de uma organização. Uma vez explorada, permite que um atacante com acesso administrativo a um servidor MS Exchange local consiga elevar seus privilégios para o ambiente em nuvem (Exchange Online), potencialmente comprometendo todo o domínio.

Ela foi catalogada como a vulnerabilidade CVE-2025-53786 com pontuação CVSS de 8.0 (Alta).

  • Tipo: Escalonamento de privilégios.
  • Gravidade: Alta, com pontuação CVSS de 8.0.
  • Vetor:  CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
  • CWE-287: CWE-287: Improper Authentication
  • Impacto: Permite que um atacante com acesso administrativo local acesse o ambiente em nuvem sem deixar rastros facilmente detectáveis, explorando a confiança entre o Exchange local e o Exchange Online.
  • Causa principal: O uso de um service principal compartilhado para autenticação entre o servidor local e a nuvem em configurações híbridas, criando uma ligação que pode ser explorada.

OBSERVAÇÃO: Não há evidências de exploração ativa até o momento, 08 de agosto de 2025, mas a Microsoft classifica a vulnerabilidade como “Exploitation More Likely“ (Exploração Razoavelmente Provável) devido à sua gravidade. Independente de não haver relatos da exploração da vulnerabilidade em larga escala, nós recomendamos fortemente a aplicação de mitigação sugerida nesse documento.

A exploração é particularmente perigosa porque pode passar despercebida. O ataque não gera logs ou alertas evidentes, dificultando a detecção, já que usa funções legítimas do sistema.

RESUMO DA VULNERABILIDADE

O atacante já deve ter privilégios administrativos no servidor Exchange local, por exemplo, via uma senha fraca, outra vulnerabilidade, ação de phishing ou credenciais roubadas.

Como ocorre a exploração da vulnerabilidade:

  • O atacante acessa as keyCredentials do service principal, armazenadas na configuração do Exchange ou via PowerShell/Graph API.
  • Com essas chaves, ele gera um token S2S (server-to-server) válido para autenticação na nuvem.
  • Isso permite acesso a recursos como caixas de e-mail no Exchange Online, envio de e-mails em nome de outros usuários, alterações em configurações de segurança ou até pivô para outros serviços, como SharePoint Online.
  • Para entender o que é o service principal e o KeyCredentials e como esses se combinam para o ataque, consulte o apêndice desse alerta.

Quais os riscos associados:

  • Comprometimento de dados sensíveis (e-mails, configurações de segurança).
  • Movimento lateral para outros serviços na nuvem (como SharePoint).
  • Potencial para comprometimento total do domínio em ambientes híbridos.
  • A exploração é particularmente perigosa porque pode passar despercebida, mesmo com ferramentas de monitoramento como Conditional Access ou de autenticação MFA.

MITIGAÇÃO RECOMENDADA

1. Aplicar o hotfix de abril de 2025:

  • Instale a atualização de segurança em todos os servidores Exchange locais (2016, 2019 ou Subscription Edition) em modo híbrido.
  • Verifique se os servidores estão dentro do ciclo de suporte (ex.: Exchange 2019 CU14/CU15, Exchange 2016 CU23).

2. Fazer inventário e verificação:

  • Use o script HealthChecker.ps1 da Microsoft para identificar servidores afetados e gerar relatórios.

3. Migrar para um service principal dedicado:

  • Execute o Hybrid Configuration Wizard (HCW) atualizado para configurar uma nova entidade de serviço dedicada:
.\HybridConfigurationWizard.exe /Upgrade

.\HybridConfigurationWizard.exe /Configure
  • Redefina as keyCredentials do service principal compartilhado:
Connect-MgGraph -Scopes "Application.ReadWrite.All"
$sp = Get-MgServicePrincipal -Filter "displayName eq 'Exchange Hybrid Modern Auth Service Principal'"
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -KeyCredentials @()

4. Adotar boas práticas

  • Minimize permissões administrativas.
  • Habilite e monitore logs detalhados.
  • Desconecte da internet servidores Exchange ou SharePoint em fim de vida (EOL).
  • Considere migrar para protocolos mais seguros, como Graph API, e reduzir o uso de Exchange Web Services (EWS).

INFORMAÇÕES ADICIONAIS

  • Descoberta: A vulnerabilidade foi reportada por Dirk-jan Mollema da Outsider Security e apresentada na conferência Black Hat no último dia 6 de agosto de 2025.
  • Diretiva da CISA: Agências federais dos EUA foram obrigadas a mitigar a falha até 11 de agosto de 2025, mas a recomendação se estende a todas as organizações com ambientes híbridos.
  • Contexto maior: Tal falha reforça a necessidade de revisar configurações legadas em ambientes híbridos e adotar modelos de zero trust para minimizar riscos.

REFERÊNCIAS:

[1] CISA – Emergency Directives ED 25-02: Mitigate Microsoft Exchange Vulnerability – Released: Aug 7, 2025

[2] Microsoft Exchange Server Hybrid Deployment Elevation of Privilege Vulnerability – CVE-2025-53786 Security Vulnerability – Released: Aug 6, 2025

[3] CVE-2025-53786

APÊNDICE

A keyCredentials é como um “chaveiro” criptográfico, que funciona como uma carteira de identidade do service principal híbrido. Ela é usada para autenticar um servidor Exchange local na nuvem. Na vulnerabilidade CVE-2025-53786, um atacante com acesso administrativo local pode roubar esse chaveiro (keyCredentials) e usá-lo para fazer se passar pelo servidor, acessando o Exchange Online sem deixar rastros óbvios.

O que é um Service Principal?

Um service principal é uma identidade não-humana usada em sistemas da Microsoft (como o Azure Active Directory, agora Microsoft Entra ID) para autenticar aplicativos ou serviços, permitindo que eles interajam com outros recursos na nuvem, como o Exchange Online. No caso de ambientes híbridos do Exchange, o service principal é usado para facilitar a comunicação segura entre o Exchange Server local (on-premises) e o Exchange Online (nuvem).

  • Função no ambiente híbrido: O service principal híbrido atua como uma “ponte” de autenticação, permitindo que o servidor local execute ações na nuvem, como sincronizar dados, gerenciar caixas de e-mail ou autenticar usuários. Ele é configurado automaticamente pelo Hybrid Configuration Wizard (HCW) durante a criação do ambiente híbrido.

O que é a keyCredentials?

A keyCredentials é uma propriedade do service principal que armazena as chaves criptográficas (certificados ou chaves assimétricas) usadas para autenticar o service principal no Microsoft Entra ID. Essas chaves são essenciais para o processo de autenticação server-to-server (S2S), permitindo que o servidor local consiga provar sua identidade ao acessar recursos na nuvem.

  • Formato: A keyCredentials contém informações como:
    • Chave pública de um certificado.
    • Identificador da chave (keyId).
    • Tipo de chave (geralmente assimétrica, como RSA).
    • Datas de validade (início e fim).
  • Uso: Quando o servidor Exchange local precisa acessar o Exchange Online, ele usa a chave privada correspondente à keyCredentials para assinar um token de autenticação (JWT). Esse token é validado pela nuvem usando a chave pública armazenada na keyCredentials.

Vol. 1 No. 20250724-666 (2025)

Análise da Vulnerabilidade CVE-2025-53770 (ToolShell) no Microsoft SharePoint Server

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

RESUMO

A vulnerabilidade crítica CVE-2025-53770, apelidada de ToolShell, está sendo ativamente explorada por agentes maliciosos para comprometer servidores Microsoft SharePoint on-premises. A falha permite execução remota de código não autenticada, extração de chaves criptográficas sensíveis e implantação de ransomwares.


A exploração ocorre por meio de uma cadeia de ataques que combina as vulnerabilidades CVE-2025-49706 (bypass de autenticação via spoofing) e CVE-2025-49704 (deserialização insegura), possibilitando o controle total dos sistemas afetados.

A ameaça é classificada com CVSS 9.8 (Crítica) e já comprometeu dezenas de organizações públicas e privadas. Este artigo técnico detalha os vetores de ataque, os impactos operacionais, os indicadores de comprometimento (IoCs) e as ações recomendadas de mitigação com base em orientações oficiais da Microsoft.

Nota importante

• Se você utiliza Microsoft SharePoint na nuvem da Microsoft, como parte do pacote Microsoft 365, ESSA VULNERABILIDADE NÃO SE APLICA A VOCÊ.
• Se você usa sua própria instalação Microsoft SharePoint on-premises, seja no seu datacenter físico ou em colocation privado, ESSE ALERTA SE APLICA A VOCÊ.

Introdução

A vulnerabilidade CVE-2025-53770, apelidada de ToolShell, é uma falha crítica de execução remota de código (RCE) que afeta servidores on-premises do Microsoft SharePoint. Ela é uma variante da vulnerabilidade anterior CVE-2025-49706 e está sendo ativamente explorada em ataques reais. A exploração ocorre por meio de uma cadeia de vulnerabilidades que combina:

  • CVE-2025-49706: Permite bypass de autenticação por meio de técnicas de spoofing de rede, proporcionando acesso não autenticado aos sistemas.
  • CVE-2025-49704: Explora uma deserialização insegura de objetos manipulados, permitindo execução remota de código e acesso autenticado subsequente.

Essa cadeia de exploração, publicamente conhecida como ToolShell, foi demonstrada na competição Pwn2Own Berlin em maio de 2025 e possibilita que atores maliciosos obtenham controle total sobre os servidores SharePoint afetados. Os impactos incluem:

  • Acesso irrestrito ao conteúdo: Arquivos, configurações internas e sistemas de arquivos armazenados no SharePoint.
  • Execução remota de código: Capacidade de executar comandos maliciosos na rede interna, incluindo a implantação de web shells (.aspx), executáveis (.exe) e bibliotecas dinâmicas (.dll).
  • Persistência de acesso: Extração de chaves criptográficas (ValidationKey e DecryptionKey), permitindo a criação de tokens de autenticação forjados, mesmo após a aplicação de patches.
  • Escalada de ataques: Recentemente, observou-se o uso de técnicas de criptografia de arquivos e a distribuição do ransomware Warlock, indicando um aumento no potencial destrutivo dos ataques.

A vulnerabilidade está relacionada a uma deserialização insegura de dados não confiáveis no endpoint /ToolPane.aspx, explorado por meio de solicitações HTTP POST com cabeçalhos Referer forjados (ex.: apontando para /_layouts/SignOut.aspx). A pontuação CVSS da CVE-2025-53770 é 9.8 (Crítica), refletindo sua gravidade devido à facilidade de exploração e ao impacto devastador.

Contexto e impacto

O SharePoint é amplamente utilizado por organizações para colaboração e armazenamento de documentos, integrando-se a serviços como Office, Teams e OneDrive. A exploração ativa da ToolShell, adicionada ao catálogo de Vulnerabilidades Exploradas Conhecidas (Known Exploited Vulnerabilities – KEV) da CISA em 20 de julho de 2025, já comprometeu mais de 85 servidores em 54 organizações, incluindo agências governamentais, empresas de energia e universidades. Relatos apontam envolvimento de atores estatais chineses, como Linen Typhoon, Violet Typhoon e Storm-2603, em campanhas sofisticadas.

A combinação de acesso não autenticado, execução de código e implantação de ransomware amplia o risco, podendo resultar em:

  • Violações de dados sensíveis.
  • Interrupções operacionais críticas.
  • Comprometimento de sistemas interconectados na rede.

Detalhes técnicos

A exploração da ToolShell ocorre em duas etapas principais:

  1. Bypass de autenticação (CVE-2025-49706): Atacantes utilizam técnicas de spoofing para enviar solicitações HTTP POST maliciosas, manipulando cabeçalhos Referer e explorando falhas de validação no endpoint /ToolPane.aspx.
  2. Execução remota de código (CVE-2025-49704): A deserialização insegura de objetos manipulados permite a execução de payloads maliciosos, resultando em RCE. Isso inclui a criação de web shells (ex.: spinstall0.aspx) e a extração de chaves criptográficas.

Os atacantes também evoluíram suas táticas, empregando:

  • Payloads variados: Além dos tradicionais web shells (.aspx) e executáveis (.exe), também foram detectadas bibliotecas dinâmicas (.dll), ampliando a superfície de ataque.
  • Ransomware Warlock: Técnicas de criptografia de arquivos e distribuição de ransomware foram detectadas, indicando uma escalada no impacto dos ataques.

Essas táticas demonstram a sofisticação dos operadores e reforçam a urgência na aplicação das medidas de mitigação descritas a seguir.

Mitigações recomendadas

A Microsoft lançou atualizações de segurança em 21 de julho de 2025 para as versões suportadas do SharePoint Server (2016, 2019 e Subscription Edition), abordando a CVE-2025-53770 e a CVE-2025-53771 (uma vulnerabilidade de spoofing relacionada, mas não explorada ativamente). As seguintes medidas são recomendadas:

  1. Aplicar patches imediatamente: instale as atualizações de segurança mais recentes para SharePoint Server 2016, 2019 e Subscription Edition.
  2. Habilitar o AMSI: O Antimalware Scan Interface, ativado por padrão em atualizações de setembro de 2023 (SharePoint Server 2016/2019) e na versão 23H2 (Subscription Edition), pode bloquear exploits não autenticados.
  3. Implantar o Microsoft Defender Antivirus: Ative o Defender em todos os servidores SharePoint para detectar e mitigar atividades maliciosas.
  4. Rotacionar chaves criptográficas: Antes e após aplicar patches, rotacione as chaves ValidationKey e DecryptionKey do ASP.NET e reinicie o servidor IIS.
  5. Desconectar servidores expostos: Servidores SharePoint voltados para a internet, especialmente versões obsoletas (ex.: SharePoint Server 2013), devem ser desconectados até serem atualizados.
  6. Monitorar logs: Verifique solicitações POST ao endpoint /_layouts/15/ToolPane.aspx e a criação de arquivos suspeitos, como spinstall0.aspx.
  7. Restringir privilégios: Audite e minimize privilégios administrativos e de layout no SharePoint.
  8. Bloquear IPs maliciosos: Monitore e bloqueie tráfego de IPs associados aos ataques, como 107.191.58.76, 104.238.159.149, 96.9.125.147 e 45.77.155.170.

Indicadores de Comprometimento (IoCs)

  • Arquivos suspeitos: spinstall0.aspx, webshells customizados (.aspx, .dll, .exe) 
  • Endpoints observados: /ToolPane.aspx, /_layouts/15/ToolPane.aspx .
  • IPs maliciosos: 107.191.58.76 , 104.238.159.149 , 96.9.125.147 , 45.77.155.170 

Riscos e Considerações

A exploração da ToolShell é facilitada pela ausência de autenticação necessária e pela capacidade de extrair chaves criptográficas, garantindo acesso persistente. A introdução do ransomware Warlock eleva o risco, podendo causar perdas financeiras e operacionais significativas.

Conclusão

A vulnerabilidade CVE-2025-53770 (ToolShell), combinada com as falhas CVE-2025-49706 e CVE-2025-49704, representa uma ameaça crítica para servidores SharePoint on-premises. A aplicação imediata de patches, a habilitação do AMSI, a rotação de chaves criptográficas e o monitoramento contínuo são essenciais para mitigar os riscos. A escalada para ataques de ransomware, como o Warlock, reforça a necessidade de uma resposta rápida e coordenada. Para mais detalhes, consulte as orientações oficiais da Microsoft Microsoft:

Referências

  1. Microsoft Security Response Center (MSRC).
    Disrupting Active Exploitation of On-Premises SharePoint Vulnerabilities.
    Disponível em: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53770
  2. Cybersecurity and Infrastructure Security Agency (CISA).
    Microsoft Releases Guidance on Exploitation of SharePoint Vulnerabilities.
    Disponível em: https://www.cisa.gov/news-events/alerts/2025/microsoft-sharepoint-vulnerabilities
  3. CISA – Known Exploited Vulnerabilities Catalog.
    CVE-2025-53770 – SharePoint Remote Code Execution Vulnerability.
    Disponível em: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  4. Zero Day Initiative (ZDI) – Trend Micro.
    Pwn2Own Berlin 2025: Results and Exploits Summary.
    Disponível em: https://www.zerodayinitiative.com/blog/2025/berlin-pwn2own-results
  5. Microsoft Learn Documentation.
    Antimalware Scan Interface (AMSI) for SharePoint Server.
    Disponível em: https://learn.microsoft.com/en-us/sharepoint/install/antimalware-scan-interface
  6. MITRE Corporation.
    CVE-2025-53770 – Remote Code Execution in Microsoft SharePoint.
    Disponível em: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-53770

Vol. 1 No. 20250704-682 (2025)

Relatório de Vulnerabilidade para Solicitação de CVE: Bypass de Firewall em Conexões SSH no Junos OS

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

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

  1. Configure o roteador Juniper com a regra acima aplicada à interface loopback (lo0).
  2. Inicie um servidor SSH na rede interna (xxx.yyy.zzz.123, porta 22).
  3. 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)

Vol. 1 No. 20250704-644 (2025)

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

Adriano Cansian | adriano.cansian@unesp.br |

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. 20250619-581 (2025)

Falha Técnica, Não Ciberataque: Análise do Evento Global de 12 de Junho

Adriano Cansian | adriano.cansian@unesp.br | 19/06/2025

Resumo

Em 12 de junho de 2025, por volta das 14h51 (UTC-3), uma falha significativa em serviços baseados no Google Cloud causou indisponibilidade generalizada de plataformas como Spotify, Discord, Snap, Character.ai e até partes da infraestrutura da Cloudflare. A suspeita inicial de que se tratava de um ataque cibernético coordenado está descartada com base em dados técnicos e fontes confiáveis. O incidente, embora com impacto global, não teve relação com atividade maliciosa.

Linha do Tempo do Incidente

  • Início do problema: 12 Jun 2025, 17:51 UTC (14:51 GMT-03 BRT).
  • Atualização final do status: 12 Jun 2025, 22:46 UTC (19:46 GMT-03 BRT).
  • Locais afetados: Regiões Google asia-east1, europe-west4, africa-south1 e dezenas de outras.
  • Serviços impactados: APIs, autenticação, conectividade com backend, serviços de hospedagem.
  • Volume de impacto – relatos simultâneos de inacessibilidade: Spotify 46.000, Google 14.000 e Discord 11.000 (segundo Downdetector).
Fonte: ThousandEyes

Nossa análise

Com base nas evidências disponíveis até o momento, é altamente improvável que tenha ocorrido qualquer incidente relevante de segurança cibernética com impacto global em 12 de junho de 2025.

As interrupções observadas em diversos serviços online parecem ter sido causadas por uma falha técnica na infraestrutura do Google Cloud, e não por ações maliciosas ou por um ataque cibernético.

Não há registros oficiais nem indicadores técnicos que sustentem a hipótese de um ataque cibernético coordenado, apesar da circulação de algumas especulações e teorias da conspiração em redes sociais.

Diagnóstico Técnico

De acordo com Google Cloud Status Dashboard, o incidente envolveu instabilidades de rede e falhas no fornecimento de recursos críticos para workloads, com degradação em múltiplas zonas de disponibilidade. Apesar do escopo, não houve indícios de exploração de vulnerabilidades, DDoS, sequestro de rota BGP ou comportamento anômalo em logs de tráfego. O relatório completo de status do Google Cloud para o evento de 12/6/2025 pode ser visto nesse link confiável: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW

A Cloudflare, por sua vez, relatou impactos secundários limitados a serviços que utilizam o Google Cloud como backend. Segundo relatos de engenheiros da comunidade e usuários técnicos no Downdetector, houve menção a “erro de configuração de rede” e dependências indiretas afetando ao menos 19 data centers da Cloudflare.

Avaliação Cibernética

Do ponto de vista de threat intelligence e resposta a incidentes, nenhuma IOC (indicador de comprometimento) conhecida foi associada ao evento. Nenhum CSIRT internacional (como o US-CERT ou o JPCERT/CC) emitiu alertas relacionados, tampouco houve correlação com campanhas ativas de ameaça.

Buscas por “cyber attack”, “internet outage”, “DDoS” ou “APT activity” relacionadas a 12/06/2025 nas redes sociais e em feeds técnicos (como OTX AlienVault e MISP) não retornaram nenhuma correlação válida. Portanto, a hipótese de ataque coordenado por ator estatal ou hacktivismo pode ser tecnicamente descartada neste caso.

Implicações para Resiliência

Embora não tenha envolvido comprometimento, o incidente reforça o risco de falhas sistêmicas em infraestruturas centralizadas. A dependência excessiva de provedores de nuvem (monoculturas tecnológicas) pode gerar efeitos em cascata mesmo sem ações maliciosas.

É recomendável que analistas e arquitetos de segurança revisem:

  • Estratégias de redundância multi-cloud.
  • Monitoramento contínuo de integridade de serviços externos (SLAs e upstreams).
  • Planos de contingência para falhas de serviços de terceiros.

Conclusão

Apesar das suspeitas iniciais, o incidente de 12/06/2025 foi causado por uma falha técnica no Google Cloud e não representa um evento de segurança cibernética. Para times de resposta a incidentes, é mais um lembrete de que a visibilidade sobre a cadeia de dependências tecnológicas é tão crítica quanto a detecção de ataques.

Última atualização: 19/06/2025 às 20:29 GMT-03.

Vol. 1 No. 20250513-583 (2025)

Vulnerabilidades sendo exploradas em roteadores D-Link

Adriano Cansian | adriano.cansian@unesp.br | 13/05/2025

Nas últimas 72 horas estamos observando uma onda de ataques focados em roteadores D-Link, especificamente nos modelos D-Link DIR-600L, DIR-605L e DIR-619L. Essas vulnerabilidades são preocupantes porque muitos desses dispositivos atingiram o fim de seu suporte (EOL – End of Life), o que significa que não receberão atualizações de firmware para corrigir os problemas.

Esses roteadores foram lançados entre 2010 e 2013, quando o padrão 802.11n era amplamente adotado em dispositivos de entrada. Eles foram amplamente comercializados, especialmente em mercados emergentes como Índia, Brasil e Filipinas, devido ao seu baixo custo e funcionalidades básicas. Continuam em uso em residências e pequenas empresas, especialmente em regiões onde o custo de substituição é uma barreira, ou onde os usuários não estão cientes das vulnerabilidades.

Alguns exemplos de vulnerabilidades recentes nesses dispositivos:

1. D-Link DIR-600L

Vulnerabilidades muito recentes

  • CVE-2025-4349 (05/05/2025): Uma vulnerabilidade crítica no firmware até a versão 2.07B01, afetando a função formSysCmd. A manipulação do argumento host permite a execução remota de comandos, possibilitando que um atacante assuma o controle do roteador sem autenticação.
  • CVE-2025-4350 (05/05/2025): Outra falha crítica na função wake_on_lan do mesmo firmware. A manipulação de argumentos pode levar à execução de código arbitrário, permitindo ataques remotos.

2. D-Link DIR-605L

Vulnerabilidades muito recentes

  • CVE-2025-4441 (08/05/2025): Vulnerabilidade de estouro de buffer (buffer overflow) que pode ser explorada remotamente manipulando o parâmetro curTime. Isso permite a execução de código arbitrário, comprometendo o roteador.
  • CVE-2025-4442 (08/05/2025): Outro estouro de buffer remoto, desta vez via manipulação de configurações WAN, também permitindo execução de código malicioso.

3. D-Link DIR-619L

Vulnerabilidades muito recentes

  • CVE-2025-4454 (08/05/2025): Vulnerabilidade crítica no firmware 2.04B04, afetando a função wake_on_lan. A manipulação de argumentos permite execução remota de código, possibilitando o controle total do roteador.
  • CVE-2025-4453 (09/05/2025): Injeção remota de comandos no mesmo firmware, explorável via manipulação de parâmetros, permitindo que atacantes executem comandos arbitrários.
  • CVE-2025-4452 (09/05/2025): Estouro de buffer na função formSetWizard2, que pode ser explorado remotamente para comprometer o roteador.
  • CVE-2025-4449 (09/05/2025): Estouro de buffer na função EasySetupWizard3, presente em firmware não suportados, permitindo execução de código malicioso.

Possíveis impactos:

De forma bastante resumida, essas vulnerabilidades permitem que atacantes:

  • Executem comandos remotamente, comprometendo completamente o roteador.
  • Alterem configurações, como senhas Wi-Fi ou regras de firewall.
  • Obtenham credenciais de administrador, possibilitando o controle total do dispositivo.
  • Realizem ataques de rede, como redirecionamento de tráfego ou monitoramento de dados.
  • Obtenham controle total do roteador incluindo alterações de configuração e execução de código malicioso.
  • Realizem sequestro de sessões administrativas, comprometendo a segurança da rede.

O que fazer?

Infelizmente não há muito que possa ser feito que permita continuar utilizando esses equipamentos. A única solução definitiba é comprar um roteador moderno de um fabricante que ofereça suporte contínuo e atualizações regulares. Algumas ações configurações de segurança podem ajudar a reduzir um pouco o problema. De forma genérica, são elas:

  • Instalar o firmware mais recente disponível para o roteador.
  • Desativar o acesso remoto ao painel de administração.
  • Usar senhas fortes e exclusivas para o roteador e a rede Wi-Fi.
  • Desativar recursos como UPnP e WPS, que são alvos comuns de exploits.
  • Considerar usar um firewall ou software de monitoramento de rede.
  • Configurar redes separadas para dispositivos móveis e IoT, separando dos computadores para limitar o impacto de um eventual roteador comprometido.

Observações:

Conforme mencionado, estamos discutindo aqui as vulnerabilidades que estão sendo exploradas em roteadores D-Link D-Link DIR-600L, DIR-605L e DIR-619L nas últimas 72 horas, no momento de elaboração desse artigo. Existem diversos outros modelos de roteadores D-Link com problemas de vulnerabilidades. Porém, tais modelos continuam com o ciclo de vida ativo e recebem atualizações de segurança. Para uma busca completa de vulnerabilidades que estejam afetando os dispositivos D-Link, classificadas das mais recentes para as mais antigas, utilize essa [BUSCA] que irá abrir em outra janela.

Conclusão

Apesar da ausência de estatísticas precisas, pelas nossas obaservações, é plausível estimar que uma quantidade significativa de roteadores dos modelos D-Link DIR-600L, DIR-605L e DIR-619L permaneça em operação, particularmente em mercados emergentes, em função do seu baixo custo e das funcionalidades básicas que oferecem. No entanto, esses equipamentos encontram-se tecnicamente obsoletos e apresentam vulnerabilidades de segurança conhecidas e críticas.

Diante desse cenário, recomenda-se fortemente sua substituição por dispositivos mais modernos, que contem com atualizações de firmware e suporte contínuo por parte do fabricante. A manutenção desses modelos em redes ativas representa um vetor considerável de risco à segurança da informação.

Vol. 1 No. 20250414-272 (2025)

Sobre POCs para ataques a dispositivos Fortinet

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

Estamos cientes de pelo menos um agente de ameaça explorando vulnerabilidades importantes de execução remota de código (RCE) em produtos Fortinet, como FortiOS e FortiGate, que podem ser usadas para criar arquivos maliciosos ou explorar sistemas.

Estamos tratando aqui especificamente das vulnerabilidades catalogadas pela Fortinet como: FG-IR-22-398 (CVE-2022-42475), FG-IR-23-097 (CVE-2023-27997) e FG-IR-24-015 (CVE-2024-21762), todas relacionadas ao SSL VPN em dispositivos Fortinet.

Nesse ponto é importante observar que se o produto Fortinet não tem, e nunca teve, SSL VPN ativado, ele não é afetado por essas vulnerabilidades. Para determinar se um dispositivo Fortinet, como um FortiGate rodando FortiOS, tem ou teve o SSL VPN ativado é necessário fazer verificações na interface gráfica (GUI) ou na linha de comando (CLI) e, se julgar necessário, analisar logs ou configurações históricas.

Vamos analisar se há provas de conceito (PoCs – Proof Of Concept) públicas ou evidências de exploração para essas vulnerabilidades:

  • FG-IR-22-398 / CVE-2022-42475
    CVSS: 9,8 (Critical) – EPSS: 92,9% de chance de ataque (em 14/4/2025)
    Essa é uma vulnerabilidade crítica de estouro de buffer baseado em heap no FortiOS SSL VPN, permitindo execução remota de código (RCE) sem autenticação. A Fortinet confirmou exploração ativa em dezembro de 2022, com indicadores de comprometimento (IoCs) como arquivos maliciosos (ex.: /data/lib/libips.bak) e conexões a IPs suspeitos. Há PoC público disponível para essa vulnerabilidade. A exploração real sugere que atores avançados desenvolveram seus próprios métodos, possivelmente devido à sua complexidade e ao foco em alvos governamentais.

  • FG-IR-23-097 / CVE-2023-27997
    CVSS: 9,8 (Critical) – EPSS: 87,3% de chance de ataque (14/4/2025)
    Outro problema crítico de estouro de buffer no SSL VPN, também permitindo RCE sem autenticação. A Fortinet relatou exploração limitada em junho de 2023 e, presumivelmente, existe de uma PoC funcional, embora não amplamente divulgada. Um repositório no GitHub contém um exemplo de PoC que demonstra a corrupção da memória heap para executar código remoto. Esse PoC é funcional, mas requer adaptações específicas, indicando que atores de ameaça podem estar usando variantes para criar arquivos maliciosos ou backdoors.

  • FG-IR-24-015 / CVE-2024-21762:
    CVSS: 9,8 (Critical) – EPSS: 90,7% de chance de ataque (14/4/2025)
    Essa vulnerabilidade de escrita fora dos limites no FortiOS SSL VPN foi reportada como potencialmente explorada em fevereiro de 2024. A Fortinet alertou para ataques reais, mas não há PoC pública confirmada até agora. A exploração envolve requisições HTTP maliciosas, e a falta de um PoC público pode refletir a recente divulgação ou esforços para limitar a disseminação de exploits. A recomendação da Fortinet de desativar o SSL VPN como mitigação sugere que atores de ameaça podem estar usando essa falha para acesso inicial e implantação de payloads maliciosos.

As três vulnerabilidades são alvos atraentes para atores sofisticados devido à exposição do SSL VPN na internet. A criação de arquivos maliciosos, como backdoors ou implantes, é consistente com o comportamento observado em explorações de RCE, especialmente em FG-IR-22-398, onde malwares personalizados para FortiOS foram detectados. Embora PoCs públicos sejam limitados, a exploração ativa indica que grupos de ameaça possuem exploits funcionais, possivelmente compartilhados em fóruns privados ou desenvolvidos internamente.

RECOMENDAÇÃO:

Há PoCs públicas confirmadas para FG-IR-22-398 (CVE-2022-42475) e FG-IR-23-097 (CVE-2023-27997), mas para FG-IR-24-015, não há PoCs amplamente disponíveis, embora explorações reais tenham sido reportadas. Entretanto, atores específicos podem estar de posse de algum código de ataque, ou códigos de ataque podem se tornar disponíveis em algum momento próximo ou vindouro.

Por esse motivo, nossa recomendação é aplicar os patches mais recentes [1] e, se possível, desativar o SSL VPN (obviamente, caso a VPN não seja utilizada), além de monitorar sistemas por IoCs, como arquivos ou conexões suspeitas.

Para mais informações sobre o tratamento das vulnerabilidades relacionadas com SSL VPN em produtos Fortinet, por favor consulte [1].

Referências:

[1] Carl Windsor – “Analysis of Threat Actor Activity”. Fortinet. 10 de abril de 2025.

https://www.fortinet.com/blog/psirt-blogs/analysis-of-threat-actor-activity