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
0qsc137p@justdefinition.com – 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
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
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 |