Fortinet's FortiOS is the backbone for many organizations' firewalls, VPNs, and cloud gateways. However, between specific versions (6.. up to 7..), a critical vulnerability—CVE-2022-22306—left many FortiGate devices exposed to man-in-the-middle (MitM) attacks. This article explores what went wrong, how an attacker could exploit it, and what you should do if you're running a vulnerable version.

What is CVE-2022-22306?

CVE-2022-22306 is an *improper certificate validation* vulnerability (see CWE-295) in several FortiOS versions:

7.. specifically

The issue is found in how FortiOS checks (or, in this case, doesn't fully check) the certificates presented by some peers like private SDNs (Software Defined Networks) and external cloud platforms.

The Core Problem

FortiOS, when connecting to certain external services, *doesn't* properly validate the SSL/TLS certificate chain. This flaw lets an attacker who is on the same network (network-adjacent) hijack and alter secure communications by presenting a fake certificate.

Normally, devices only trust certificates signed by authorized CAs. With this bug, even untrusted or spoofed certificates may be accepted—rendering SSL/TLS protections useless in affected situations.

Who Can Attack?

- Network-adjacent: The attacker must be on the same network segment as the FortiGate device or otherwise able to intercept its traffic.
- No authentication needed: The attacker does not need to log in or otherwise authenticate to run this exploit.

Real-World Attack Scenario

Imagine your FortiGate is tightly linked to your cloud provider for remote logging, SDN orchestration, or similar services. An attacker on your network could perform a MitM attack—intercepting and possibly modifying data, stealing credentials, or causing denial of service.

Here's a simplified, Python-based illustration of incorrect certificate validation

import ssl
import socket

# BAD: Allowing any certificate, even those not signed by trusted CAs
def insecure_ssl_connection(host, port):
    context = ssl._create_unverified_context()  # bypasses all validation!
    sock = socket.create_connection((host, port))
    ssl_sock = context.wrap_socket(sock, server_hostname=host)
    print("Connected to", host)
    # No exception raised - even if cert is wrong!

# Connect (this will work even with a rogue certificate on the server)
insecure_ssl_connection('malicious-actor.com', 443)

In vulnerable FortiOS versions, the application logic responsible for handling certificate chains had a similarly lax approach in some communications.

A typical attack path might look like this

1. Positioning: Attacker gets on the same LAN/subnet as the FortiGate (e.g., rogue device in the data center).
2. Interception: Leverages ARP spoofing, DHCP attacks, or poisoning the network routing to intercept traffic between FortiOS and its peers.
3. Impersonation: Presents a self-signed or attacker-controlled certificate when FortiOS initiates a connection.
4. MitM Success: Because FortiOS doesn't correctly validate the certificate, the connection proceeds, and the attacker is now in the middle.

Here's a tool invocation (e.g., with mitmproxy) that could be used once traffic is flowing through the attacker:

mitmproxy --mode transparent --ssl-insecure

This command would allow the attacker to view and manipulate the traffic.

Original References

- Fortinet Security Advisory - FG-IR-22-094  
- CVE-2022-22306 Entry  
- National Vulnerability Database NVD Entry  
- CWE-295: Improper Certificate Validation

Mitigation and Updates

Fortinet has resolved this issue in later releases. If you are running any affected version, you *must* upgrade to a safe release (check the advisory for your specific branch).

Isolate your FortiGate devices from any untrusted or semi-trusted local networks.

- Monitor for MITM attacks: Use network monitoring to detect unusual ARP/spoofing behavior.

Conclusion

CVE-2022-22306 is a classic example of how skipping or mishandling certificate validation can shatter assumptions of security in network devices. For any organization relying on FortiOS, this underlines the necessity of patching and of validating all layers of trust in your network stack.

If you want to read in detail, check out the official advisory and NVD's analysis.

Timeline

Published on: 05/24/2022 15:15:00 UTC
Last modified on: 06/06/2022 18:22:00 UTC