During the early stages of the pandemic, a client reached us asking about their VPN security. As security professionals, we always do our due diligence and shout “its not secure!!”. Is that what we say by default, as security professionals? While it’s true, some of us get a bit dramatic about it.

Working remotely is the new norm and the quickest security fix that companies use is the VPN services. Without the VPN, the employees will not be able to access company resources. While this is a good measure, like any security measures, it is not 100% secure. In fact, it can even give you a false sense of security.

After following the scope discussions, NDA, and other requirements, we took on the assignment to test the client’s VPN security. The client was using Fortinet SSL VPN v6.0.2, which is from Fortigate, is recognized globally, so you think it must be secure right?

Threat Model

Being intimidated, we strategized our approach and decided to test VPN like any web-application. To start with, we conducted a passive recon, checked on open-source vulnerability databases, such as the CVE and the Fortigate website for any publicly known vulnerabilities. Then, created a threat model using STRIDE framework and assigned all the attack methods and potential vulnerabilities in each component of STRIDE, such as Spoofing, Tampering, Repudiation, Information Disclosure, Elevation of Privilege. Refer the Threat Model image.

Following the threat model, we conducted the VAPT on Fortinet’s SSL VPN. This was our first VAPT on a Fortigate product, so we were excited to see what we could find.

After testing, we found three vulnerabilities with a risk score higher than 7.5, which was under high or critical. We also found other medium vulnerabilities, such as cross-site scripting, untrusted SSL certificate, etc. But the essence of our testing was the high and critical vulnerabilities.

Vulnerability: Open Sesame (CVE-2018-13379)

Fortinet VPN v6.0.2 has a directory traversal path vulnerability. This vulnerability enabled to view the User-ID, Password, access level and the IP addresses of active VPN users at that time of attack. It is like saying “Open Sesame” to get all the users’ login credentials. Refer to the image.

Vulnerability: Abraca-dabra (CVE-2018-13382)

Another vulnerability in this version of Fortinet is that it has a magic keyword to change the password for any users. It is an Improper Authorization vulnerability that allows an attacker to change the password of a user with crafted HTTP requests. By using an exploit script (github weblink https://github.com/milo2012/CVE-2018-13382), we can instantly change one of the logged-in users password .Refer to the image.

Vulnerability: Terminator (CVE-2018-13379 and CVE-2018-13382)

By chaining the last two CVE vulnerabilities, you can get a shell access to the network device. The process includes crashing the system, so be very cautious when you attempt this. When we tried this a few times, we ended up crashing it but without shell. Then decided not to go further with it because we didn’t want to push the system way further and cause any damages to our client network. Since we were able to crash it, we are certain that this flaw existed on their Fortigate version. Credit to Orange Tsai for the vulnerability exploit.

Well, there you have it. Fortigate SSL VPNv6 is not as secure as our client thought it is. Fortunately, Fortigate has released patches to make up for these flaws. Remember to always keep your devices updated and get an external party to test your systems, preferably our Arche professionals. But, in general, VPN services are a good measure to secure your perimeter. However, considering the pandemic induced remote workforce, we should not rely on it too much and prevail with a false sense of security.