A design flaw in the Fortinet VPN server’s logging mechanism can be leveraged to conceal the successful verification of credentials during a brute-force attack without tipping off defenders of compromised logins.

Although the brute-force attack is still visible, a new technique allows logging only failed attempts and not successful ones, generating a false sense of security.

Verifying VPN credentials

The FortiClient VPN server stores login activity using a two-step process that consists of an authentication and an authorization stage.

Researchers at Pentera, a company providing automated security validation solutions, discovered that a successful login is recorded only if the process passes both the authentication and the authorization steps; otherwise, FortiClient VPN will log a failed authentication.

“[…] the failed ones are logged in the authentication phase but the successful ones are logged in the authorization phase, so yes, a full login with either a script or a VPN client would create a log,” Pentera security researcher Peter Viernik told BleepingComputer.

In a report today, the cybersecurity company describes how its researchers devised a method to stop the full login process after the authentication stage, allowing them to validateVPN credentials without logging the success.

The researchers used the Burp application security testing tool to record the interactions between the client and the VPN server.

They noticed that the response to the initial HTTPS request shows valid credentials (through a “ret=1” value), a failed authentication (“ret=0”), or “An error occurred” response in case of multiple consecutive failed attempts.

In simpler terms, authentication just confirms that the credentials are valid and authorization establishes a VPN session.

However, if the process is stopped after the authentication stage, the VPN server only logs the failed attempts, and not the successful ones, since it did not continue to the next authorization step.

The issue generated this way is that an incident response team can’t determine if a brute-force attempt in such an attack was successful and will only see logs for failed processes.

The failed authentication attempts will still tip off an Fortinet admin that their device is under a brute-force attack and allow them to potentially block the attempts.

However, they will not know that the attacker was able to successfully verify credentials. These credentials can then be sold to other threat actors or used at a later time to breach the network, when the admins are no longer alert to the malicious activity.

It is worth noting that even if a threat actor determines a correct login set and uses them in an attack, the authorization process completes only after FortiClient VPN sends two API calls that verify the device’s security compliance and the user’s access level.

This check complicates the attack significantly but a well-resourced attacker could still use Pentera’s method to breach an organization’s network.

Pentera says that they shared the research with Fortinet and the company replied by saying it did not consider the issue a vulnerability. It is unclear if Fortinet will address the problem, especially since it is not a complicated fix.

As part of today’s disclosure, Pentera released a script that exploits this design flaw to verify Fortinet VPN credentials.

BleepingComputer reached out to Fortinet for a comment on the issue yesterday but a statement was not available before publishing time.