PSIRT | FortiGuard Labs

Summary

An Authentication Bypass Using an Alternate Path or Channel vulnerability [CWE-288] affecting FortiOS and FortiProxy may allow a remote attacker to gain super-admin privileges via crafted requests to Node.js websocket module or via crafted CSF proxy requests.

Please note that reports show this is being exploited in the wild.

Version

Affected

Solution

FortiOS 7.6

Not affected

Not Applicable

FortiOS 7.4

Not affected

Not Applicable

FortiOS 7.2

Not affected

Not Applicable

FortiOS 7.0

7.0.0 through 7.0.16

Upgrade to 7.0.17 or above

FortiOS 6.4

Not affected

Not Applicable

FortiProxy 7.6

Not affected

Not Applicable

FortiProxy 7.4

Not affected

Not Applicable

FortiProxy 7.2

7.2.0 through 7.2.12

Upgrade to 7.2.13 or above

FortiProxy 7.0

7.0.0 through 7.0.19

Upgrade to 7.0.20 or above

FortiProxy 2.0

Not affected

Not Applicable

Follow the recommended upgrade path using our tool at: https://docs.fortinet.com/upgrade-tool

IoCs

The following log entries are possible IOC's:

• Following login activity log with random scrip and dstip:
  type="event" subtype="system" level="information" vd="root" logdesc="Admin login successful" sn="1733486785" user="admin" ui="jsconsole" method="jsconsole" srcip=1.1.1.1 dstip=1.1.1.1 action="login" status="success" reason="none" profile="super_admin" msg="Administrator admin logged in successfully from jsconsole"

• Following admin creation log with seemingly randomly generated user name and source IP:
  type="event" subtype="system" level="information" vd="root" logdesc="Object attribute configured" user="admin" ui="jsconsole(127.0.0.1)" action="Add" cfgtid=1411317760 cfgpath="system.admin" cfgobj="vOcep" cfgattr="password[*]accprofile[super_admin]vdom[root]" msg="Add system.admin vOcep"

• The following IP addresses were mostly found used by attackers in above logs:
  1.1.1.1
  127.0.0.1
  2.2.2.2
  8.8.8.8
  8.8.4.4

Please note that the above IP parameters are not the actual source IP addresses of the attack traffic, they are generated arbitrarily by the attacker as a parameter. Because of this they should not be used for any blocking.

Please note as well that sn and cfgtid are not relevant to the attack.

The operations performed by the Threat Actor (TA) in the cases we observed were part or all of the below:
- Creating an admin account on the device with random user name
- Creating a Local user account on the device with random user name
- Creating a user group or adding the above local user to an existing sslvpn user group
- Adding/changing other settings (firewall policy, firewall address, ...)
- Logging in the sslvpn with the above added local users to get a tunnel to the internal network.

Admin or Local user created by the TA is randomly generated. e.g:
Gujhmk
Ed8x4k
G0xgey
Pvnw81
Alg7c4
Ypda8a
Kmi8p4
1a2n6t
8ah1t6
M4ix9f
...etc...

Additionally, the TA has been seen using the following IP addresses:

45.55.158.47 [most used IP address]
87.249.138.47
155.133.4.175
37.19.196.65
149.22.94.37

Workaround

Disable HTTP/HTTPS administrative interface

OR

Limit IP addresses that can reach the administrative interface via local-in policies:

config firewall address
edit "my_allowed_addresses"
set subnet
end

Then create an Address Group:

config firewall addrgrp
edit "MGMT_IPs"
set member "my_allowed_addresses"
end

Create the Local in Policy to restrict access only to the predefined group on management interface (here: port1):

config firewall local-in-policy
edit 1
set intf port1
set srcaddr "MGMT_IPs"
set dstaddr "all"
set action accept
set service HTTPS HTTP
set schedule "always"
set status enable
next

edit 2
set intf "any"
set srcaddr "all"
set dstaddr "all"
set action deny
set service HTTPS HTTP
set schedule "always"
set status enable
end

If using non default ports, create appropriate service object for GUI administrative access:

config firewall service custom
edit GUI_HTTPS
set tcp-portrange 443
next

edit GUI_HTTP
set tcp-portrange 80
end

Use these objects instead of "HTTPS HTTP "in the local-in policy 1 and 2 below.

Please note that the trusthost feature achieves the same as the local-in policies above only if all GUI users are configured with it. Therefore, the local-in policies above are the preferred workaround.

Please note as well that an attacker needs to know an admin account's username to perform the attack and log in the CLI. Therefore, having a non-standard and non-guessable username for admin accounts does offer some protection, and is, in general, a best practice. Keep in mind however that the targeted websocket not being an authentication point, nothing would prevent an attacker from bruteforcing the username.

Please contact customer support for assistance.

CSF requests issue:

Disable Security Fabric from the CLI:

Config system csf
   Set status disable
end

Acknowledgement

Fortinet is pleased to thank Sonny of watchTowr (https://watchtowr.com/)) for reporting the CSF related vulnerability under responsible disclosure.

Timeline

2025-01-14: Format
2025-01-15: Added non-standard admin account username best practice
2025-01-15: Clarified that IP addresses "under attacker control" means they are arbitrarily generated by the attacker
2025-01-21: Added IPS package info
2025-01-24: Removed IPS package info
2025-02-11: Added CVE-2025-24472 and its acknowledgement

CVE-2024-55591 and CVE-2025-24472