FortiGate VPN Default Config Allows MitM Attacks

Default configurations of Fortinet’s FortiGate VPN appliance could open organizations to man-in-the-middle (MitM) attacks, according to researchers, where threat actors could intercept important data.

According to the SAM IoT Security Lab, the FortiGate SSL-VPN client only verifies that the certificate used for client authentication was issued by Fortinet or another trusted certificate authority.

“Therefore, an attacker can easily present a certificate issued to a different FortiGate router without raising any flags, and implement a man-in-the-middle attack,” researchers wrote, in an analysis on Thursday.

They added, “An attacker can actually use this to inject his own traffic, and essentially communicate with any internal device in the business, including point of sales, sensitive data centers, etc. This is a major security breach, that can lead to severe data exposure.”

A Shodan search turned up more than 230,000 vulnerable FortiGate appliances using the VPN functionality, researchers found. Out of those, a full 88 percent, or more than 200,000 businesses, are using the default configuration and can be easily breached in an MitM attack.

Underneath the Hood

According to SAM, in a typical SSL certificate verification process, the client can connect to a server only after verifying that the certificate’s Server Name field matches the actual name of the server that the client is attempting to connect to; that the certificate validity date has not passed; that the digital signature is correct; and that the certificate was issued by an authority that the client trusts.

In the case of the FortiGate router, it uses a self-signed, default SSL certificate, and it uses the router’s serial number to denote the server for the certificate – it does not, according to SAM, verify that the actual server name parameter matches.

“This leaves Fortinet with enough information to verify the certificate was issued to the same server the client is trying to connect to, if it were to verify the serial number,” according to researchers. “However, Fortinet’s client does not verify the Server Name at all. In fact, any certificate will be accepted, so long as it is valid.”

SAM published a proof-of-concept (PoC) how an attacker could easily re-route the traffic to a malicious server, displaying his or her own certificate, and then decrypt the traffic.

“We decrypt the traffic of the Fortinet SSL-VPN client and extract the user’s password and [one-time password],” researchers explained.

Fixing the Issue

While the issue exists in the default configuration of the FortiGard SSL-VPN client, Fortinet does not consider the issue to be a vulnerability, because users have the ability to manually replace the certificate in order to secure their connections appropriately.

“The security of our customers is our first priority. This is not a vulnerability,” the firm told Threatpost. “Fortinet VPN appliances are designed to work out-of-the-box for customers so that organizations are enabled to set up their appliance customized to their own unique deployment. Each VPN appliance and the set up process provides multiple clear warnings in the GUI with documentation offering guidance on certificate authentication and sample certificate authentication and configuration examples. Fortinet strongly recommends adhering to its provided installation documentation and process, paying close attention to warnings throughout that process to avoid exposing the organization to risk.”

SAM researchers noted that Fortinet’s approach “may be reasonable for the enterprise space,” but “smaller businesses (for example a small law firm) may not have the knowledge or time to configure it.”

They added, “the Fortigate issue is only an example of the current issues with security for the small-medium businesses, especially during the epidemic work-from-home routine. These types of businesses require near-enterprise grade security these days, but do not have the resources and expertise to maintain enterprise security systems.”