CVE-2024-47575

Falha de ausência de autenticação (CWE-306) no daemon fgfmd do FortiManager, que gerencia o protocolo FGFM usado por FortiGates para se registrarem no gerenciador. Um atacante remoto não autenticado pode enviar requisições FGFM forjadas se passando por um dispositivo desconhecido e executar código ou comandos arbitrários no FortiManager. É explorada ativamente desde antes da divulgação pública, está no catálogo KEV da CISA e Fortinet confirmou uso em campanhas reais de exfiltração de dados.

O problema está no daemon fgfmd, responsável por processar o protocolo proprietário FGFM (FortiGate-to-FortiManager) na porta TCP 541. O daemon aceita requisições de registro de dispositivos desconhecidos sem validar adequadamente a autenticidade de quem está do outro lado — não há autenticação obrigatória antes de processar comandos que deveriam ser restritos a dispositivos já confiados/registrados. Isso é uma falha clássica de CWE-306 (missing authentication for critical function): a função crítica (registro de dispositivo + processamento de comandos subsequentes) não exige credencial válida como pré-condição.

O atacante controla o conteúdo da requisição FGFM forjada, incluindo número de série (SN) de dispositivo, o que permite se apresentar como um FortiGate legítimo ainda não cadastrado. Uma vez que o FortiManager aceita o registro de um dispositivo 'unknown', comandos subsequentes enviados através dessa sessão são processados com privilégio suficiente para exfiltrar arquivos e, no cenário mais severo, executar código no sistema.

A vulnerabilidade também afeta modelos antigos de FortiAnalyzer (1000E, 1000F, 2000E, 3000E, 3000F, 3000G, 3500E, 3500F, 3500G, 3700F, 3700G, 3900E) quando o recurso 'FortiManager on FortiAnalyzer' está habilitado (fmg-status enable) e há ao menos uma interface com o serviço fgfm ativo — ou seja, o vetor não é exclusivo de instalações FortiManager dedicadas.

O fornecedor não detalhou o payload exato usado para execução de código; a análise pública disponível (PoC e módulo Metasploit) foca no abuso do fluxo de registro não autenticado como ponto de entrada.

O vetor de ataque é rede: a porta TCP 541 (serviço fgfm) precisa estar acessível ao atacante, o que geralmente significa FortiManager exposto direta ou indiretamente à internet — configuração que existe em ambientes reais porque FortiGates remotos precisam se conectar ao FortiManager central. Não é necessária autenticação prévia nem qualquer credencial: o atacante simplesmente envia uma requisição FGFM forjada simulando um dispositivo (FortiGate) ainda não registrado, com um número de série arbitrário.

A Fortinet documentou exploração em campanha real cujo objetivo observado foi automatizar, via script, a exfiltração de arquivos do FortiManager contendo IPs, credenciais e configurações dos dispositivos gerenciados (FortiGates). Até o momento do advisory, a Fortinet não recebeu relatos de instalação de malware/backdoor em nível de sistema operacional nem de modificação do banco de dados ou dos próprios dispositivos gerenciados — mas isso reflete o que foi observado, não uma garantia de que o impacto máximo (RCE) não tenha sido demonstrado por outros pesquisadores, já que a descrição oficial da CVE fala em execução de código ou comandos arbitrários.

A CISA colocou a CVE no catálogo KEV em 23/10/2024 com prazo de mitigação até 13/11/2024, confirmando exploração ativa antes da correção. Existe módulo Metasploit e PoC pública, o que reduz a barreira técnica para replicar o ataque uma vez que o mecanismo é conhecido.

A correção definitiva é atualizar: FortiManager 7.6.0 para 7.6.1+; 7.4.0–7.4.4 para 7.4.5+; 7.2.0–7.2.7 para 7.2.8+; 7.0.0–7.0.12 para 7.0.13+; 6.4.0–6.4.14 para 6.4.15+; 6.2.0–6.2.12 para 6.2.13+. Para FortiManager Cloud: 7.4.1–7.4.4 para 7.4.5+; 7.2.1–7.2.7 para 7.2.8+; 7.0.1–7.0.12 para 7.0.13+; a linha 6.4 (todas as versões) não tem correção e exige migração para uma release corrigida. FortiManager Cloud 7.6 não é afetado.

Se a atualização imediata não for possível, a Fortinet lista paliativos reais, cada um com custo: (1) para FortiManager 7.0.12+, 7.2.5+ ou 7.4.3+ (mas não 7.6.0), habilitar 'set fgfm-deny-unknown enable' em system global, bloqueando registro de dispositivos desconhecidos — é o único workaround recomendado para FortiManager Cloud, mas tem efeito colateral: um FortiGate legítimo cujo SN não esteja na lista de dispositivos será impedido de se conectar mesmo com PSK correspondente, o que pode quebrar provisionamento automatizado; (2) para versões 7.2.0+, criar políticas local-in restringindo a porta 541 apenas aos IPs de FortiGates autorizados — exige inventário preciso de IPs de origem e mantém risco se algum IP confiável for spoofado ou comprometido; (3) para 7.2.2+, 7.4.0+ e 7.6.0+, usar certificado customizado (fgfm-ca-cert + fgfm-cert-exclusive enable) instalado também nos FortiGates, o que mitiga o problema desde que o atacante não consiga obter um certificado assinado por essa CA por outro canal. Para versões 6.2, 6.4 e 7.0.11 e anteriores, a orientação é atualizar primeiro para uma versão que suporte os workarounds e só então aplicá-los — ou seja, essas versões não têm paliativo isolado disponível.

Restringir a porta 541 na borda de rede (firewall perimetral) para aceitar apenas os IPs de FortiGates gerenciados é um controle compensatório adicional fora do próprio FortiManager. Não confiar apenas na presença de entradas de log de 'Unregistered device' como prova de compromisso: a Fortinet alerta que esses mesmos logs continuam aparecendo em sistemas já corrigidos, pois o patch não impede o registro de dispositivo desconhecido em si — impede que esse dispositivo não autenticado envie comandos de exploração depois de registrado.

Procurar nos logs do FortiManager entradas type=event, subtype=dvm com mensagens como 'Unregistered device localhost add succeeded' (operation='Add device') ou 'Edited device settings (SN ...)' com performed_on='localhost' e session_id=0 — a Fortinet lista números de série específicos observados em ataques reais (FMG-VMTM23017412, FMG-VMTM19008093, FGVMEVWG8YMT3R63) e arquivos em /tmp/.tm ou /var/tmp/.tm como possíveis indicadores. IPs de origem reportados em atividade maliciosa incluem 45.32.41.202, 104.238.141.143, 158.247.199.37, 45.32.63.2, 80.66.196.199, 198.199.122.22, 142.93.177.233, 195.85.114.78 e 172.232.167.68.

O próprio fornecedor alerta que esses logs de registro de dispositivo não autorizado não são, por si só, prova definitiva de compromisso: em sistemas já corrigidos, o mesmo padrão de log continua aparecendo, porque o patch não impede a tentativa de registro — impede a execução de comandos de exploração após o registro. Ou seja, presença desses logs sem outros indicadores (arquivos em /tmp, exfiltração de configuração) indica tentativa, não sucesso.