Technical Tip: Description of CVE-2020-12812 (bypassing two-factor authentication for LDAP users) and remediation options

[Debbie_FTNT]

Description
This articles 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

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:

1) 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.

2) The same users need to be member of a group on LDAP server
Example: user jsmith is a member of 'Domain Users', 'Helpdesk' and 'VPN Users'.

3) 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, the 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 in regard to username.
The FortiGate will then retrieve group memberships of the user, and discover that the user is 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

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:

1) 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 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 in has an LDAP server as member configured on FortiGate.
If there is one, and that token group is used in an SSLVPN 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.

2) 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 token).

3) 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 prompt a Token if a Token is associated with the username.

Related Articles

Technical Note - Configuring Remote LDAP users with Two-Factor Authentication