Select your country

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

Søk

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

Executive summary

critical 0-day vulnerability was exploited in the wild (link for our Managed Vulnerability Intelligence-watch customers here). This 0-day has been discussed off the record since that time. Details about impacted and fixed versions were disclosed first. Then, more information were revealed in a blogpost written by security researcher Kevin Beaumont and in comments of Reddit threads.

This critical issue affects most versions of Fortinet’s FortiManager, a solution to manage this vendor’s products and in particular FortiGate firewalls, by automating security operations and deployments. Only publicly exposed instances are expected to have been compromised as of now.

The security advisory is publicly available at this Fortinet URL and involves an authentication issue in fgfmd daemon (FortiGate to FortiManager protocol) which enables a remote unauthenticated attacker to execute arbitrary API commands on the device. The flaw’s CVSS v3.1 score is calculated at 9.8 by the vendor.

No details on the threat actors that leveraged the 0-day were provided, but the activity bears striking similarity with previous Chinese APT activities. Indeed, this mass compromise of one edge security solution is similar to previous campaigns against Fortigate and VPN SSL or firewalls from other prominent vendors. Mainly nation-state hackers usually conduct such advanced attacks, for espionage or pre-positioning within sensitive networks.

Specific logs and IPs addresses were provided by Fortinet to hunt for a possible compromise of a FortiManager device. Mass reconnaissance attempts may have happened as early as mid July, but mass exploitation occurred mostly on September 22.

The threat level of this advisory is thus considered very high (5/5, maximum severity level).

The administrators of the few thousands exposed FortiManager instances are advised to immediately check whether their devices was exposed since July and if so, if it has been hacked using the detection opportunities provided by Fortinet. Indeed, the adversaries have used the obtained accesses on FortiManager to steal configuration files (including authentication secrets), but could have used these accesses to try to jump to FortiGate firewalls or change their security configurations, among others. This is why Kevin Beaumont nicknamed this 0-day “FortiJump“.

What it means?

Fortinet’s security advisory (FG-IR-24-423) explains that a remote attacker with a valid Fortinet certificate extracted from a Fortinet device or VM, could send specially crafted requests allowing to execute arbitrary API commands. This vulnerability stems from a missing authentification on a specific function, impacting the fgfmd daemon.

Mid July, a massive scanning activity by one of the identified malicious server rented by the attackers was detected, presumably for early reconnaissance. On September 22 (and 23), a mass exploitation campaign was launched against numerous of the exposed instances found, resulting in thousands of devices being compromised. Some of our clients have been affected using this automated process at that exact time. A few thousands exposed instances have been identified online using passive scanners such as Censys, and these assets are the ones more specifically at risk of compromise.

 

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

Står du overfor en cyberhendelse akkurat nå?

 

Kontakt vår globale 24/7/365 tjeneste incident response hotline.