What Happened
On October 23, 2024, FortiGuard Labs released a PSIRT advisory detailing a critical vulnerability in FortiManager fgfmd daemon which “may allow a remote unauthenticated attacker to execute arbitrary code or commands via specially crafted requests.” This vulnerability has been recorded by NVD and assigned the CVE-ID CVE-2024-47575 and carries with it a critical severity CVSSv3 score of 9.8.
This vulnerability has been unofficially named “FortiJump” by researcher Kevin Beaumont, who was among the first to raise concerns that a potentially high risk vulnerability was on the horizon. Ten days after Beaumont’s initial post on the social media platform, Mastodon, FortiGuard Labs released their own official statement and not only confirmed the existence of this vulnerability, but also revealed they had evidence that it is actively being exploited in the wild.
This vulnerability is the result of an insecure implementation of how managed devices are registered with FortiManager. By default, any device is allowed to register with FortiManager as a managed device. Malicious actors can use this to register their own rogue device and exploit FortiManager to access managed FortiGate firewalls and exfiltrate or make changes to configuration files, credentials, or other sensitive data.
What That Means
Administrators who manage FortiManager services should patch as soon as possible. The exploitation seems relatively trivial but the potential impact is extreme, considering this vulnerability provides access to devices used to protect and secure networks. Failure to patch quickly could result in threat actors gaining access to company networks and configuring services or accounts for backdoor access and persistence. Exfiltrated configuration files, users, and passwords can be saved by threat actors for future reconnaissance and attacks.
While no proof of concept code has been released as of the writing of this article (October 24, 2024), active exploitation has been seen in the wild.
Who’s Impacted
The following table and notes have been directly lifted from the FortiGuard PSIRT
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 is also impacted by this vulnerability.
How Would I Know and What Should I Do
Blumira has released a new detection to all of our FortiNet customers. Titled, “FortiGate: FortiManager CVE-2024-47575 Missing authentication in fgfmsd”, this detection monitors for initial steps taken by a threat actor to register their rogue device with FortiManager. If you are already shipping your FortiNet device logs to Blumira, this rule will automatically be deployed and enabled for you. We have also retroactively scanned the last 30 days of customer FortiNet logs to verify no compromise has occurred before we were able to develop and release the detection (should we identify any suspicious behavior, our Security Operations team will reach out).
Several indicators of compromise (IOC) have been released by the FortiGuard Labs team:
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
Serial Number
FMG-VMTM23017412
Files
/tmp/.tm
/var/tmp/.tm
Workarounds
Additionally, the FortiGaurd Labs team has advised on several workarounds if a patch cannot be applied immediately - note that for older versions (6.2, 6.4, and 7.0.11 and below), it is advised to apply the patch and workarounds:
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.
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.
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.
When Will it be Fixed?
Patches are available and have been released by FortiNet. Please refer to the table above to see if you are affected.
How Blumira Can Help
Blumira continues to actively monitor this issue, and look for any additional ways that we can detect any stage of exploitation of these vulnerabilities.
If you are an MSP and not already using Blumira, please submit a request for a “free for internal use” NFR account.
The Blumira Free SIEM is easy to deploy; IT and security teams can start seeing immediate security value for their organizations.
Jake Ouellette
Jake is an Incident Detection Engineer at Blumira, where he contributes to research and design efforts to continuously improve the detection, analysis, and disruption capabilities of the Blumira platform.
More from the blog
View All PostsFortinet SSL-VPN RCE Vulnerability (CVE-2022-40684) Exploited In The Wild
Read MoreOpenSSL Vulnerability: What You Should Know
Read MoreSonicWall Advisory Reveals Two Unauthenticated Remote Code Execution Vulnerabilities
Read MoreSubscribe to email updates
Stay up-to-date on what's happening at this blog and get additional content about the benefits of subscribing.