Fortinet warns of new critical FortiManager flaw used in zero-day attacks

Fortinet publicly disclosed today a critical FortiManager API vulnerability, tracked as CVE-2024-47575, that was exploited in zero-day attacks to steal sensitive files containing configurations, IP addresses, and credentials for managed devices.

The company privately warned FortiManager customers about the flaw starting October 13th in advanced notification emails seen by BleepingComputer that contained steps to mitigate the flaw until a security update was released.

However, news of the vulnerability began leaking online throughout the week by customers on Reddit and by cybersecurity researcher Kevin Beaumont on Mastodon, who calls this flaw “FortiJump.”

Fortinet device admins have also shared that this flaw has been exploited for a while, with a customer reporting being attacked weeks before the notifications were sent to customers.

“We got breached on this one weeks before it hit “advance notifications” – 0-day I guess,” reads a now-deleted comment on Reddit.  

FortiManager zero-day disclosed

Today, Fortinet publicly disclosed the actively exploited critical FortiManager flaw, tracked as CVE-2024-47575 with a rated severity of 9.8 out of 10.

“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,” reads Fortinet’s FG-IR-24-423 security advisory.

“Reports have shown this vulnerability to be exploited in the wild.”

A source familiar with the attacks told BleepingComputer that the advisory is missing some critical information to exploit the bug: threat actors must first extract a valid certificate from any owned or compromised Fortinet devices, including FortiManager VM.

The flaw impacts the following FortiManager versions:

At this time, only FortiManager versions 7.2.8 and 7.4.5 have been released but BleepingComputer learned that the rest would be released in the upcoming days.

Fortinet created the “FortiGate to FortiManager Protocol” (FGFM) to allow companies to easily deploy FortiGate firewall devices and have them register with a remote FortiManager server so they can be managed from a central location.

“The FortiGate to FortiManager (FGFM) protocol is designed for FortiGate and FortiManager deployment scenarios, especially where NAT is used,” reads documentation about the FGFM protocol.

“These scenarios include the FortiManager on public internet while the FortiGate unit is behind NAT, FortiGate unit is on public internet while FortiManager is behind NAT, or both FortiManager and FortiGate unit have routable IP addresses.”

As cybersecurity researcher Kevin Beaumont points out, it is not difficult for an attacker to connect a FortiGate device to an exposed FortiManager server as long as they have obtained a valid certificate.

This certificate is used to set up an SSL tunnel between the FortiGate and the FortiManager server to authenticate both devices. However, a source familiar with the vulnerability told BleepingComputer that this is not where the vulnerability lies.

Instead, an additional level of authorization is required to execute commands via the FortiManager FGFM API, which can be bypassed using the CVE-2024-47575 flaw. The authentication bypass in the API has been fixed in the latest versions of FortiManager.

This API allows attackers to execute commands, retrieve information, and take full control over managed devices and FortiManager to gain further access to corporate networks.

“Because MSPs — Managed Service Providers — often use FortiManager, you can use this to enter internal networks downstream,” warned Beaumont.

“Because of the way FGFM is designed — NAT traversal situations — it also means if you gain access to a managed FortiGate firewall you then can traverse up to the managing FortiManager device… and then back down to other firewalls and networks.”

Fortinet has offered different ways to mitigate this attack if it is not possible to install the latest firmware update at this time:

• Utilize the set fgfm-deny-unknown enable command to prevent devices with unknown serial numbers from registering to the FortiManager.
• Create a custom certificate for use when creating the SSL tunnel and authenticating FortiGate devices with FortiManager.

  However, Fortinet warns that if a threat actor is able to obtain this certificate, then it could still be used to connect FortiGate devices and exploit the flaw.

• Create an allowed list of IP addresses for FortiGate devices that are allowed to connect.

Instructions on how to perform these mitigations and restore compromised servers can be found in Fortinet’s advisory.

Exploited to steal data

Fortinet says the observed attacks were used to steal various files from the FortiManager server that “contained the IPs, credentials and configurations of the managed devices.”

This stolen information can be used to learn about and target FortiGate devices to gain initial access to corporate networks or MSPs downstream clients.

The company also confirms there is no evidence of malware installed on compromised FortiManager services or configuration changes to managed FortiGate devices.

“At this stage, we have not received reports of any low-level system installations of malware or backdoors on these compromised FortiManager systems,” Fortinet says in the security advisory.

“To the best of our knowledge, there have been no indicators of modified databases, or connections and modifications to the managed devices.”

Fortinet has not attributed the attacks to any particular threat actor and is not sharing any information about how many and the type of customers that were impacted due to the ongoing investigation.

However, Fortinet has shared the following IOCs to help security professionals and network admins detect whether their FortiManager servers were breached using this vulnerability.

The observed attacks show that the threat actors connected attacker-controlled FortiGate devices under the name “localhost,” which will appear in the Unregistered Devices section in Fortimanager.

Log entries will show that the threat actors issued API commands to add these unregistered “localhost” 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"

Another log entry shared by Fortinet was used to edit 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)"

Fortinet says that rogue FortiGate devices were seen using the serial number FMG-VMTM23017412, which appears to be the format used by FortiGate-VM virtual machines.

Other IOCs include the creation of the /tmp/.tm and /var/tmp/.tm files.

The following IP addresses were observed in the attacks, all located at the cloud hosting company, Vultr:

• 45.32.41.202 
• 104.238.141.143 (Recently seen hosting SuperShell C2 infrastructure)
• 158.247.199.37
• 45.32.63.2

The SuperShell C2 framework was recently utilized in attacks on F5 BIG-IP routers that were attributed with moderate confidence to a Chinese (PRC) threat actor known as UNC5174.

Fortinet warns that not all IOCs may be present on exploited devices.

Beaumont warns that a Shodan search shows there are 59,534 FortiManager devices whose FGFM ports (TCP port 531) are exposed online, with the majority in the US.

Private disclosure leads to frustration

Fortinet shared the following statement with BleepingComputer about the CVE-2024-47575 flaw and how it was disclosed to customers.

However, Fortinet customers have expressed frustration over how the vulnerability was disclosed, with some FortiManager customers not receiving the advanced notice and having to rely on leaked information to find out about the zero-day vulnerability.

“How do I get on the private disclosure email list? I have 7.2.7 and didn’t hear about this,” a FortiManager customer commented on Reddit.

BleepingComputer was told that all FortiManager customers should have received this notification to their “Master” account. If they did not, they should contact Fortinet or their reseller to confirm they have the correct contact information.

Others were frustrated that the private advisory did not list FortiManager Cloud as impacted by the zero-day, yet when they called Fortinet TAC, they were told it was impacted.

This flaw is not the first time Fortinet decided to quietly patch a critical vulnerability or privately disclose it to customers.

In December 2022, Fortinet quietly patched an actively exploited FortiOS SSL-VPN vulnerability tracked as CVE-2022-42475 without publicly stating that the flaw was used in attacks. Like this FortiManager flaw, Fortinet issued a private TLP:Amber advisory to customers on December 7th, alerting customers to the bug.

In June 2023, Fortinet again quietly patched a critical FortiGate SSL-VPN remote code execution vulnerability tracked as CVE-2023-27997 on June 8. Four days later, on June 11th, the company disclosed that the flaw had been used in zero-day attacks against government, manufacturing, and critical infrastructure.

Some have called out Fortinet’s lack of transparency, recalling an October 2023 post from Fortinet that stated, “the security community must normalize transparency and information sharing for organizations to collectively advance their fight against adversaries.”

Update 10/23/24: Updated impacted versions and added further information about the vulnerability.