200K Businesses are Exposed to WFH Attack Scenario

Research by Niv Hertz and Lior Tashimov / SAM’s IoT Security Lab

Identifying the Fort

Many have written, and probably more will be told about the dramatic change in the way each of us works remotely following the Covid-19 pandemic. As security researchers, we have been trying to assess whether the existing security solutions address the new situation. We noticed that many companies are resulting in requiring employees to connect to the office via VPN. Whether it’s because of on-site data centers or IP anchoring, many small businesses (less than 20 employees) use a VPN server that is usually also the company’s gateway. Not too long after we began our research, the name FortiGate was thrown into the air. We instantly grabbed the FortiGate that we kept as a backup in the office and began exploring.

Surprisingly (or not?), 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. We’ve searched and found over 200k vulnerable businesses in a matter of minutes.

  1. Compromised IoT initiates MITM attack using ARP Poisoning
  2. Forticlient initiate VPN connection
  3. IoT device serves signed Fortinet certificate extracted from legacy credentials
  4. Forward the credentials to the original server, while stealing them in the middle
  5. Spoofed Authentication

Technical deep-dive

To understand the issue with Fortinet’s implementation, we must first go through the very base of the SSL certificate chain verification process. SSL uses encryption based on asymmetric key-pair. The private key, that is known only to the server, is used to decrypt (read) 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 interesting values, however we will only focus on a couple of them:

  • Server name – The name of the server this certificate was issued to
  • Public key – The public key used to encrypt the traffic to this server
  • Digital Signature – A digital signature that verifies this certificate was issued by a legitimate authority.
  • Validity – A date this certificate is valid through
  • Issuer information – Information about the issuer of the certificate (the same entity that signed the certificate)

Normally when a client connects to a server, the client verifies the following information:

  • The certificate’s Server Name matches the server that the client attempted to connect to
  • The certificate validity date has not passed
  • The certificate’s digital signature is correct
  • The certificate was issued by an authority that this client trusts

Now that we grasp the basics of the certificate validation process, going back to Fortinet’s client, there is clearly a major issue. The Fortigate router comes with a default SSL certificate that is signed by Fortinet (Self-signed, that is, it was not issued by a trusted CA). Each Fortigate has its own certificate that uses the router’s serial number as the server name for the certificate. An example certificate can be seen here:

Fortigate Example Certificate

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. 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, and it was issued either by Fortinet or any other trusted CA. An attacker can easily re-route the traffic to his server, display his own certificate, and then decrypt the traffic. To prove this is feasible, we’ve set up the following POC:

Man in the middle attack POC – video opens in new window

In this video you can how we decrypt the traffic of the Fortinet SSL-VPN client and extract the user’s password and OTP. 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.

Fortinet’s Response

We reached out to Fortinet to portray this issue (and offered an easy solution), they responded that they are well aware of it, but are not going to change it. They claim that since the user has the ability to manually replace the certificate, it is the user’s responsibility to make sure the connection is protected. Although Fortinet’s claim may be reasonable for the enterprise space, smaller businesses (for example a small law firm) may not have the knowledge or time to configure it.

Moreover, there is no clear warning by Fortinet to the user, that this major security flaw exists when using the default certificate. Instead, a vague message is displayed:

Fortinet’s vague warning

This message is far from sufficient to cause even an experienced IT manager to replace the certificate, let alone a SMB owner with no cybersecurity expertise.

We decided to take the research a step forward, and check how many Fortinet devices are vulnerable to this type of attack. Using the Shodan.io database, we’ve found ~230k Fortigate devices that are using the VPN functionality. Out of these, roughly 88%, that is over 200k (!) Businesses that are using the default configuration and can be easily breached using this MITM method.

Conclusion

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. Smaller businesses require leaner, seamless, easy-to-use security products that may be less flexible, but provide much better basic security.