Fortinet zei woensdag dat het onder bepaalde configuraties ‘recent misbruik’ van een vijf jaar oud beveiligingslek in FortiOS SSL VPN in het wild heeft waargenomen.
De kwetsbaarheid in kwestie is CVE-2020-12812 (CVSS-score: 5.2), een onjuiste authenticatiekwetsbaarheid in SSL VPN in FortiOS waardoor een gebruiker succesvol kon inloggen zonder dat om de tweede authenticatiefactor werd gevraagd als het hoofdlettergebruik van de gebruikersnaam werd gewijzigd.
“Dit gebeurt wanneer tweefactorauthenticatie is ingeschakeld in de ‘user local’-instelling en dat gebruikersauthenticatietype is ingesteld op een externe authenticatiemethode (bijvoorbeeld LDAP)”, merkte Fortinet in juli 2020 op. “Het probleem bestaat vanwege inconsistente hoofdlettergevoelige overeenkomsten tussen de lokale en externe authenticatie.”
De kwetsbaarheid is sindsdien in het wild actief uitgebuit door meerdere bedreigingsactoren, waarbij de Amerikaanse overheid het ook noemt als een van de vele zwakke punten die in 2021 werden ingezet bij aanvallen op perimeter-type apparaten.
In een nieuw advies van 24 december 2025 merkte Fortinet op dat het succesvol activeren van CVE-2020-12812 vereist dat de volgende configuratie aanwezig is:
- Lokale gebruikersinvoer op de FortiGate met 2FA, terugverwijzend naar LDAP
- Dezelfde gebruikers moeten lid zijn van een groep op de LDAP-server
- Er moet ten minste één LDAP-groep waarvan de tweefactorgebruikers lid zijn, worden geconfigureerd op FortiGate, en de groep moet worden gebruikt in een authenticatiebeleid dat bijvoorbeeld administratieve gebruikers, SSL of IPSEC VPN kan omvatten.
Als aan deze vereisten is voldaan, zorgt het beveiligingslek ervoor dat LDAP-gebruikers met 2FA-configuratie de beveiligingslaag omzeilen en zich in plaats daarvan rechtstreeks bij LDAP authenticeren, wat op zijn beurt het gevolg is van het feit dat FortiGate gebruikersnamen als hoofdlettergevoelig behandelt, terwijl de LDAP-directory dat niet doet.
“Als de gebruiker inlogt met ‘Jsmith’, of ‘jSmith’, of ‘JSmith’, of ‘jsmiTh’ of iets dat NIET exact overeenkomt met ‘jsmith’, zal de FortiGate de login niet matchen met de lokale gebruiker”, legt Fortinet uit. “Deze configuratie zorgt ervoor dat FortiGate andere authenticatie-opties overweegt. FortiGate zal andere geconfigureerde firewall-authenticatiebeleidsregels controleren.”
“Nadat het niet lukt om jsmith te matchen, vindt FortiGate de secundair geconfigureerde groep ‘Auth-Group’ en van daaruit de LDAP-server. Op voorwaarde dat de inloggegevens correct zijn, zal de authenticatie succesvol zijn, ongeacht eventuele instellingen binnen het lokale gebruikersbeleid (2FA en uitgeschakelde accounts). “
Als gevolg hiervan kan de kwetsbaarheid beheerders- of VPN-gebruikers authenticeren zonder 2FA. Fortinet heeft FortiOS 6.0.10, 6.2.4 en 6.4.1 uitgebracht om het probleem aan te pakken in juli 2020. Organisaties die deze versies niet hebben geïmplementeerd, kunnen de onderstaande opdracht uitvoeren voor alle lokale accounts om het probleem van het omzeilen van de authenticatie te voorkomen:
set gebruikersnaam-hoofdlettergevoeligheid uitschakelen
Klanten die FortiOS-versies 6.0.13, 6.2.10, 6.4.7, 7.0.1 of hoger gebruiken, worden geadviseerd de volgende opdracht uit te voeren:
gebruikersnaamgevoeligheid instellen uitschakelen
“Als de gebruikersnaamgevoeligheid is uitgeschakeld, zal FortiGate jsmith, JSmith, JSMITH en alle mogelijke combinaties als identiek behandelen en zo failover naar andere verkeerd geconfigureerde LDAP-groepsinstellingen voorkomen”, aldus het bedrijf.
Als aanvullende oplossing is het de moeite waard om te overwegen om de secundaire LDAP-groep te verwijderen als deze niet nodig is, omdat hierdoor de hele aanvalslijn wordt geëlimineerd, aangezien authenticatie via de LDAP-groep niet mogelijk zal zijn en de authenticatie van de gebruiker zal mislukken als de gebruikersnaam niet overeenkomt met een lokale invoer.
De nieuw uitgegeven richtlijnen geven echter geen details over de aard van de aanvallen waarbij gebruik wordt gemaakt van de fout, noch over de vraag of deze incidenten succesvol waren. Fortinet heeft betrokken klanten ook geadviseerd contact op te nemen met het ondersteuningsteam en alle inloggegevens te resetten als ze bewijs vinden dat beheerders of VPN-gebruikers zijn geauthenticeerd zonder 2FA.
