Missing authentication in fgfmsd

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.

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

Note: This is the only workaround recommended for use in FortiManager Cloud.

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

Important note: The two entries above may keep being logged even on an up-to-date, patched system (eg: FMG 7.4.5) - in which case they are not Indicators of Compromise anymore, but rather 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 which can legitimately happen in a deployment context), it is meant to prevent unauthorized devices to send exploit commands.

IP addresses

45.32.41.202
104.238.141.143
158.247.199.37
45.32.63.2
80.66.196.199
198.199.122.22
195.85.114.78 (Not observed by Fortinet, reported by Mandiant here)
172.232.167.68 (Not observed by Fortinet, reported by trusted third party)

Serial Number

FMG-VMTM23017412
FMG-VMTM19008093
FGVMEVWG8YMT3R63

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 a more detailed list, see Best Practices for Maintaining Secure Credentials

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

Managed Devices

Although we have not seen, or been made aware of devices managed by a compromised FortiManager that have been compromised, it should be assumed that this could occur. Therefore, we recommend that the credentials, such as passwords and user-sensitive data, of all managed devices be urgently changed, including those of the Managed FortiGates and FortiManager. This includes:
• Admin Users Accounts
• Certificate’s private key and password (In case of ssl offloading/deep inspection/ipsec auth)
• VPN Pre-Shared Keys
• Local user accounts
• TACACS Key
• LDAP / Active Directory Passwords
• RADIUS Secret Keys
• SNMP Secrets
• OSPF/BGP Neighbour Passwords
• Wireless SSID / Mesh Keys
• Passwords stored inside automation stitches
• PPPoE Passwords
• SMTP Passwords
• HA Pre-shared Keys Cluster Password

Timeline

2024-10-23: Initial publication
2024-10-23: Add FortiManager Cloud fixes
2024-10-24: Added workarounds to block the addition of unauthorized devices via syslog or FDS
2024-10-24: Added 195.85.114.78 in IoCs
2024-10-25: Added note about log entries IoCs
2024-10-28: Added link to "Best Practices for Maintaining Secure Credentials"
2024-10-28: Added note in workaround 1. (FMG Cloud recommended workaround)
2024-10-30: Added IoCs (4 IP addresses and 1 SN)
2024-11-04: Removed duplicate IP addresses
2024-11-05: Added 198.199.122.22 in IoCs
2024-11-07: Added recommendation for managed devices
2024-11-15: Updated the Serial Number IOCs section