Fortinet divulga segunda falha de autenticação em firewall corrigida em janeiro
- Cyber Security Brazil
- 12 de fev.
- 3 min de leitura
A Fortinet informou que a nova vulnerabilidade CVE-2025-24472, adicionada ao relatório FG-IR-24-535 hoje, não é um zero-day e já havia sido corrigida em janeiro.
Além disso, embora o comunicado atualizado mencione que ambas as falhas foram exploradas em ataques e inclua uma solução alternativa para exploração via solicitações CSF proxy, a Fortinet esclareceu que apenas a CVE-2024-55591 foi efetivamente utilizada em ataques.
A empresa explicou que clientes que já haviam atualizado seus sistemas seguindo as diretrizes do boletim FG-IR-24-535/CVE-2024-55591 estão automaticamente protegidos contra essa nova vulnerabilidade divulgada.
O título da matéria foi atualizado para refletir essas informações, e o artigo original segue abaixo.
A Fortinet alertou hoje que hackers estão explorando uma nova falha zero-day agora corrigida no FortiOS e no FortiProxy para comprometer firewalls Fortinet e invadir redes corporativas.
A exploração bem-sucedida dessa vulnerabilidade de autenticação (CVE-2025-24472) permite que hackers obtenham privilégios de superadministrador enviando solicitações CSF proxy maliciosamente manipuladas.
O problema de segurança afeta o FortiOS das versões 7.0.0 até 7.0.16, o FortiProxy das versões 7.0.0 até 7.0.19 e o FortiProxy 7.2.0 até 7.2.12. A Fortinet corrigiu a falha nas versões FortiOS 7.0.17 ou superior e FortiProxy 7.0.20/7.2.13 ou superior.
A Fortinet adicionou essa falha ao comunicado de segurança publicado no mês passado, que alertava os clientes sobre a exploração da vulnerabilidade zero-day CVE-2024-55591 no FortiOS e no FortiProxy, afetando as mesmas versões de software. Essa falha, já corrigida, permitia ataques enviando requisições maliciosas ao módulo websocket do Node.js.
De acordo com a Fortinet, hackers estão explorando essas vulnerabilidades para criar usuários administrativos ou locais aleatórios em dispositivos comprometidos, adicionando-os a novos e antigos grupos de usuários VPN SSL. Eles também foram observados modificando políticas de firewall e outras configurações, além de acessarem instâncias de VPN SSL com contas previamente estabelecidas para obter um túnel até a rede interna.
Embora a Fortinet não tenha fornecido detalhes adicionais sobre a campanha de ataques, a empresa de cibersegurança Arctic Wolf divulgou um relatório identificando os mesmos indicadores de comprometimento (IOCs). Segundo a pesquisa, firewalls Fortinet FortiGate com interfaces de gerenciamento expostas à Internet vêm sendo alvo de ataques desde pelo menos meados de novembro.
"A campanha envolveu acessos administrativos não autorizados às interfaces de gerenciamento dos firewalls, criação de novas contas, autenticação VPN SSL por meio dessas contas e várias outras mudanças de configuração", explicou o Arctic Wolf Labs.
"Embora o vetor de acesso inicial não esteja confirmado com certeza, uma vulnerabilidade zero-day é altamente provável. As organizações devem desativar urgentemente o acesso de gerenciamento do firewall em interfaces públicas o quanto antes."
A Arctic Wolf Labs também apresentou um cronograma das explorações em massa da CVE-2024-55591, dividindo o ataque em quatro fases distintas:
Escaneamento de vulnerabilidades: 16 a 23 de novembro de 2024
Reconhecimento: 22 a 27 de novembro de 2024
Configuração da VPN SSL: 4 a 7 de dezembro de 2024
Movimentação lateral dentro da rede: 16 a 27 de dezembro de 2024
"Devido a diferenças sutis nas técnicas e na infraestrutura entre as invasões, é possível que múltiplos indivíduos ou grupos hackers tenham participado dessa campanha, mas o uso do jsconsole foi um elemento comum em todos os casos", acrescentou.
A Arctic Wolf Labs notificou a Fortinet sobre os ataques em 12 de dezembro e recebeu confirmação do time de resposta a incidentes de segurança da empresa (PSIRT) cinco dias depois, informando que a atividade já era conhecida e estava sob investigação.
A Fortinet orientou os administradores que não puderem aplicar as atualizações de segurança imediatamente a desativarem as interfaces administrativas HTTP/HTTPS ou a restringirem os endereços IP que podem acessá-las por meio de políticas locais (local-in policies) como uma solução temporária.
Via - BC
コメント