Splunk UseCase for attacks against FortiGate Firewall management interfaces

If you are using Splunk as your SIEM you can try to detect attacks against your FortiGate firewalls by using the following SPL query:

index=firewall type=event subtype=system msg IN ("Failed to match community*", "Message authentication or checking failed*", "Negotiation failed: no matching*", "Negotiation failed: Broken pipe*")
| stats earliest(_time) as FirstEvent count by devname,msg,result,logdesc
| eval FirstEvent=strftime(FirstEvent,"%Y-%m-%d %H:%M:%S")


Additionally: It is imperative that you protect your FortiGate interfaces with TrustedHosts AND Local-In-Policies. Only using TrustHosts protects HTTPS, SSH, etc but not other protocols like SIP, IPsec, CAPWAP, BGP, OSPF, SSLVPN etc which are also local services running on the FortiGate, which need to be protected, too.
See https://how2itsec.blogspot.com/2022/10/fortigate-admin-interface.html

FortiGate admin interface authentication bypass

There are rumors about a vulnerability in Fortinets FortiGate firewalls where you may bypass authentication on their admin interfaces. Affected seem to be FortiOS 7.0.x and FortiOS 7.2.0/1. A fix is included in FortiOS 7.0.7 and FortiOS 7.2.2. It is written the vulnerability has CVE-2022-40684.

It is imperative that you protect your FortiGate interfaces with TrustedHosts AND Local-In-Policies. Only using TrustHosts protects HTTPS, SSH, etc but not other protocols like SIP, IPsec, CAPWAP, BGP, SSLVPN* etc which are also local services running on the FortiGate, which need to be protected, too.

*SSLVPN = Even though SSLVPN might be not configured and therefore seems to be inactive, in some cases for example vulnerability-scanners still trigger the SSLVPN service to log errors in FortiGates log. This only is solved by setting up local-in-polices.

Example for trusthost & local-in-policy:

CLI configuration:

System > Administrators >
config system admin
    edit "admin"
        set trusthost1 172.26.73.48 255.255.255.255
        set accprofile "super_admin"
        set vdom "root"
    next
end

Configuring address and address group as per the trusted hosts:

config firewall address
    edit "trusted-1"
        set type ipmask
        set comment ''
        set visibility enable
        set associated-interface ''
        set color 0
        set allow-routing disable
        set subnet 172.26.73.48 255.255.255.255
    next
end

config firewall addrgrp
    edit "trusted_grp"
        set member "trusted-1"
        set comment ''
        set visibility enable
        set color 0
    next
end

Configuring Firewall local in policies:

config firewall local-in-policy
    edit 2
        set intf "port1"
        set srcaddr "trusted_grp"
        set dstaddr "all"
        set action accept
        set service "PING"
        set schedule "always"
        set status enable
        set comments ''
    next
    edit 1
        set intf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "PING"
        set schedule "always"
        set status enable
        set comments ''
    next
end

Remember: This example shows the local-in-policy only for "ping". You want to protect all services (except for example SSLVPN or IPsec if you use them).

FortiManager task fails when MTU is changed on LAG-Interface of FortiGate HA

If you want to change the MTU of your FortiGate HA-Cluster by using the FortiManager, think about removing the HA monitored interface for that LAG-interface first. Because: When the MTU of that LAG-interface is changed, the interface goes down and comes up again. If that LAG-interface is part of the HA monitored interfaces, then your FortiGate HA will execute a HA failover. That interupts the execution of the FortiManager task and might lead to a crash of the FortiManager (reboots).

FortiManager Log shows:

1560 2021-02-03 17:10:31 [..]
1561 2021-02-03 17:10:31 information Deployment manager event Device state updates
Device fgtdev214 config status changed to OUT_OF_SYNC by aborted, devdb MODIFIED
1562 2021-02-03 17:10:31 error prod-user54 Deployment manager event Policy package install failed Installation of the device settings (null) on fgtdev214[root] failed.
1563 2021-02-03 17:10:31 [..]

If you want to avoid an unplanned FortiGate HA-failover, FortiManager crash and using diagnose dvm task repair on your FortiManager, then:

1. Schedule a maintenance window (communication & schedule a maintenance window in your monitoring- and logging-systems)
2. Remove the HA monitor interface for that LAG-interface first (using the FortiManager)
3. Then adjust the MTU on the FortiGate LAG-interface (using the FortiManager)
4. Enable the HA monitor interface for that LAG-interface again (using the FortiManager)
5. Test your new MTU, communicated the change and enable alerting/stop maintenance-window in your monitoring-systems and log-alerts.

Kali linux update fails with HTTP 403 Forbidden

If one of your kali linux systems fails to update some packages like davtest, dbd, impacket, mimikatz etc using sudo apt-get update with the error "http 403 forbidden", as shown in the following screenshot, a possible cause could be your FortiGate firewall with its UTM antivirus feature:

Your Fortinet FortiGate antivirus log might look like this:

To fix this, create an extra FortiGate antivirus profile which excludes those signatures and use this av profile in the firewall policy of your kali systems. Another 'dirty' workaround could be to change the updates to use HTTPS, as long as you don't do deep packet inspection for TLS traffic on your FortiGate. If so the URI and payload become invisble due to encryption to your FortiGate.

HTTPS for kali updates: https://www.kali.org/news/kali-linux-repository-https-support/

List FortiGate Certificates via CLI - CA certificates and local Certificates

You can either use the GUI of the FortiGate to list all certificates, or use the CLI. Either using the commands:

Using the "get" command

config vdom
edit root   #<--- your management vdom/your vdom of choice
get vpn certificate ca

FGT50E00000000 (root) #
FGT50E00000000 (root) # get vpn certificate ca
== [ Fortinet_Wifi_CA ]
name: Fortinet_Wifi_CA
== [ Fortinet_CA ]
name: Fortinet_CA
== [ ACCVRAIZ1 ]
name: ACCVRAIZ1
== [ AC_RAIZ_FNMT-RCM ]
name: AC_RAIZ_FNMT-RCM
== [ Actalis_Authentication_Root_CA ]
name: Actalis_Authentication_Root_CA
[...]

Using the "show" command

The show command might not be very helpful, because it does not necessarily show all certificates:

FGT50E00000000 (root) #
FGT50E00000000 (root) # show vpn certificate ca
config vpn certificate ca
end
FGT50E00000000 (root) # show full-configuration vpn certificate ca
config vpn certificate caend

FGT50E00000000 (root) # show full-configuration | grep -f 'vpn certificate ca'
config vpn certificate ca <---
end
FGT50E00000000 (root) #

Using the "fnsysctl" command

Using the fnsysctl command might be helpful:

FGT50E00000000  #
FGT50E00000000 # fnsysctl ls -la /etc/cert/local/
drwxr-xr-x    2 0    0   Wed Dec 25 21:43:14 2019        0 .
drwxr-xr-x    6 0    0   Wed Sep 18 20:39:27 2019        0 ..
-rw-------    1 0    0   Wed Sep 18 20:35:46 2019     2250 root_2020jan_sub.domain.tld.cer
-rw-------    1 0    0   Wed Sep 18 20:35:46 2019     1704 KEY-FILE
-rw-------    1 0    0   Wed Sep 18 20:35:46 2019     1407 root_Fortinet_CA_SSL.cer
-rw-------    1 0    0   Wed Sep 18 20:35:47 2019     1704 KEY-FILE
-rw-------    1 0    0   Wed Sep 18 20:35:47 2019     1419 root_Fortinet_CA_Untrusted.cer
-rw-------    1 0    0   Wed Sep 18 20:35:47 2019     1704 KEY-FILE
-rw-------    1 0    0   Wed Sep 18 20:35:47 2019     4285 root_Fortinet_Factory.cer
-rw-------    1 0    0   Wed Sep 18 20:35:47 2019     1679 KEY-FILE[...]
FGT50E00000000  #
FGT50E00000000  # fnsysctl ls -la /etc/cert/ca
drwxr-xr-x    2 0    0   Wed Dec 25 21:41:28 2019        0 .
drwxr-xr-x    6 0    0   Wed Sep 18 20:39:27 2019        0 ..
-rw-------    1 0    0   Wed Sep 18 20:35:55 2019      119 ca_bundle_ver
-rw-------    1 0    0   Tue Jan 14 20:06:15 2020 1972 root_AC_RAIZ_FNMT-RCM.cer
-rw-------    1 0    0   Tue Jan 14 20:06:15 2020 2772 root_ACCVRAIZ1.cer
-rw-------    1 0    0   Wed Sep 18 20:35:55 2019     2041 root_ACEDICOM_Root.cer
-rw-------    1 0    0   Tue Jan 14 20:06:15 2020 2049 root_Actalis_Authentication_Root_CA.cer
-rw-------    1 0    0   Tue Jan 14 20:06:14 2020 1521 root_AddTrust_External_Root.cer[...]

FortiGate allows Ping from "not trusted hosts" since FortiOS 6.0

Recently I discovered something after updating a FortiGate cluster, which I intensively monitor, not only via working monitoring queries, but also doing some negative monitoring*: Since FortiOS 6.0 the Fortinet FortiGate firewall answers to source addresses via ICMP Type:8 EchoRequest "Ping", which are not included in the trustedhosts (config system admin -> edit admin -> set trusthost1). This is due to a change in FortiOS, which allows ping from more addresses. To limit ping, you have to use LocalIn-Policies (which always should be used, too).

*negative monitoring = I recommend not only to monitor what is allowed (like your SNMPv3 AuthPriv queries, your SSH or HTTPS-Calls), but also to monitor what is forbidden, in order to find some possible bugs or misconfigurations, if suddenly something is answering what really shouldn't. This can be done by trying to use insecure protocols like Telnet, SNMPv1/v2c, HTTP, etc.. or by sending requests from not allowed source ips or by trying to login using deleted/altered accounts or with wrong credentials.


Fortinet documentation:

In versions 5.x and below, trusted hosts configured by an administrator user only allow access from certain IP addresses configured in trusted hosts, to all services configured on the interface, including ping.

From version 6.0 onwards ping service on management interfaces are not included within the scope of trusted hosts. This means that you will be able to ping the interface from an IP that is not included within trusted hosts.

In order to only allow trusted hosts to be able to ping the interface and deny everyone else, you will need to configure a Local In Policy as below.

CLI configuration:

System > Administrators >
config system admin
    edit "admin"
        set trusthost1 172.26.73.48 255.255.255.255
        set accprofile "super_admin"
        set vdom "root"
    next
end

Configuring address and address group as per the trusted hosts:

config firewall address
    edit "trusted-1"
        set type ipmask
        set comment ''
        set visibility enable
        set associated-interface ''
        set color 0
        set allow-routing disable
        set subnet 172.26.73.48 255.255.255.255
    next
end

config firewall addrgrp
    edit "trusted_grp"
        set member "trusted-1"
        set comment ''
        set visibility enable
        set color 0
    next
end

Configuring Firewall local in policies:

config firewall local-in-policy
    edit 2
        set intf "port1"
        set srcaddr "trusted_grp"
        set dstaddr "all"
        set action accept
        set service "PING"
        set schedule "always"
        set status enable
        set comments ''
    next
    edit 1
        set intf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "PING"
        set schedule "always"
        set status enable
        set comments ''
    next
end

Before configuring the local in policy:

diagnose sniffer packet any 'host 172.26.73.78 and icmp' 4
interfaces=[any]
filters=[host 172.26.73.48 and icmp]
3.647787 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
3.647850 port1 out 10.5.22.114 -> 172.26.73.78: icmp: echo reply
4.651341 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
4.651383 port1 out 10.5.22.114 -> 172.26.73.78: icmp: echo reply
5.657949 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
5.657992 port1 out 10.5.22.114 -> 172.26.73.78: icmp: echo reply

After configuring the local in policies:

diagnose sniffer packet any 'host 172.26.73.78 and icmp' 4
interfaces=[any]
filters=[host 172.26.73.48 and icmp]
4.264950 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
8.904217 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
13.906576 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
18.893835 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request

trace_id=22 func=print_pkt_detail line=5497 msg="vd-root:0 received a packet(proto=1, 172.26.73.78:1->10.5.22.114:2048) from port1. type=8, code=0, id=1, seq=335."
id=20085 trace_id=22 func=init_ip_session_common line=5657 msg="allocate a new session-00874fe6"
id=20085 trace_id=22 func=vf_ip_route_input_common line=2591 msg="find a route: flag=80000000 gw-10.5.22.114 via root"
id=20085 trace_id=22 func=fw_local_in_handler line=409 msg="iprope_in_check() check failed on policy 1, drop

Reply for the trusted host:

diagnose sniffer packet any 'host 172.26.73.48 and icmp' 4
interfaces=[any]
filters=[host 172.26.73.48 and icmp]
7.239647 port1 in 172.26.73.48 -> 10.5.22.114: icmp: echo request
7.239743 port1 out 10.5.22.114 -> 172.26.73.48: icmp: echo reply
8.261081 port1 in 172.26.73.48 -> 10.5.22.114: icmp: echo request
8.261122 port1 out 10.5.22.114 -> 172.26.73.48: icmp: echo reply
9.276261 port1 in 172.26.73.48 -> 10.5.22.114: icmp: echo request
9.276321 port1 out 10.5.22.114 -> 172.26.73.48: icmp: echo reply
10.294536 port1 in 172.26.73.48 -> 10.5.22.114: icmp: echo request
10.294588 port1 out 10.5.22.114 -> 172.26.73.48: icmp: echo reply

Diag debug flow on FortiOS 6.0.9
Source IP of ping is not configured in trustedhosts

2020-02-26 08:38:47 id=20085 trace_id=255 func=init_ip_session_common line=5684 msg="allocate a new session-00018a90"
2020-02-26 08:38:47 id=20085 trace_id=255 func=vf_ip_route_input_common line=2591 msg="find a route: flag=80000000 gw-10.128.36.35 via root"
2020-02-26 08:38:47 id=20085 trace_id=256 func=print_pkt_detail line=5519 msg="vd-root:0 received a packet(proto=1, 10.128.36.35:1->10.240.161.178:0) from local. type=0, code=0, id=1, seq=1156."


Diag debug flow on FortiOS 5.6.12
Source IP of ping is not configured in trustedhosts

2020-02-26 08:46:05 id=20085 trace_id=10 func=print_pkt_detail line=5375 msg="vd-root received a packet(proto=1, 10.240.161.178:1->10.128.36.4:2048) from mgmt1. type=8, code=0, id=1, seq=1166."
2020-02-26 08:46:05 id=20085 trace_id=10 func=init_ip_session_common line=5534 msg="allocate a new session-fd0ad6af"
2020-02-26 08:46:05 id=20085 trace_id=10 func=vf_ip_route_input_common line=2574 msg="find a route: flag=80000000 gw-10.128.36.4 via root"
2020-02-26 08:46:05 id=20085 trace_id=10 func=fw_local_in_handler line=402 msg="iprope_in_check() check failed on policy 0, drop"

Source: https://kb.fortinet.com/kb/documentLink.do?externalID=FD44156

Solution for Skybox connection issue to Fortinet FortiGate or FortiManager

If you are using the Skybox (https://www.skyboxsecurity.com/) solution for your environment, during the initial setup there might be an issue in the connection from the Skybox to your Fortinet FortiGate firewalls or your or FortiManager firewall management system. Skybox uses HTTPS (XML API with SOAP) and/or SSH to connect to the Fortinet systems.

If your hardening of the Fortinet devices changed the default minimum Diffie-Hellman Exchange-Bits from 2048 to 3072, 4096 or 8192Bits, then your Skybox is not able to connect to them, after Skybox currently does not support more than 2048Bit for DH.

FortiGate Hardening of DH-Bits:

config sys global
 set dh-params 8192
end

See also the Skybox documentation "ReferenceGuide", e.g. here "Reference Guide v10.801" or an overview of the documentation of all last versions.

Hardening FortiGate connection to FortiAnalyzer

The FortiGate uses OFTP (Fortinets proprietary Optimized Fabric Transfer Protocol, not Odette File Transfer Protocol) to transfer data between FortiGates and FortiAnalyzer. For encryption SSLv3 or TLS is used. In order to harden the connection, use the following commands:

Cfg for FortiAnalyzer 

 1. Set TLS to minimum version 1.2:


2. Change FAZ certificate to one using the correct FQDN from your/a public CA:



Debugging can be done using the fowlloing commands:

Oftpd daemon test usage:   diagnose test application oftpd <integer>

• 1: show PID
• 2: show statistics and state
• 3: show connected device name and IP
• 4: show detailed session state
• 5: show oftp request statistics
• 6: show cmdb device cache
• 7: show logfwd thread stats
• 8: show tasklist statistics
• 9: show unreg dev cache
• 10: log cluster bridge stats
• 20: show forticlent end-user stats
• 21: rebuild forticlient end-user avatar table
• 90: reload un-reg device tree
• 99: restart daemon

FAZ looks like this:

(global)# get

dh-params           : 8192

enc-algorithm       : high

fgfm-ssl-protocol   : tlsv1.2

oftp-ssl-protocol   : tlsv1.2

ssl-low-encryption  : disable

ssl-protocol        : tlsv1.2

ssl-static-key-ciphers: disable

webservice-proto    : tlsv1.2

Cfg for FortiGate

1. Change TLS ciphers to high:

config log fortianalyzer setting

    set enc-algorithm high

end

2. Change Global TLS-Settings

config system global

    set ssl-static-key-ciphers disable

    set dh-params 8192

    set strong-crypto enable

end

FortiOS XSS in DHCP-Monitor

Fortinet has released PSIRT FG-IR-19-184 (CVE-2019-6697) about a vulnerability in FortiOS of the FortiGate firewall. A DHCP packet may contain a stored XSS in the hostname parameter field.

Affected Versions and Update

Affected Products are FortiOS 6.2.1 and below & FortiOS 6.0.6 and below.

FortiOS 6.2.2 and FortiOS 6.0.7 fix the vulnerability

PoC/Vulnerability Details from ssd-disclosure.com

Source: https://ssd-disclosure.com/archives/3987/ssd-advisory-fortigate-dhcp-stored-xss

An unauthenticated attacker can trigger a Stored XSS Vulnerability via a malicious DHCP packet in the Fortigate DHCP Monitor.

This can happen if Device Detection is enabled through Network >Interface > Edit Interface > Device Detection

  


 When this option is enabled the attacker may perform the following steps in order to exploit the vulnerability:

1. Install dhtest or any other tool that can send arbitrary DHCP packets.
   (https://sargandh.wordpress.com/2012/02/23/linux-dhcp-client-simulation-tool/)
2. Send a malicious DHCP packet. For example:
   
   #./dhtest-master/dhtest -i eth0 -m 12:34:56:78:90:12 -h "x<svg onload=alert();)>x" [Option] -m : mac address -h : hostname(dhcp option 12). The attacker can inject malicious scripts.

   1 2 3 4

   #./dhtest-master/dhtest -i eth0 -m 12:34:56:78:90:12 -h "x<svg onload=alert();)>x"     [Option]     -m : mac address     -h : hostname(dhcp option 12). The attacker can inject malicious scripts.

Apple iPhone/iPad iOS IPSec IKEv2 Proposals

When setting up VPN-tunnel from an Apple iPhone or iPad running iOS using IPSec with IKEv2 you need to know, which IPSec proposals the iPhone/iPad/iOS device are supporting/offering:

Offered proposals from iOS

Testing with an iPhone running iOS 12.4.1 and iPad 13.1.2:

• AES256-SHA256-DH14 (2048-bit MODP Group) <------ (✔ okay)
• AES256-SHA256-DH19 (256-bit random ECP group) <------ (✅ recommended)
• AES256-SHA256-DH5 (1536-bit MODP Group) <------ (❌not recommended)
• AES128-SHA1-DH2 (1024-bit MODP Group) <------ (❌not recommended)
• 3DES-SHA1-DH2 (1024-bit MODP Group) <------ (❌not recommended)

Recommendation

Therefore I recommened 🔒✅ to use for your IPSec IKEv2 proposals:

• IKEv2 Phase1: AES-CBC-256 with SHA2-256 and DH-Grp 19 (ECP 256bit)
• IKEv2 Phase2: AES-CBC-256 with SHA2-256 and DH-Grp 19 (ECP 256bit)

DH-Grp 19 ECP 256Bit > DH-Grp 14 RSA 2048Bit
-> For example see BSI recommendation for crypto IPSec page 13 section 3.2.4  or NIST recommendation page 9 line 264

-> Details for ECP (Elliptic Curve from NIST) for IKEv1/v2 see RFC5903 or IANA ipsec registry

Details to reverse engineering

iPhone iOS 12.4.1 IKEv2 RAW output:

2019-10-27 16:25:15.519164 ike 4: incoming proposal:
2019-10-27 16:25:15.519176 ike 4: proposal id = 1:
2019-10-27 16:25:15.519185 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519195 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519205 ike 4:         type=ENCR, val=AES_CBC (key_len = 256)
2019-10-27 16:25:15.519215 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
2019-10-27 16:25:15.519224 ike 4:         type=PRF, val=PRF_HMAC_SHA2_256
2019-10-27 16:25:15.519234 ike 4:         type=DH_GROUP, val=MODP2048.
2019-10-27 16:25:15.519246 ike 4: proposal id = 2:
2019-10-27 16:25:15.519255 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519264 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519274 ike 4:         type=ENCR, val=AES_CBC (key_len = 256)
2019-10-27 16:25:15.519283 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
2019-10-27 16:25:15.519293 ike 4:         type=PRF, val=PRF_HMAC_SHA2_256
2019-10-27 16:25:15.519303 ike 4:         type=DH_GROUP, val=ECP256.
2019-10-27 16:25:15.519314 ike 4: proposal id = 3:
2019-10-27 16:25:15.519323 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519332 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519342 ike 4:         type=ENCR, val=AES_CBC (key_len = 256)
2019-10-27 16:25:15.519353 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
2019-10-27 16:25:15.519365 ike 4:         type=PRF, val=PRF_HMAC_SHA2_256
2019-10-27 16:25:15.519374 ike 4:         type=DH_GROUP, val=MODP1536.
2019-10-27 16:25:15.519384 ike 4: proposal id = 4:
2019-10-27 16:25:15.519392 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519400 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519408 ike 4:         type=ENCR, val=AES_CBC (key_len = 128)
2019-10-27 16:25:15.519416 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA_96
2019-10-27 16:25:15.519424 ike 4:         type=PRF, val=PRF_HMAC_SHA
2019-10-27 16:25:15.519432 ike 4:         type=DH_GROUP, val=MODP1024.
2019-10-27 16:25:15.519443 ike 4: proposal id = 5:
2019-10-27 16:25:15.519451 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519459 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519466 ike 4:         type=ENCR, val=3DES_CBC
2019-10-27 16:25:15.519474 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA_96
2019-10-27 16:25:15.519482 ike 4:         type=PRF, val=PRF_HMAC_SHA
2019-10-27 16:25:15.519490 ike 4:         type=DH_GROUP, val=MODP1024.

 

FortiOS update with versions 5.2.14/5.4.12/5.6.10/6.0.5/6.2.1

Fortinet released two "Customer Support Bulletins" (check fortinet support portal) regarding a possible issue with uninterruptible upgrade in FortiGate HA-clusters running version FortiOS 5.2.14 or 5.4.12 or 5.6.10 or 6.0.5 or 6.2.1. Please check the two Customer Support Bulletins before upgrading and plan a possible short downtime for the update.

FortiGate default configuration does not verify the LDAP server identity - CVE-2019-5591

I have found a vulnerability in all FortiOS versions, including the current 5.4/5.6/6.0/6.2 branches. The issue has been fixed in 6.0.3/6.2.1 by using the new feature "server-identity-check":
 

The vulnerability is in the LDAPS connection of the FortiGate to a LDAP-Server. The FortiGate does not properly check the certificate sent from the LDAP-Server, allthough the correct CA certificate is configured. More details will be published later.

Fortinet PSIRT-team responded quickly, has acknowledged the issue, told me that some one else also reported the issue, assigned CVE-2019-5591 to it and released the following PSIRT advisory: https://fortiguard.com/psirt/FG-IR-19-037

Solution:

Update to FortiOS 6.0.3+ or 6.2.1+ and set the following option:


config user ldap
edit ldap-server
set server-identity-check enable