Fortinet Zero-Day dá Privilégios de Superadministrador

Empresa corrigiu a falha de segurança, que foi responsável por uma série de ataques relatados no início deste mês que comprometeram os produtos FortiOS e FortiProxy expostos à Internet pública.

A Fortinet corrigiu uma falha de desvio de autenticação de dia zero explorada ativamente que afeta seus produtos FortiOS e FortiProxy, que os invasores têm explorado para obter acesso superadministrativo a dispositivos para realizar atividades nefastas, incluindo violação de redes corporativas.

A Fortinet caracterizou a falha, classificada como crítica e rastreada como CVE-2024-55591 (CVSS 9.6), como um “desvio de autenticação usando um caminho alternativo ou vulnerabilidade de canal” que “pode permitir que um invasor remoto obtenha privilégios de superadministrador por meio de solicitações criadas para Node.js módulo websocket”, de acordo com um comunicado de segurança do FortiGuard Labs na semana passada.

A Fortinet observou os agentes de ameaças realizando várias operações maliciosas explorando a falha. Essas atividades incluíam: criar uma conta de administrador no dispositivo com um nome de usuário aleatório; criar uma conta de usuário local no dispositivo com um nome de usuário aleatório; criar um grupo de usuários ou adicionar um usuário local a um grupo de usuários SSL VPN existente; adicionar e/ou alterar outras configurações, incluindo política de firewall e/ou endereço de firewall; e fazer login na VPN SSL para obter um túnel para a rede interna.

A Fortinet recomendou que os clientes que usam produtos afetados sigam o caminho de atualização recomendado em seu site para mitigar a falha. Ele também ofereceu opções alternativas em seu comunicado.

Primeiros sinais de exploração de dia zero da Fortinet

Os primeiros sinais de que algo estava errado surgiram no início deste mês, quando pesquisadores da Arctic Wolf revelaram que uma falha de dia zero provavelmente era a culpada por uma série de ataques recentes a dispositivos de firewall FortiGate com interfaces de gerenciamento expostas na Internet pública. Os invasores tinham como alvo os dispositivos para criar logins administrativos não autorizados e fazer outras alterações de configuração, criar novas contas e realizar autenticação SSL VPN.

A Fortinet informou discretamente sua base de clientes sobre o problema antes de revelar o patch e a extensão da situação no final da semana passada; essa revelação discreta é como a Arctic Wolf ficou sabendo disso, de acordo com uma postagem no blog analisando a falha da watchTowr Labs publicada em 27 de janeiro. No entanto, os pesquisadores de segurança ainda não sabiam exatamente qual era a falha ou o que a exploração implicava.

Isso ficou mais claro agora. A falha residia na funcionalidade jsconsole, que é um recurso de interface gráfica do usuário (GUI) para executar comandos da interface de linha de comando (CLI) dentro da interface de gerenciamento do FortiOS, de acordo com o watchTowr Labs. “Especificamente, a fraqueza nessa funcionalidade permitiu que os invasores adicionassem uma nova conta administrativa”, de acordo com o post.

Jsconsole é um console da Web baseado em WebSocket para a CLI dos dispositivos Fortinet afetados. “Esta CLI é todo-poderosa, pois é efetivamente a mesma que a CLI real fornecida que é usada por administradores legítimos para configurar o dispositivo”, de acordo com o watchTowr Labs. Portanto, se um invasor obtiver acesso ao console Web, o próprio dispositivo deverá ser considerado comprometido.

Os pesquisadores mergulharam profundamente na vulnerabilidade e descobriram que na verdade era uma cadeia de problemas combinados em uma vulnerabilidade crítica que permitia que os invasores seguissem quatro etapas principais para obter acesso super administrativo.

Essas etapas são: criar uma conexão WebSocket a partir de uma solicitação HTTP pré-autenticada; usar um parâmetro especial local_access_token ignorar verificações de sessão; explorar uma condição de corrida na CLI do WebSocket Telnet para enviar autenticação antes que o servidor o faça; e escolher o perfil de acesso que um invasor deseja assumir, que no caso da prova de conceito dos pesquisadores era se tornar um superadministrador.

Mitigação e proteção contra CVE-2024-55591

Os dispositivos Fortinet são um alvo popular para agentes de ameaças, com vulnerabilidades encontradas nos produtos muitas vezes amplamente exploradas para violar não apenas dispositivos, mas também atuar como um ponto de entrada para atacar redes corporativas.

As organizações que usam os dispositivos afetados pela falha são aconselhadas a seguir o caminho de atualização apropriado ou aplicar a solução alternativa fornecida pela Fortinet.

A Fortinet também observou em seu comunicado que um invasor geralmente precisaria saber o nome de usuário de uma conta de administrador para realizar o ataque e fazer login no CLE para explorar a falha. “Portanto, ter um nome de usuário não padrão e não adivinhável para contas de administrador oferece alguma proteção e é, em geral, uma prática recomendada”, de acordo com o comunicado.

No entanto, acrescentou a empresa, como o WebSocket visado não é um ponto de autenticação, os invasores ainda têm a possibilidade de forçar o nome de usuário para explorar a falha.

Resumo CVE-2024-55591

Uma vulnerabilidade de desvio de autenticação usando um caminho alternativo ou canal [CWE-288] que afeta o FortiOS e o FortiProxy pode permitir que um invasor remoto obtenha privilégios de superadministrador por meio de solicitações criadas para Node.js módulo websocket.
Observe que os relatórios mostram que isso está sendo explorado na natureza.

Versão	Afetado	Solução
ForteiOS 7.6	Não afetado	Não aplicável
ForteiOS 7.4	Não afetado	Não aplicável
ForteiOS 7.2	Não afetado	Não aplicável
ForteiOS 7.0	7.0.0 até 7.0.16	Atualize para 7.0.17 ou superior
ForteiOS 6.4	Não afetado	Não aplicável
FortiProxy 7.6	Não afetado	Não aplicável
FortiProxy 7.4	Não afetado	Não aplicável
FortiProxy 7.2	7.2.0 até 7.2.12	Atualize para 7.2.13 ou superior
FortiProxy 7.0	7.0.0 até 7.0.19	Atualize para 7.0.20 ou superior
FortiProxy 2.0	Não afetado	Não aplicável

Siga o caminho de atualização recomendado usando nossa ferramenta em: https://docs.fortinet.com/upgrade-tool

IoCs

As seguintes entradas de log são possíveis IOCs:

- Seguindo o log de atividades de login com scrip aleatório e dstip:
  type=”event” subtype=”system” level=”information” vd=”root” logdesc=”Login do administrador bem-sucedido” sn=”1733486785″ user=”admin” ui=”jsconsole” method=”jsconsole” srcip=1.1.1.1 dstip=1.1.1.1 action=”login” status=”success” reason=”none” profile=”super_admin” msg=”Administrador administrador conectado com sucesso a partir do jsconsole”

- Seguindo o log de criação do administrador com nome de usuário e IP de origem aparentemente gerados aleatoriamente:
  type = “event” subtype = “system” level = “information” vd = “root” logdesc = “Atributo de objeto configurado” user = “admin” ui = “jsconsole (127.0.0.1)” action = “Adicionar” cfgtid = 1411317760 cfgpath = “system.admin” cfgobj = “vOcep” cfgattr = “senha [*] accprofile [super_admin] vdom [root]” msg = “Adicionar system.admin vOcep”

- Os seguintes endereços IP foram encontrados principalmente usados por invasores nos logs acima:
  1.1.1.1
  127.0.0.1
  2.2.2.2
  8.8.8.8
  8.8.4.4

Observe que os parâmetros IP acima não são os endereços IP de origem reais do tráfego de ataque, eles são gerados arbitrariamente pelo invasor como um parâmetro. Por causa disso, eles não devem ser usados para nenhum bloqueio.
Observe também que sn e cfgtid não são relevantes para o ataque.

As operações realizadas pelo Agente da Ameaça (TA) nos casos que observamos foram parte ou todos os itens abaixo:
– Criação de uma conta de administrador no dispositivo com nome de usuário aleatório- Criação de uma conta de usuário local no dispositivo com nome de usuário aleatório- Criação de um grupo de usuários ou adição do usuário local acima a um grupo de usuários sslvpn existente- Adicionar/alterar outras configurações (política de firewall, endereço de firewall, …)

– Fazer login no sslvpn com os usuários locais adicionados acima para obter um túnel para a rede interna.

O usuário Admin ou Local criado pelo TA é gerado aleatoriamente. por exemplo:

Gujhmk
Ed8x4k
G0xgey
Pvnw81
Alg7c4
Ypda8a
Kmi8p4
1A2N6T
8ah1t6
M4ix9f
… etc…

Além disso, o TA foi visto usando os seguintes endereços IP:

45.55.158.47 [endereço IP mais usado]
87.249.138.47
155.133.4.175
37.19.196.65
149.22.94.37

Solução alternativa

Desativar interface administrativa HTTP/HTTPS
OU
Limite os endereços IP que podem acessar a interface administrativa por meio de políticas locais:
Endereço do firewall de configuração Editar “my_allowed_addresses”
Definir fim da sub-rede

Em seguida, crie um Grupo de Endereços:

config firewall addrgrp
edit “MGMT_IPs”
set member “my_allowed_addresses”
end

Crie o Local na Política para restringir o acesso apenas ao grupo predefinido na interface de gerenciamento (aqui: port1):

config firewall local-in-policy

edit 1
set intf port1
set srcaddr “MGMT_IPs”
set dstaddr “all”
set action accept
set service HTTPS HTTP
set schedule “always”
set status enable
next

edit 2
set intf “all”
set srcaddr “all”
set dstaddr “all”
set action deny
set service HTTPS HTTP
set schedule “always”
set status enable
end

Se estiver usando portas não padrão, crie o objeto de serviço apropriado para acesso administrativo à GUI:

config firewall service custom
edit GUI_HTTPS
set tcp-portrange 443
next

edit GUI_HTTP
set tcp-portrange 80
end

Use esses objetos em vez de “HTTP HTTPS” nas políticas de entrada local 1 e 2 abaixo.
Observe que o recurso trusthost atinge o mesmo que as políticas de entrada local acima somente se todos os usuários da GUI estiverem configurados com ele. Portanto, as políticas de entrada local acima são a solução preferencial.
Observe também que um invasor precisa saber o nome de usuário de uma conta de administrador para realizar o ataque e fazer login na CLI. Portanto, ter um nome de usuário não padrão e não adivinhável para contas de administrador oferece alguma proteção e é, em geral, uma prática recomendada. Lembre-se, no entanto, de que o websocket de destino não é um ponto de autenticação, nada impediria um invasor de forçar o nome de usuário.
Entre em contato com o suporte ao cliente para obter assistência.

Linha do tempo

2025-01-14: Formato
2025-01-15: Adicionada prática
recomendada de nome de usuário de conta de administrador não padrão 2025-01-15: Esclarecido que os endereços IP “sob controle do invasor” significam que eles são gerados arbitrariamente pelo invasor
2025-01-21: Adicionadas informações
do pacote IPS 2025-01-24: Informações do pacote IPS removidas

Fonte: DarkReading & Fortiguard

Veja também:

Fortinet Zero-Day dá Privilégios de Superadministrador

Primeiros sinais de exploração de dia zero da Fortinet