Select your country

Not finding what you are looking for, select your country from our regional selector:

Search

FortiManager critical 0-day vulnerability exploited in the wild (FG-IR-24-423 aka FortiJump)

Update 3, 11-15-2024 - FortiManager flaw CVE-2024-47575 bypassed by WatchTowr, details/PoCs are now public

Executive Summary

Since our last update, vulnerability researchers at WatchTowr published the details and exploit for the vulnerability in FortiManager known as “fortijump” (CVE-2024-47575). These technical details reveal that this vulnerability relies on command injection due to insufficient validation in the som/export function, allowing attackers to exploit the system() call to execute arbitrary commands. Using the get file_exchange command, an attacker can obtain a valid transfer identifier and pass a command through som/export, triggering a reverse shell.

WatchTowr considers patch 7.6.1 (and potentially all previous fixed versions for the CVE-2024-47575 vulnerability) to be insufficient to fully fix this issue. They consider the patch was misapplied in a separate function and library from those containing the original vulnerability.

WatchTowr notes that the IoCs provided by Mandiant, which rely on logs in /log/locallog/elog to detect unregistered devices, can unfortunately be bypassed as well. Therefore, WatchTowr recommends monitoring for suspicious file transfers and unusual activities related to som/export. It also advises network monitoring to detect abnormal outgoing connections, such as reverse shells.

To verify whether their environment is vulnerable to FortiJump, administrators can use WatchTowr's exploit, which provides a way to test for the presence of this vulnerability in FortiManager systems. A specific certificate and encryption key are used to bypass FortiManager's access controls and open secure communication.

It is important to note that the execution of this code can be detected by following the WatchTowr recommendations mentioned above. We therefore recommend that you follow these recommendations.

Researchers also revealed that the new FortiJumpHigher vulnerability – which still has no CVE number assigned, may have already been discovered (and potentially exploited) by APT groups. This new flaw allegedly remains unpatched and could allow adversaries to elevate from one managed FortiGate appliance to the central FortiManager appliance.

Because of the corrections of device registration, FortiJumpHigher is considered as a post-authentication privilege escalation attack, instead of the full RCE that is FortiJump.

Furthermore, on November 8, Fortinet added a new attacker IP address that exploited CVE-2024-47575: 198.199.122[.]22.

The threat level remains unchanged (5 out of 5).

What You Should Do

Orange Cyberdefense’s Datalake platform provides access to Indicators of Compromise (IoCs) related to this threat, which are automatically fed into our Managed Threat Detection services. This enables proactive hunting for IoCs if you subscribe to our Managed Threat Detection service that includes Threat Hunting. If you would like us to prioritize addressing these IoCs in your next hunt, please make a request through your MTD customer portal or contact your representative.

Orange Cyberdefense’s MTI [protect] service offers the ability to automatically feed network-related IoCs into your security solutions. To learn more about this service and to find out which firewall, proxy, and other vendor solutions are supported, please get in touch with your Orange Cyberdefense Trusted Solutions representative.

Update 2, 11-06-2024 - Fix for FortiManager 0-day CVE-2024-47575 bypassed by WatchTowr, but details/PoC not released publicly

This advisory was provided to our Managed service customers on 11/06/2024, 11:59 AM

As a reminder, mass exploitation of exposed FortiManager instances was observed on September 22 and 23, as indicated in our initial advisory below. It is nevertheless probable that more limited, targeted use of the 0-day occurred earlier. NCC Group detected possible exploitation attempts as early as May for instance, and we suspect adversaries started even earlier setting up some of the needed infrastructure and conduct initial reconnaissance.

We expect more advanced adversaries are already or will soon be capable of leveraging the vulnerability. Vulnerability researchers from WatchTowr for example confirmed having found how to leverage CVE-2024-47575. Fortunately, no details or code were revealed yet publicly. They also announced being able to compromise a fully patched FortiManager instance via a working PoC bypassing the fix released in the latest versions (using 7.6.1 in their example). The precise list of impacted versions was not disclosed, but we expect the same branches to be vulnerable.

This new but linked issue does not have a CVE number yet, but is nicknamed “fortijump-higher“. WatchTowr announced that they reached out to Fortinet and will wait until the vendor releases an advisory before publishing technical details. An advisory about this bypass is available for our [Managed Vulnerability Intelligence – watch] service customers at this address.

Fortinet did not publicly react to WatchTowr’s findings yet, but updated earlier the initial advisory (on October 30), adding 2 new IP addresses of attackers who exploited CVE-2024-47575, 1 new rogue device serial number abused, and notes on the workaround provided. Those additional IP adresses, not rented from the same original hosting provider (Vultr), are:

  • 80.66.196.199 (PS: also mentioned in a VirusTotal comment, and detected on October 24),
  • 172.232.167.68 (reported by a trusted third party to Fortinet).

New adversaries may have managed to get their hands on the exploit or reverse the patches to identify it. Other suspicious IPs, identified in OSINT or by our teams and partners, are available to our [Managed Threat Intelligence – detect] clients only, via our Datalake IOCs repository.

New serial number seen abused by Fortinet include:

  • FMG-VMTM19008093 (provided in Fortinet’s updated advisory),
  • FMG-VMTM1900809 (unconfirmed: found in the VirusTotal comment for the new IP address mentioned above, but probably similar to the first FMG number, just with the missing last digit).

Fortinet also indirectly listed all FortiGate secret information (i.e. credentials) you should rotate in case you suspect a compromise here.

Another support page explains how to start provision again new FortiGate device if the workaround (using “set fgfm-deny-unknown enable”) remains active.

 

The risk level remains very high for now, even if no public report of post-exploitation activities emerged yet.

What You Should Do

Orange Cyberdefense’s Datalake platform provides access to Indicators of Compromise (IoCs) related to this threat, which are automatically fed into our Managed Threat Detection services. This enables proactive hunting for IoCs if you subscribe to our Managed Threat Detection service that includes Threat Hunting. If you would like us to prioritize addressing these IoCs in your next hunt, please make a request through your MTD customer portal or contact your representative.

Orange Cyberdefense’s MTI [protect] service offers the ability to automatically feed network-related IoCs into your security solutions. To learn more about this service and to find out which firewall, proxy, and other vendor solutions are supported, please get in touch with your Orange Cyberdefense Trusted Solutions representative.

Update 1, 10-24-2024 - Advisory on FortiJump (CVE-2024-47575) 0-day released, more IOCs and fixes available

Fortinet’s advisory about the 0-day was finally published onlinea few hours after our below advisory. It notably revealed the CVE number attributed to this vulnerability: CVE-2024-47575.

The advisory includes a 4th IP address (45.32.63[.]2) that we knew thanks to our CTI partners. The IP belongs to the same threat actors, but we did not directly observe it in our incident response engagements. We nevertheless advise you to also hunt for TCP traffic from or towards this IP, only on suspected ports (541/443). If you hunt in logs using network IOCs, we recommend you to extend the search before September 1st, and ideally up to June 22nd, as Mandiant released a report confirming threat actors started these malicious activities as early as June 27th.

Furthermore, Mandiant announced having detected at least 50 instances compromised. This is way below the actual number we currently estimate, ranging between 1,000 and 3,000 instances. NB: More than 60,000 instances are presumably found using simplistic queries on passive scanners such as Shodan. These numbers do include FortiGate devices on top of FortiManager along with honeypots, and should not be trusted as is.

ShadowServer will send later today a specific report to notify their subscribers if they were targeted or compromised by this specific cluster of activity. We advise you to register your organisation in their various notification services if you haven’t yet, in order to receive their free daily reports.

Mandiant assigned a cluster identifier for the operation, UNC5820, without associating it to any previous known threat actor. They also did not mention its presumed Chinese origin. Mandiant also confirmed our own findings on the specific exfiltered data.

In the second, massive exploitation campaing surrounding September 22, their researchers identified an additional artefact on top of the “FMG number” associated to the unauthorized device registered on a compromised FortiManager. Presence of the below disposable email address and/or company name indicate a highly probable infection:  

SerialNumber=FMG-VMTM23017412|AccountID=0qsc137p@justdefinition.com|Company=PuritySupreme|UserID=1756868

Host based indicators could also help confirm a successful infection:

  • /tmp/[.]tm
  • /fds/data/unreg_devices[.]txt (NB: with MD5 hash = 9dcfab171580b52deae8703157012674
  • /fds/data/subs.dat[.]tmp
  • /fds/data/subs[.]dat

Other provided indicators include a 5th IP address presumably used by the threat actors: 195.85.114[.]78. No additional information is available on this IOC at this time.

Fixes are now available for 4 out of the 6 planned branches:

  • 7.4.5: 2024-10-17
  • 7.2.8: 2024-10-18
  • 7.0.13: 2024-10-22
  • 6.2.13: 2024-10-23

7.6.1 and 6.4.15 should be available soon, probably before October 28.

Fortinet’s advisory was also updated to confirm FortiManager Cloud instances are impacted as well (except for the latest branch, 7.6):

 

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

 

 

Even if Mandiant did not share any additional post-exploitation activities, the risk level associated to this advisory remains very high for now (5/5).

What You Should Do

Orange Cyberdefense’s Datalake platform provides access to Indicators of Compromise (IoCs) related to this threat, which are automatically fed into our Managed Threat Detection services. This enables proactive hunting for IoCs if you subscribe to our Managed Threat Detection service that includes Threat Hunting. If you would like us to prioritize addressing these IoCs in your next hunt, please make a request through your MTD customer portal or contact your representative.

Orange Cyberdefense’s MTI [protect] service offers the ability to automatically feed network-related IoCs into your security solutions. To learn more about this service and to find out which firewall, proxy, and other vendor solutions are supported, please get in touch with your Orange Cyberdefense Trusted Solutions representative.

Impacted versions include

  • FortiManager versions 7.6.0
  • FortiManager versions 7.4.4 and below
  • FortiManager versions 7.2.7 and below
  • FortiManager versions 7.0.12 and below
  • FortiManager versions 6.4.14 and below
  • (End of Support versions 6.2.x maybe as well)

Patches are released progressively by the vendor and workarounds have been also shared (see our “What you should do” section).

We classify this advisory’s threat level as 5 out of 5, the maximum level possible on our side.

 

Patches for the 0-day

Fortinet has released the following versions of FortiManager that address this vulnerability:

  • 7.4.5
  • 7.2.8
  • 7.0.13
  • 6.2.13

Workaround provided by Fortinet

For versions earlier than 7.6, include preventing unknown devices to attempt to register using the below configuration:

# config system global

(global)# set fgfm-deny-unknown enable

(global)# end

Adding local-in policies to whitelist the IP addresses of FortiGates that are allowed to connect is proposed otherwise. If possible, access to FortiManager should always be restricted to trusted sources only.

Fortinet provides log entries to hunt for, that if found are indicating a highly probable exploitation:

  • 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)”

A device registered with the serial number “FMG-VMTM23017412” is thus a very reliable indicator. We don’t know any other “FMG-numbers” used as of now.

IPs attributed to the attackers that exploited this 0-day were provided by the vendor:

  • 45.32.41[.]202 
  • 104.238.141[.]143 
  • 158.247.199[.]37 
  • 45.32.63[.]2 
  • (other suspicious but unconfirmed IOCs are reserved to our Managed Threat Intelligence – detect clients so far)

We confirmed all three above were indeed identified in the incidents we investigated. Established TCP traffic from and towards these IPs on port 541 and/or 443 should be thoroughly checked, in particular around September 22.

In case of confirmed compromise, we advise you to not upgrade the instance, but fully reinstall a fresh one running a fixed version, along with backup data from prior to the compromise date, i.e. before September 21 at least.

Incident Response Hotline

Facing cyber incidents right now?

Contact our 24/7/365 world wide service incident response hotline.