CVE-2024-47575: FortiManager Missing Authentication Zero-Day Vulnerability Explained

In October 2024, FortiManager appliances were reported to be under attack due to the exploitation of CVE-2024-47575 / FG-IR-24-423 [1], a vulnerability classified as CWE-306 (Missing Authentication for Critical Function). This flaw arises from weak authentication enforcement in the fgfmsd service, which manages communication between FortiManager and FortiGate devices. By sending specially crafted requests, attackers can gain control of the FortiManager device and execute arbitrary commands.

While the vulnerability primarily affects FortiManager, attackers can exfiltrate sensitive data, including hashed passwords, from managed FortiGate devices, increasing the risk of lateral movement and broader network breaches. In fact, a newly identified threat group, UNC5820, was observed exploiting this vulnerability as early as June 27, 2024 [2], stealing configuration data and FortiOS256-hashed passwords, potentially enabling further attacks across Fortinet devices and enterprise environments.

HOW TO SIMULATE THIS THREAT FOR FREE - NO SETUP

The CVE-2024-47575 Vulnerability Explained

CVE-2024-47575 is a critical vulnerability in the FortiManager platform, specifically affecting its fgfmsd daemon. Classified under CWE-306, it stems from insufficient authentication for management functions in the fgfmsd service, which handles communication between FortiManager and FortiGate devices.

This flaw allows a remote attacker to send crafted requests, bypass access controls, and execute arbitrary commands on the FortiManager system, potentially compromising the network.

Timeline of the CVE-2024-47575 Exploitation 

The first confirmed instance of exploitation occurred on June 27, 2024, when multiple FortiManager devices received inbound connections from the IP address 45[.]32[.]41[.]202 over the default service port TCP/541 [2]. This activity triggered the creation of a Gzip-compressed archive, named /tmp/.tm, containing critical configuration data from the compromised FortiManager.

Staging and Exfiltration of Configuration Data

The malicious archive /tmp/.tm included various sensitive files, such as:

• FortiGate Configuration Files: Contained within the directory /var/dm/RCS, these files store the configurations of all FortiGate devices managed by the FortiManager.

• Device Metadata: The revinfo.db file, found in the same directory, holds additional metadata about managed FortiGate devices, likely detailing their state, version, and other operational parameters.

• Device Listings: The devices.txt file in /var/fds/data/ contains a list of FortiGate serial numbers and their corresponding IP addresses, providing the attacker with an overview of the devices in the network.

• Global Configuration Database: The global.db file in /var/pm2/ stores critical network-wide configurations, including policy packages and IPS settings, giving the attacker further insight into the enterprise's security infrastructure.

• Version Information: The old_fmversion file holds information about the current FortiManager version, its build, and branch, which can be useful for attackers to tailor further attacks based on specific vulnerabilities in different software versions.

Shortly after this file staging, outbound traffic was detected, likely corresponding to the exfiltration of the archived configuration data. In the first exploitation instance, the data was sent to the IP address 195[.]85[.]114[.]78 over port 443, just seconds after the creation of the /tmp/.tm archive. 

The size of the outbound data closely matched that of the archive, indicating that the staged files were transmitted to the attacker's infrastructure.

Exploitation and Persistence

On September 23, 2024, a second exploitation attempt mirrored the initial attack, with modifications made to the archive file /tmp/.tm and outbound traffic sent to 104[.]238[.]141[.]143 over port 443. The file sizes and traffic patterns remained consistent with the earlier attempt.

A key difference in this attack was the successful registration of an unauthorized device in the FortiManager Global Objects database, which stores critical information about managed devices. The attacker exploited the vulnerability to add a rogue device with serial number FMG-VMTM23017412 and IP address 48[.]32[.]41[.]202. 

The following SQL query showcases the attacker’s device being listed:

SELECT oid, name, sn, platform_str, ip, mgmt_if,     datetime(last_checked, 'unixepoch') as last_checked,     datetime(first_tunnel_up, 'unixepoch') as first_tunnel_up FROM device WHERE name = 'localhost';

This registration allowed the attacker to interact with the FortiManager system as though they were a legitimate device, providing them with a persistent foothold in the network.

Indicators of Compromise

IoCs include the rogue device being listed in /fds/data/unreg_devices.txt, with its serial number and IP address recorded (as shown above). Additional files, such as /fds/data/subs.dat and /subs.dat.tmp, contained more details about the attack, including disposable email addresses and fake company information tied to the attacker’s activities.

Memory Artifacts and Network Activity

Further analysis of the compromised FortiManager device's memory uncovered a JSON blob containing references to the unauthorized device’s serial number and IP address, as well as a field called "first_tunnel_up", which indicated when the attacker first established a tunnel or communication channel to the compromised system. This timestamp confirmed that the attacker had maintained ongoing access to the device.

Affected Products and Versions from the CVE-2024-47575 Vulnerability

The advisory released by FortiNET has listed the affected products and the solutions available [1]. 

Version	Affected versions	Fixed versions
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

Older FortiAnalyzer models, including 1000E, 1000F, 2000E, 3000E, 3000F, 3000G, 3500E, 3500F, 3500G, 3700F, 3700G, and 3900E, are also affected by this vulnerability if they have the FortiManager on FortiAnalyzer feature enabled [1]:

config system global set fmg-status enable end

Additionally, the vulnerability applies if at least one interface has the fgfm service enabled.

Mitigation Strategies & Workaround for CVE-2024-47575

To mitigate the risk posed by CVE-2024-47575, it is recommended to upgrade to a fixed version listed above. However, if upgrading is not immediately possible, you can apply the following workarounds depending on your current FortiManager version [1]:

1. Deny Unknown Devices (For FortiManager versions 7.0.12+, 7.2.5+, 7.4.3+ but not 7.6.0)

This workaround prevents unauthorized or unknown devices from attempting to register with FortiManager by enabling the fgfm-deny-unknown setting.

config system global (global)# set fgfm-deny-unknown enable (global)# end

Important Note:

Enabling this setting will block any FortiGate device that is not already in the FortiManager device list. Even if a pre-shared key (PSK) is configured for a model device, it will not be allowed to register if its serial number is not recognized.

2. Use Local-In Policies to Whitelist Trusted IPs (For FortiManager versions 7.2.0+)

You can configure local-in policies to only allow specific, trusted IP addresses to connect to the FortiManager over the fgfm service port (TCP/541). This helps restrict connections to known FortiGate devices and blocks potential attackers.

Configuration Example:

config system local-in-policy edit 1 set action accept set dport 541 set src <trusted_IPs> next edit 2 set dport 541 set action deny next end

This configuration allows connections only from trusted IP addresses and denies all other incoming traffic on the fgfm port.

3. Custom Certificates (For FortiManager versions 7.2.2+, 7.4.0+, 7.6.0+)

Another workaround involves configuring FortiManager to use a custom certificate for secure communication between FortiManager and FortiGate devices. Only FortiGates that have the corresponding CA certificate installed will be allowed to connect, providing strong validation.

Configuration:

config system global set fgfm-ca-cert <custom_CA_cert> set fgfm-cert-exclusive enable end

After this setup, ensure that the custom CA certificate is installed on all managed FortiGate devices. This restricts device connections to only those with the correct certificate, preventing unauthorized access unless the attacker can acquire a valid certificate from your CA.

References

[1] “PSIRT,” FortiGuard Labs. Available: https://fortiguard.com/psirt/FG-IR-24-423. [Accessed: Oct. 24, 2024]

[2] L. Abrams, “Mandiant says new Fortinet flaw has been exploited since June,” BleepingComputer, Oct. 24, 2024. Available: https://www.bleepingcomputer.com/news/security/mandiant-says-new-fortinet-fortimanager-flaw-has-been-exploited-since-june/. [Accessed: Oct. 24, 2024]