Description
This article describes the details of CVE-2020-12812, how two-factor authentication can be bypassed in the first place, what prerequisites there are, and what options FortiGate offers to prevent the vulnerability from being exploited.
Related link:
https://fortiguard.com/psirt/FG-IR-19-283
Scope
FortiGuard, FortiGate.
Solution
FortiGates can, under certain circumstances, allow LDAP users with two-factor authentication configured to bypass the second factor and instead authenticate against LDAP directly.
This is caused by FortiGate treating usernames as case-sensitive by default, which LDAP does not.
Some configuration needs to be in place on the FortiGate for this to be possible:
- Local user entries on the FortiGate with two-factor authentication, referencing back to LDAP:
config user local
edit jsmith
set type ldap
set ldap-server LDAP1
set two-factor fortitoken
set fortitoken FTKxxxxxxxxxxxxxxxxxx
end
Note:
While the example uses FortiToken, this also applies to other methods like email or SMS Token.
- The same users need to be members of a group on the LDAP server.
Example: user jsmith is a member of 'Domain Users', 'Helpdesk', and 'VPN Users'.
- At least one LDAP group the two-factor users are a member of needs to be configured on FortiGate, and the group needs to be used in a VPN policy (policy with source interface ssl.root or ssl.<vdom>).
config user group
edit VPN-Group
set member LDAP1
config match
edit 1
set server-name LDAP1
set filter "CN=VPN Users, OU=[...]"
end
end
With those prerequisites in place, the issue can be triggered as follows:
If the user logs into VPN with 'jsmith', the token is requested, as this matches the local user.
If the user logs in with 'Jsmith', or 'jSmith', or 'JSmith', or 'jsmiTh' or anything that is NOT an exact case match to 'jsmith', the FortiGate will not match the login against the local user.
This causes the FortiGate to consider other authentication options.
The FortiGate will check through SSLVPN firewall policies, and collect user groups from them.
From the user groups, it will compile authentication servers and then attempt to authenticate the user against the authentication servers.
In this example, FortiGate finds the group 'VPN-Group', and from it the LDAP server 'LDAP1'.
It attempts to authenticate the user against LDAP1.
Provided the credentials are correct, this is successful, as LDAP is case-insensitive concerning username.
The FortiGate will then retrieve group memberships of the user, and discover that the user is a member of the group 'VPN Users'.
The LDAP group 'VPN Users' matches the group on FortiGate called 'VPN-Group', and thus the user is authenticated successfully against LDAP through the user group WITHOUT any token being requested.
The user will have access to anything that the LDAP group has outright access to through firewall policies, but NOT access to resources through policies explicitly configured with the local user entry.
In firmware versions where the CVE is fixed (6.0.10, 6.2.4, 6.4.1), a CLI option has been added to the 'config user local' entry:
config user local
edit jsmith
set type ldap
set ldap-server LDAP1
set two-factor fortitoken
set fortitoken FTKxxxxxxxxxxxxxxxxxx
set username-case-sensitivity enable/disable
end
From v5.6.14, v6.0.13, v6.2.10, v6.4.7, v7.0.1, and the above versions, the syntax for the same command above has been changed to 'username-sensitivity':
config user local
edit jsmith
set username-sensitivity enable/disable
end
If case-sensitivity is enforced, the behavior will remain. Case-sensitivity is ENABLED by default.
If case-sensitivity is not enforced, then the user can log in with any capital/non-capital letter variation of his username, but the token will still be required, ensuring this behavior cannot occur.
FortiGate offers some other configuration options to prevent possible bypassing independent of firmware version, though these options can require a redesign of LDAP structure:
- Keep token and non-token users in separate LDAP groups and only use non-token LDAP groups in FortiGate.
This interrupts the process outlined above after the credentials have been validated.
FortiGate will still check for groups, get the LDAP server(s) from the groups, and authenticate the user against LDAP.
When fetching the token user’s group memberships, it will find that the token user is NOT a member in any non-token group that the FortiGate accepts, and so the authentication fails due to group restrictions.
This requires that NO group the token-user is a member of has an LDAP server as a member configured on FortiGate.
If there is one, and that token group is used in an SSL VPN policy, the same behavior can be triggered.
The user is found via a group on LDAP but the locally defined user is not checked against, no token is required.
- Do not use any LDAP groups at all.
If no LDAP groups are used at all, no authentication via LDAP group is possible, and the user will fail authentication if the username is not a match to a local entry.
This does have issues with scalability, as EVERY user that is allowed to log in needs to have a local user entry (with or without a token).
- Use FortiAuthenticator.
Using FortiAuthenticator to associate tokens and LDAP users removes this burden from FortiGate, and FortiGate is no longer concerned about capital/non-capital letters in usernames.
On FortiGate, the FortiAuthenticator exists as a RADIUS server, with one or more user groups pointing to this RADIUS server.
FortiGate sends the credentials to FortiAuthenticator, which does NOT treat usernames as case-sensitive.
FortiAuthenticator matches the username against its database and prompts a Token if a Token is associated with the username.
Related article:
Technical Note - Configuring Remote LDAP users with Two-Factor Authentication
