(Vendor information) Missing authentication in fgfmsd
Created on 2024-10-25 07:11, updated on 2024-10-25 07:11, by Alexandre DulaunoyA missing authentication for critical function vulnerability [CWE-306] in FortiManager fgfmd daemon may allow a remote unauthenticated attacker to execute arbitrary code or commands via specially crafted requests.
Reports have shown this vulnerability to be exploited in the wild.
PSIRT | FortiGuard Labs 9–11 minutes Summary
A missing authentication for critical function vulnerability [CWE-306] in FortiManager fgfmd daemon may allow a remote unauthenticated attacker to execute arbitrary code or commands via specially crafted requests.
Reports have shown this vulnerability to be exploited in the wild. 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
Old FortiAnalyzer models 1000E, 1000F, 2000E, 3000E, 3000F, 3000G, 3500E, 3500F, 3500G, 3700F, 3700G, 3900E with the following feature enabled (FortiManager on FortiAnalyzer):
config system global set fmg-status enable end
and at least one interface with fgfm service enabled are also impacted by this vulnerability.
Workarounds
Upgrade to a fixed version or use one of the following workarounds, depending on the version you're running:
1- For FortiManager versions 7.0.12 or above, 7.2.5 or above, 7.4.3 or above (but not 7.6.0), prevent unknown devices to attempt to register:
config system global (global)# set fgfm-deny-unknown enable (global)# end
Warning: With this setting enabled, be aware that if a FortiGate's SN is not in the device list, FortiManager will prevent it from connecting to register upon being deployed, even when a model device with PSK is matching.
If FAZ features are enabled on FMG, block the addition of unauthorized devices 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- Alternatively, for FortiManager versions 7.2.0 and above, you may add local-in policies to whitelist the IP addresses of FortiGates that are allowed to connect.
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 7.2.2 and above, 7.4.0 and above, 7.6.0 and above it is also possible to use a custom certificate which will mitigate the issue:
config system global set fgfm-ca-cert set fgfm-cert-exclusive enable
end
And install that certificate on FortiGates. Only this CA will be valid, this can act as a workaround, providing the attacker cannot obtain a certificate signed by this CA via an alternate channel.
NB: For FortiManager versions 6.2, 6.4, and 7.0.11 and below, please upgrade to one of the versions above and apply the above workarounds.
Indicators of Compromise
The following are possible IoCs:
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)"
IP addresses
45.32.41.202 104.238.141.143 158.247.199.37 45.32.63.2 195.85.114.78 (Not observed by Fortinet, reported by Mandiant here)
Serial Number
FMG-VMTM23017412
Files
/tmp/.tm /var/tmp/.tm
Note that file IoCs may not appear in all cases.
Risk
The identified actions of this attack in the wild have been to automate via a script the exfiltration of various files from the FortiManager which contained the IPs, credentials and configurations of the managed devices.
At this stage, we have not received reports of any low-level system installations of malware or backdoors on these compromised FortiManager systems. To the best of our knowledge, there have been no indicators of modified databases, or connections and modifications to the managed devices.
Recovery
A FortiManager configuration backup file would not contain any OS or system-level file changes, as these files are not included in the archive. Therefore, taking a backup from a compromised system and then restoring it on a fresh or re-initialized one, would not carry over and re-introduce such low-level changes. When taking this approach, be aware that the data may have been tampered with. Careful review should be done to confirm configuration accuracy.
The methods below assume that the managed devices (FortiGates or other) contained in the backup have not been tampered with and that their configurations are reliable. Event log activity verification of the FortiGates should be reviewed starting from the date of the identified IoCs, to determine if there were any unauthorized access or configuration changes. Since data may have been exfiltrated from the FortiManager database, we recommend that the credentials, such as passwords and user-sensitive data, of all managed devices, be urgently changed.
For VM installations, recovery can be facilitated by keeping a copy of the compromised FortiManager in an isolated network with no Internet connection, as well as configuring it in offline mode and closed-network mode operation (see settings below). This system can be used to compare with the new one which will be set up in parallel.
config system admin setting set offline_mode enable end config fmupdate publicnetwork set status disable 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 taken 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 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
Meta
[
{
"tags": [
"vulnerability:information=remediation"
]
}
]