Executive Summary

On October 23^rd, 2024, Fortinet published an advisory regarding active exploitation of the FortiManager platform, a solution used to centrally manage Fortinet products. The advisory discloses a critical severity vulnerability, nicknamed FortiJump. The FortiGate to FortiManager (FGFM) protocol can be abused by an attacker to achieve unauthenticated, remote code execution (RCE) on FortiManager deployments, later pivoting to FortiManager managed devices. The FGFM protocol is designed to enable FortiManager connectivity when there is a need to span Fortinet management use cases over an internet connection. As such, Beazley Security expects vulnerable devices to be exposed to the public internet. 

This critical severity vulnerability is reported to be under active exploitation by malicious threat actors and Beazley Security is aware of this vulnerability being abused to compromise IT Managed Service Providers (MSPs) to gain access to client networks. While there is currently no publicly available Proof of Concept (POC) exploit code, Beazley security expects financially motivated threat actors to attempt reverse engineering Fortinet provided patches for this vulnerability and deploy weaponized exploits in the coming days. Beazley Security strongly recommends organizations leveraging Fortinet FortiManager solutions apply vendor supplied patches as soon as possible. If patching the affected system is not possible, organizations should apply the mitigations described in this document immediately. 

Affected Systems or Products

The table below highlights affected versions of FortiManager and available patches. 

Mitigations / Workarounds

Until patches can be applied, the following mitigation steps should be taken to temporarily mitigate this vulnerability. 

FortiManager versions 7.0.12 or above, 7.2.5 or above, 7.4.3 or above (but not 7.6.0) 

This is the Beazley Security recommended workaround, if available.  

The commands below prevent an unknown device from registering to the FortiManager deployment: 

config system global 

(global)# set fgfm-decy-unknown enable 

(global)# end 

FortiManager versions 7.2.0 and above 

If unable to apply the temporary mitigation described above, local-in policies can be added to allow only the IP addresses of managed FortiGate devices to connect to the FortiManager deployment: 

config system local-in-policy 

edit 1 

set action accept 

set dport 541 

set $src

next 

edit 2 

set dport 541 

next 

end 

FortiManager 7.2.2 and above, 7.4.0 and above, 7.6.0 and above 

Alternatively, organizations may choose to use a custom certificate-authority on the FortiManager and only allow Fortinet devices with certificates signed and trusted by that CA to register and connect to the FortiManager device. To do this, issue the following commands with a trusted CA certificate available: 

config system global 

set fgfm-ca-cert 

set fgfm-cert-exclusive enable 

end 

Once this command has been issued, you must also install certificates signed by the trusted certificate authority on managed Fortinet devices or they will no longer be able to connect to the FortiManager deployment. 

Patches

Patches are already available from Fortinet and should be applied immediately on vulnerable FortiManager deployments. 

Indicators of Compromise

Although in-depth technical specifics of the bug haven't been disclosed, Fortinet shared indicators of compromise (IoCs) that can be utilized for threat hunting or to verify suspected exploitation of this vulnerability in an incident response situation. 

The log entries below show a “rogue” Fortinet device being registered to the FortiManager deployment and then this vulnerability being abused to change settings on a separate and legitimately managed Fortinet device.  

Log Entries 

type=event,subtype=dvm,pri=information,desc="Device,manager,generic,information,log",user="device,...",msg="Unregistered device localhost add succeeded" device="localhost" adom="FortiManager" session_id=0 operation="Add device" performed_on="localhost" changes="Unregistered device localhost add succeeded"

type=event,subtype=dvm,pri=notice,desc="Device,Manager,dvm,log,at,notice,level",user="System",userfrom="",msg="" adom="root" session_id=0 operation="Modify device" performed_on="localhost" changes="Edited device settings (SN FMG-VMTM23017412)" 

Technical Details

Fortinet did not provide enough details for third parties to write proof-of-concept (PoC) exploits, however they did provide enough information for researchers to study and publish context around vulnerable components. 

A blog posted on DoublePulsar suggests that “by default, FortiManager allows any device, even with an unknown serial number, to register with FortiManager automatically and become a managed device". This appears to be a pre-requisite for exploit, as the actual vulnerable API endpoint is then reachable via an attacker-controlled, registered, rogue FortiGate device. 

Figure 1 : CVE-2024-47575 exploit process 

This attack has already been observed in the wild and was reportedly used to automate file exfiltration from victimized FortiManager devices. Exfiltrated data included confidential IPs, credentials, and device configurations. 

How Beazley Security is responding

Beazley Security is monitoring client perimeter devices discovered by our Attack Surface Management Solution, Karma, to identify potentially impacted devices and support organizations in remediation of any issues found.

Sources

• 

  https://www.fortiguard.com/psirt/FG-IR-24-423 

• 

  https://doublepulsar.com/burning-zero-days-fortijump-fortimanager-vulnerability-used-by-nation-state-in-espionage-via-msps-c79abec59773