Authentication bypass in Node.js websocket module
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.
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 |
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 "all"
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.
Virtual Patch named "FortiOS.NodeJS.Websocket.Authentication.Bypass." is available in FMWP db update 25.014
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