Understanding Zero-Day Vulnerabilities: Dissecting CVE-2024-47575 in FortiManager

In the cybersecurity world, zero-day vulnerabilities represent a significant threat due to their unexpected nature and the lack of existing defenses. A zero-day exploit takes advantage of an undiscovered or unpatched vulnerability, giving attackers the opportunity to exploit it before developers can issue fixes. Recently, a critical zero-day vulnerability—tracked as CVE-2024-47575—was publicly disclosed in FortiManager, a centralized management platform used to control Fortinet’s security appliances.

This zero-day, dubbed “FortiJump” by cybersecurity researcher Kevin Beaumont, enabled attackers to breach FortiManager systems, accessing sensitive files that contained device configurations, IP addresses, and credentials, further exacerbating the potential damage.

The CVE-2024-47575 Vulnerability Breakdown

The vulnerability in question stems from a missing authentication mechanism for critical functions within the FortiManager fgfmd daemon. Assigned a Common Weakness Enumeration (CWE-306) category, this flaw allows unauthenticated attackers to execute arbitrary commands via specially crafted requests. It received a severity rating of 9.8/10, indicating its criticality.

Fortinet’s advisory (FG-IR-24-423) provides the technical breakdown, explaining that the flaw lies in the FortiGate to FortiManager (FGFM) protocol, which is used to register and manage FortiGate devices from a centralized FortiManager server. The vulnerability allows attackers to bypass FGFM’s API authorization and execute arbitrary commands on the server, which in turn grants them control over managed FortiGate devices.

Exploitation in the Wild

This zero-day vulnerability has already been exploited by attackers in the wild. Attackers must first obtain a valid certificate from any compromised or owned Fortinet device, including FortiManager Virtual Machines (VMs), to exploit this flaw. Once the certificate is acquired, attackers can initiate an SSL tunnel and interact with the FGFM API. This tunnel allows unauthorized commands to be sent to the FortiManager system, thereby granting attackers the ability to execute code, retrieve sensitive information, and manipulate network configurations.

This particular aspect of the flaw, requiring the extraction of a valid certificate, illustrates how attackers leverage known vulnerabilities to infiltrate systems that rely on certificate-based authentication. The challenge lies in not just bypassing the initial authentication but also in traversing through the network to gain access to sensitive corporate infrastructure.

Real-World Impact and Attack Methodology

The attacks exploiting CVE-2024-47575 were used to exfiltrate sensitive data from FortiManager servers. According to Fortinet, compromised systems revealed files containing critical data like device configurations, IP addresses, and credentials. With this data, attackers could gain a more comprehensive understanding of their targets, opening up avenues for additional attacks on FortiGate devices managed by FortiManager.

This vulnerability is particularly concerning in environments managed by Managed Service Providers (MSPs), as attackers who exploit this flaw can effectively use it to pivot within a corporate network. The exploitation model follows a lateral movement pattern:

  1. Compromise a FortiGate device using valid certificates.
  2. Exploit the FGFM protocol to gain unauthorized access to the FortiManager API.
  3. From FortiManager, traverse to other managed FortiGate firewalls and downstream networks.

This form of attack could create a daisy-chaining effect where multiple devices and networks under the control of FortiManager are vulnerable to compromise, affecting both direct clients and MSP downstream customers.

Mitigation Measures

To mitigate the exploitation of CVE-2024-47575, Fortinet has released patches for the affected versions of FortiManager, urging users to upgrade to versions that have fixed the vulnerability. However, patch deployment may not be immediate for all organizations, prompting the need for workarounds:

  • Denying Unknown Devices: Use the command set fgfm-deny-unknown enable to prevent unauthorized devices from registering to the FortiManager.
  • Custom Certificates: Organizations should create custom certificates for SSL tunnels to limit unauthorized access.
  • IP Whitelisting: Limiting which IP addresses are allowed to connect to FortiManager servers reduces the attack surface.

 

Despite these mitigations, the risk remains if attackers have already obtained valid certificates, meaning proactive detection and patching are critical.

The flaw impacts the following FortiManager versions:

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

At this time, only FortiManager versions 7.2.8 and 7.4.5 have been released

Indicators of Compromise (IoCs)

To help organizations detect if they have been targeted, Fortinet has shared several Indicators of Compromise (IoCs):

  • Attackers added rogue devices under the name “localhost” in FortiManager’s Unregistered Devices section.
  • Log entries showing commands issued to register these rogue devices:

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”

  • Log entries revealing the modification of device settings:

type=event,subtype=dvm,pri=notice,desc=”Device,Manager,dvm,log,at,notice,level”,user=”System”,userfrom=””,msg=”” adom=”root” session_id=0 opera,on=”Modify device” performed_on=”localhost” changes=”Edited device settings (SN FMG-VMTM23017412)”

The serial number FMG-VMTM23017412 is a known rogue device identifier in these attacks.

A Growing Trend of Fortinet Vulnerabilities

This is not the first time Fortinet has faced criticism for its handling of vulnerabilities. In previous incidents, such as the CVE-2022-42475 and CVE-2023-27997 vulnerabilities, Fortinet privately disclosed critical issues to customers without immediately making public announcements about active exploitation. This private disclosure policy has led to frustration among customers, as some did not receive the notification emails in a timely manner, leaving them vulnerable to ongoing attacks.