HomeAlerts & Advisories

Critical Vulnerability in FortiManager (CVE-2024-47575)

Executive Summary

On October 23rd, 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 / Products

The following are the affected versions of FortiManager and available patches.

FortiManager Version        Affected Sub Versions       Patched Versions

  • FortiManager 7.6                7.6.0                                 Upgrade to 7.6.1 or above
  • FortiManager 7.4               7.4.0 through 7.4.4       Upgrade to 7.4.5 or above
  • FortiManager 7.2               7.2.0 through 7.2.7        Upgrade to 7.2.8 or above
  • FortiManager 7.0               7.0.0 through 7.0.12       Upgrade to 7.0.13 or above
  • FortiManager 6.4               6.4.0 through 6.4.14     Upgrade to 6.4.15 or above
  • FortiManager 6.2               6.2.0 through 6.2.12     Upgrade to 6.2.13 or above
  • FortiManager Cloud 7.6     Not affected                 Not Applicable
  • FortiManager Cloud 7.4     7.4.1 through 7.4.4         Upgrade to 7.4.5 or above
  • FortiManager Cloud 7.2     7.2.1 through 7.2.7          Upgrade to 7.2.8 or above
  • FortiManager Cloud 7.0     7.0.1 through 7.0.12         Upgrade to 7.0.13 or above
  • FortiManager Cloud 6.4     6.4 all versions              Migrate to a fixed release

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 (Note: this should be the source IPs that are allowed to connect to the FortiManager appliance)
  • 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.

Version                              Patched Versions

FortiManager 7.6                7.6.1 and above

FortiManager 7.4                7.4.5 and above

FortiManager 7.2                7.2.8 and above

FortiManager 7.0                7.0.13 and above

FortiManager 6.4                6.4.15 and above

FortiManager 6.2                6.2.13 and above

FortiManager Cloud 7.6       Not Applicable

FortiManager Cloud 7.4       7.4.5 and above

FortiManager Cloud 7.2       7.2.8 and above

FortiManager Cloud 7.0       7.0.13 and above

FortiManager Cloud 6.4       Migrate to a fixed release

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.

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 “rouge” 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)"

How Beazley Security is Responding

Beazley Security is monitoring client perimeter devices through our Karma product and actively threat hunting on behalf of Beazley Security MDR clients to identify impacted devices and support organizations in remediation of any issues found.

Sources

‍

‍

Download PDF

Aware of an incident impacting your industry? Let us know:

Report an incident