More than 200,000 businesses that have deployed Fortigate VPN are vulnerable to MitM attacks. A successful attack could allow a threat actor to present a valid SSL certificate and fraudulently take over a connection.
"We quickly found that under default configuration the SSL VPN is not as protected as it should be, and is vulnerable to MITM attacks quite easily. The Fortigate SSL-VPN client only verifies that the CA was issued by Fortigate (or another trusted CA), 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”, SAM IoT Security Lab's Niv Hertz and Lior Tashimov said.
Researchers set up a compromised IoT device that's used to trigger a MitM attack soon after the Fortinet VPN client initiates a connection, which then steals the credentials before passing it to the server and spoofs the authentication process.
SSL uses encryption based on asymmetric key-pair. The private key, that is known only to the server, is used to decrypt the data. The public key, that is distributed to anyone who wishes to access the server, is used to encrypt the data, that way, only the server can decrypt the messages sent from the client. The public key is transferred to the clients in a format of a public certificate. The certificate includes many values, such as server name, public key, digital signature, a date this certificate is valid through and information about the issuer of the certificate
Normally when a client connects to a server, the client verifies if the certificate’s server name matches the server that the client attempted to connect to, the validity date, digital signature and if the certificate was issued by an authority that this client trusts.
The Fortigate router comes with a default self-signed SSL certificate that is signed by Fortinet. Each Fortigate has its own certificate that uses the router’s serial number as the server name for the certificate. An attacker can easily re-route the traffic to his server, display his own certificate, and then decrypt the traffic.
The problem is that the default SSL certificate uses the serial number of the router as the server name for the certificate. While Fortinet can use the router's serial number to verify that the server names match, it looks like the client does not verify the server name at all, resulting in fraudulent authentication.
According to Fortinet, the company is well aware of this problem and is not going to fix it. Since the user has the ability to manually replace the certificate, it is the user’s responsibility to make sure the connection is protected.
Currently, Fortinet provides a warning when using the default certificate: "You are using a default built-in certificate, which will not be able to verify your server's domain name (your users will see a warning). It is recommended to purchase a certificate for your domain and upload it for use."