Overview of the FortiManager API Vulnerability

Recently, a critical API vulnerability in FortiManager (CVE-2024-47575) was disclosed. Certain threat actors exploited it in the wild to steal sensitive information containing configurations, IP addresses, and credentials used by managed devices. In advanced notification emails, Fortinet warned its users of the vulnerability and mitigation steps.

The vulnerability has a critical severity rating of 9.8 out of 10. This flaw could enable an attacker to execute arbitrary code or commands due to missing authentication in the fgfmd daemon.

The FortiGate to FortiManager Protocol (FGFM) enables customers to deploy FortiGate firewall devices and register them with a remote FortiManager server, allowing centralized management of these devices from a single location.

The FGFM API was vulnerable to authentication bypass, allowing unauthenticated attackers to execute commands, retrieve sensitive information, and compromise the environment.

Mandiant observed that a new threat cluster tracked as UNC5820 exploited this vulnerability starting on June 27, 2024. The threat actor extracted configuration data from FortiGate devices managed by the exploited FortiManager. The data consists of configuration settings of the managed devices, sensitive information about the users, and their FortiOS256-hashed passwords.

There is no evidence that the threat actor leveraged this vulnerability. Additionally, there is no evidence to prove that the threat actor utilized the obtained configuration data to take control of the environment.

FortiManager API Vulnerability Details

As reported by Mandiant, multiple FortiManager instances received inbound connections from the IP address 45[.]32[.]41[.]202 on port TCP/541. Moreover, the file system recorded the staging of various Fortinet configuration files in a Gzip-compressed archive called /tmp/.tm 

This archive has the following content:

Filename	Description
/var/dm/RCS	Folder containing configuration files of managed FortiGate devices
/var/dm/RCS/revinfo.db	Database containing additional information on the managed FortiGate devices
/var/fds/data/devices.txt	Contains a list of FortiGate serials and their corresponding IP addresses
/var/pm2/global.db	Global database that contains object configurations, policy packages, and header and footer sensor configuration for IPS
/var/old_fmversion	Contains current FortiManager version, build, and branch information

Another exploitation attempt took place on September 23, 2024. It followed the same pattern as the previous attempt.

Timestamp	Description	Size
2024-06-27 12:44:04	/tmp/.tm (File creation)	Unknown
2024-06-27 12:44:11	Outbound traffic to 195[.]85[.]114[.]78:443	1,819,425 bytes
2024-09-23 11:31:12	/tmp/.tm (File modification)	1,772,650 bytes
2024-09-23 11:31:19	Outbound traffic to 104[.]238[.]141[.]143:443	1,822,968 bytes

In the second exploitation attempt, the threat actor’s device was registered to the targeted FortiManager. Below is a listing of the threat actor’s FortiManager in the Global Objects Database.

After the successful exploitation, the threat actor’s Fortinet device appeared in the FortiManager console along with its Serial Number and IP Address.

Indicators of Compromise

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)"

Important note: The two entries above may keep being logged even on an up-to-date, patched system (e.g., FMG 7.4.5) - in which case they are not Indicators of Compromise anymore but indicators of a (failed) attempt to compromise the system. Indeed, the fix is not meant to prevent adding unauthorized devices (which these log entries are indicative of and can legitimately happen in a deployment context); it is intended to prevent unauthorized devices from sending exploit commands.

IP addresses

45.32.41.202

104.238.141.143

158.247.199.37

45.32.63.2

195.85.114.78

Files

/tmp/.tm

/var/tmp/.tm

Other Indicators

FMG-VMTM23017412 - Malicious Device ID

[email protected] - Email address used by the threat actor

Purity Supreme - Observed in the tmp file

Workarounds to the FortiManager API Vulnerability

To address the issue, upgrade to a fixed version or use one of the following workarounds, depending on your FortiManager version:

1. For FortiManager Versions 7.0.12 or Above, 7.2.5 or Above, 7.4.3 or Above (excluding 7.6.0)

Prevent unknown devices from attempting to register:

config system global
(global)# set fgfm-deny-unknown enable
(global)# end

Warning: With this setting enabled, FortiManager will block any FortiGate whose serial number is not in the device list from connecting to register after deployment, even if a model device with PSK matches.

If FortiAnalyzer (FAZ) features are enabled on FortiManager, block unauthorized devices from being added via syslog:

conf system global
set detect-unregistered-log-device disable
end

If FortiGate Updates or Web Filtering are enabled, block the addition of unauthorized devices via FDS:

conf fmupdate fds-setting
set unreg-dev-option ignore
end

2. For FortiManager Versions 7.2.0 and Above

Use local-in policies to allow IP addresses of authorized FortiGates. For example:

config system local-in-policy
edit 1
set action accept
set dport 541
set src <IP_address>
next
edit 2
set dport 541
next
end

3. For Versions 7.2.2 and Above, 7.4.0 and Above, 7.6.0 and Above

Use a custom certificate to mitigate the issue:

config system global
set fgfm-ca-cert <certificate_name>
set fgfm-cert-exclusive enable
end

Recovery Methods

Option 1 – Recommended Recovery Action

This method ensures that the FortiManager configuration was not tampered with. It will require database rebuilding or device configuration resynchronizations at the Device and Policy Package ADOM levels.

• Installing a fresh FortiManager VM or re-initializing a hardware model and adding/discovering the devices.

• Installing a fresh FortiManager VM or re-initializing a hardware model and restoring a backup before the IoC detection.

Option 2 – Alternative Recovery Action

This method provides a quick recovery, where partial or no database rebuilding/resynchronization is required. It requires that you manually verify the accuracy of the currently running FortiManager configuration. 

• Installing a fresh FortiManager VM or re-initializing a hardware model and restoring/copying components or configuration sections from a compromised FortiManager.

• Installing a fresh FortiManager VM, or re-initializing a hardware model, and restoring a backup from a compromised FortiManager.

For more info on data configuration and synchronization procedures: https://community.fortinet.com/t5/FortiManager/Technical-Tip-FortiManager-data-configuration-and/ta-p/351748

Version	Affected	Solution
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