Tested version: 5.2.5, 5.2.6. I haven't confirmed older versions, but there
is a good chance they're also affected.
CVE: Fortinet hands out their own CVEs according to Mitre, and since no
human confirmation was received by Fortinet, no CVE was created yet.
FortiSIEM has a hardcoded SSH public key for user "tunneluser" which is the
same between all installs. An attacker with this key can successfully
authenticate as this user to the FortiSIEM Supervisor. The unencrypted key
is also stored inside the FortiSIEM image. While the user's shell is
limited to running the /opt/phoenix/phscripts/bin/tunnelshell script, SSH
authentication still succeeds.
Dec 2, 2019: Email sent to Fortinet PSIRT with vulnerability details.
Dec 3, 2019: Automated reply from PSIRT that email was received.
Dec 23, 2019: Sent a reminder email to PSIRT about requesting a human
Jan 3, 2019: Public Release
No human response was received by Fortinet for over 30 days. I stated that
if a confirmation was received before January 2nd that they would be given
an additional 60 days (90 days from initial release) to resolve the
vulnerability before releasing it publicly. No such response was received,
so it's now being publicly released.
Clear out (or delete) the /home/tunneluser/.ssh/authorized_keys file on the
supervisor# echo "" > /home/tunneluser/.ssh/authorized_keys
supervisor# rm /home/tunneluser/.ssh/authorized_keys
Also, ensure any of your nodes are behind firewalls with only trusted
access to ports.
The FortiSIEM Supervisor has 2 different sshd daemons listening: one is on
the standard port 22/tcp, and the other on port 19999/tcp):
supervisor# netstat -lnp |grep sshd
tcp 0 0 0.0.0.0:22 0.0.0.0:*
tcp 0 0 0.0.0.0:19999 0.0.0.0:*
tcp 0 0 :::22 :::*
tcp 0 0 :::19999 :::*
The sshd daemon on 19999/tcp uses its own configuration file:
Supervisor# ps aux |grep 38615
root 38615 0.0 0.0 66288 512 ? Ss Sep25 0:00
/usr/sbin/sshd -p 19999 -f /etc/ssh/sshd_config.tunneluser
When looking for this user under ssh configuration files, the sshd
19999/tcp only allows tunneluser to authenticate:
supervisor# grep -R tunneluser /etc/ssh/
Note that there's no DenyUsers tunneluser@* for the standard sshd
configuration. This means that tunneluser can also successfully
authenticate over sshd port 22/tcp.
The Supervisor has an entry for tunneluser in its passwd file:
supervisor# grep tunneluser /etc/passwd:
The Supervisor allows tunneluser to connect with the following SSH key, and
forward port 2 to localhost. I've confirmed with other users of FortiSIEM
that this key is the same for other installs as well. It is not
auto-generated for each FortiSIEM instance:
supervisor# cat /home/tunneluser/.ssh/authorized_keys
The corresponding SSH Private Key is located on all nodes (Supervisor,
Collector, etc.) under the /opt/phoenix/id_rsa.tunneluser file. Running the
following command confirms that this key matches that of the public key:
# ssh-keygen -y -f /opt/phoenix/id_rsa.tunneluser
This means that anyone with access to any FortiSIEM image (to copy the SSH
private key) can authenticate successfully via SSH to the FortiSIEM
Supervisor on port 19999/tcp as tunneluser. They will be limited to the
/opt/phoenix/phscripts/bin/tunnelshell script, but if this is bypassed then
full shell access can be obtained.
iptables and ip6tables are present on the Supervisor. However, they are
both permissive and accept all traffic destined to them:
supervisor# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
supervisor bin]# ip6tables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination