Title: Fortinet FortiClient Windows privilege escalation at logon
CVE ID: CVE-2017-7344
Intrinsec ID: ISEC-V2017-01
Risk level: high
Exploitable: Locally, or remotely if the logon screen is exposed (e.g. through RDP without NLA required). Requires non-default configuration on the client (“Enable VPN before logon”). Requires an invalid certificate on the VPN endpoint side, or a MITM attacker presenting an invalid certificate (e.g. stolen laptop scenario).
Impact: Privilege escalation: from anonymous to SYSTEM, and Windows lock screen bypass
This vulnerability affects the Fortinet FortiClient program. FortiClient is a client program used to connect to SSL/IPsec VPN endpoints.
A setting, disabled by default, enables FortiClient on the logon screen to allow users to connect to a VPN profile before logon. An attacker, with physical, or remote (e.g. through TSE, VNC…), access to a machine with FortiClient and this feature enabled, can obtain SYSTEM level privileges from the lock screen. No account or prior knowledge is required.
The vulnerability lies in the confirmation dialog shown when the server certificate is not valid (e.g. default auto-signed certificate, or Man-In-The-Middle with SSL/TLS interception situation).
- FortiClient Windows 5.6.0
- FortiClient Windows 5.4.3 and earlier
Upgrade to FortiClient Windows 5.4.4 or 5.6.1.
However, we tested the latest version and we discovered some bypasses of the fix under certain circumstances. We have shared our findings with Fortinet who is working on a more complete fix. We do not intend to share more details until this issue is fixed.
Enabling the “Do not warn invalid server certificate” option would prevent this issue but it is strongly discouraged since it allows silent Man-in-the-Middle attacks.
Deploying a valid certificate on the VPN endpoint mitigates the issue in standard situations, however when an attacker is in a MITM situation they will present an invalid certificate to the FortiClient, regardless of the legitimate server certificate. This is not sufficient to resolve the issue.
Vulnerability discovered by Clément Notin / @cnotin.
Vulnerability disclosed in coordination with the CERT-Intrinsec.
Windows 7 Professional x64, English. FortiClient, vulnerable version:
Create VPN connection in FortiClient with a FortiGate endpoint (or try with any domain having an invalid certificate, such as expired.badssl.com):
Enable the “VPN before logon” setting in FortiClient:
Log off. The computer is now in a vulnerable state.
On the logon screen, select the VPN profile and type any password for the user. If the certificate is invalid (default certificate on a legitimate FortiGate, MITM attack, usage of the IP address of the endpoint instead of the hostname…), when connecting the confirmation dialog will appear, then click on “View certificate”:
Go to “Details” tab then click on “Copy to file”:
Click next until the screen with “Browse” button:
Browse to “C:\Windows\System32”, type a wildcard “*” in filename to show every files. Find cmd.exe, right click then click “Open”:
You get a shell with SYSTEM privileges:
The attacker can create a local administrator user account and use it to login:
Fortinet PSIRT Advisory: FG-IR-17-070
SecurityFocus: BID 102176
- 2017-02-27: Vulnerability discovery, advisory sent to Fortinet that acknowledges the reception.
- 2017-03-15: Intrinsec asks for status update
- 2017-05-04: Fortinet confirms the vulnerability, assigns CVE-2017-7344 and plans the fix for the future 5.6 version.
- 2017-06-08: ETA for fixed versions set in June
- 2017-07-05: Intrinsec asks for status update
- 2017-07-11: Intrinsec discovers that FortiClient 22.214.171.1245, that was supposed to include the fix, is still vulnerable
- 2017-08-25: Fortinet clarifies the purpose of the fix and confirms that it is incomplete. New ETA is set to end of September for FortiClient 5.6.1.
- 2017-12-07: Intrinsec asks for status update
- 2017-12-11: Fortinet is finalizing the advisory and plans to publish it during the week
- 2017-12-13: Fortinet publishes the advisory
- 2017-12-13: Intrinsec advises against some proposed mitigations
- 2017-12-13: Fortinet updates the advisory
- 2017-12-18: Intrinsec finds bypasses of the published fix and shares the details with Fortinet
- 2017-12-21: Fortinet confirms the bypasses
- 2017-12-22: Intrinsec publishes its advisory with detailed explanations, with Fortinet’s approval
— Clément Notin