Wprowadzenie do problemu / definicja luki
Fortinet ostrzega, iż podatność CVE-2020-12812 w komponencie FortiOS SSL VPN – znana od 2020 r. – jest ponownie (lub nadal) aktywnie nadużywana w realnych atakach. Mechanizm błędu pozwala w określonych konfiguracjach zalogować się bez wywołania drugiego czynnika (FortiToken), czyli de facto ominąć 2FA/MFA na bramie VPN.
To istotny sygnał operacyjny, bo mówimy o klasie ataków na urządzenia brzegowe (VPN/firewall), gdzie pojedynczy błąd w uwierzytelnianiu potrafi otworzyć drogę do przejęcia kont VPN lub choćby administracyjnych.
W skrócie
- CVE: CVE-2020-12812 (FortiOS SSL VPN)
- Co umożliwia: ominięcie wymogu 2FA dla wybranych scenariuszy logowania
- Warunek „w praktyce”: specyficzna konfiguracja z LDAP + lokalnym użytkownikiem z 2FA + politykami/grupami LDAP
- Trik atakującego: zmiana wielkości liter w nazwie użytkownika (case) powoduje, iż FortiGate nie dopasowuje wpisu lokalnego (z 2FA) i „spada” do innego mechanizmu uwierzytelnienia
- Poprawki/mitigacje: dostępne od FortiOS 6.0.10 / 6.2.4 / 6.4.1 (lipiec 2020) + ustawienia username-sensitivity
- Status ryzyka: CVE jest też odnotowane w NVD jako obecne w katalogu KEV CISA (historycznie dodane 2021-11-03)
Kontekst / historia / powiązania
Podatność została ujawniona i zaadresowana w połowie 2020 r., ale Fortinet wskazuje, iż w tej chwili obserwuje „recent abuse” tej luki „in the wild” – przy czym skuteczne wykorzystanie ma dotyczyć konkretnych (często błędnie zaprojektowanych) konfiguracji uwierzytelniania opartego o LDAP.
Z perspektywy długiego ogona ryzyka to typowy problem: urządzenia brzegowe bywają rzadziej aktualizowane, a złożone konfiguracje IAM/LDAP potrafią „przetrwać” lata. W 2021 r. luka była łączona z realnymi kampaniami (w tym ransomware), a fakt jej umieszczenia w ekosystemie ostrzeżeń rządowych (KEV) jest sygnałem, iż podatność miała już historię użycia w atakach.
Analiza techniczna / szczegóły luki
Na czym polega błąd?
Rdzeń problemu to niekonsekwentna obsługa wrażliwości na wielkość liter (case sensitivity) pomiędzy FortiGate a katalogiem LDAP.
- FortiGate domyślnie traktuje nazwy użytkowników jako case-sensitive.
- LDAP (np. katalogi w stylu AD) często działa case-insensitive.
W efekcie logowanie „jsmith” może trafić w lokalny wpis użytkownika, wymusić 2FA, ale logowanie „Jsmith” może już nie dopasować lokalnego użytkownika i uruchomić alternatywną ścieżkę uwierzytelnienia.
Jakie warunki muszą być spełnione (prerequisites)?
Fortinet opisuje dość konkretne wymagania, aby obejście 2FA było możliwe:
- Istnieją lokalne wpisy użytkowników na FortiGate z włączonym 2FA, które „odwołują się” do LDAP.
- Ci sami użytkownicy należą do grup w LDAP.
- Co najmniej jedna z tych grup LDAP jest skonfigurowana na FortiGate i użyta w polityce uwierzytelniania (np. dla adminów, SSL VPN lub IPsec VPN).
Jak wygląda scenariusz obejścia 2FA?
Mechanika (w uproszczeniu, ale technicznie wiernie) jest taka:
- Użytkownik loguje się jako jsmith → FortiGate dopasowuje lokalny wpis → żąda tokenu 2FA.
- Użytkownik loguje się jako Jsmith / jSmith / inna kombinacja → brak dopasowania wpisu lokalnego → FortiGate sprawdza inne polityki/grupy → jeżeli jest „zapasowa” grupa LDAP, uwierzytelnienie może przejść bez 2FA.
Fortinet podkreśla też, iż istotnym „katalizatorem” jest często błędna konfiguracja wtórnej (secondary) grupy LDAP, używanej jako mechanizm „failover”, gdy dopasowanie lokalne się nie powiedzie.
Ocena podatności: CVSS i rozbieżności
W NVD dla CVE-2020-12812 widnieje CVSS 3.1: 9.8 (Critical).
W części publikacji spotkasz jednak inne wartości (np. oceny vendor-owe lub historyczne), dlatego w praktyce warto patrzeć nie tylko na „cyferkę”, ale na kontekst brzegowego VPN + aktywną eksploatację + obejście 2FA.
Praktyczne konsekwencje / ryzyko
Jeśli warunki konfiguracji są spełnione, skuteczne nadużycie CVE-2020-12812 może prowadzić do:
- Nieautoryzowanego dostępu do SSL VPN (z ominięciem 2FA), co ułatwia dalszą penetrację sieci.
- Potencjalnego przejęcia uprzywilejowanych ról (np. dostęp administracyjny), jeżeli grupy/polityki są tak zbudowane.
- Konieczności traktowania konfiguracji jako potencjalnie skompromitowanej w razie wykrycia symptomów (Fortinet wprost sugeruje reset poświadczeń, także dla bindów LDAP/AD).
To szczególnie niebezpieczne, bo „ominięcie 2FA” często bywa postrzegane jako „niemożliwe”, przez co organizacje mogą mieć zbyt słabe monitorowanie ruchu i zdarzeń logowania przy VPN.
Rekomendacje operacyjne / co zrobić teraz
1) Zweryfikuj wersje i stan łatek
Minimalnie upewnij się, iż środowisko nie tkwi na liniach podatnych i iż wdrożone są mechanizmy z wersji naprawiających zachowanie:
- poprawki/mitigacje od: 6.0.10 / 6.2.4 / 6.4.1
2) Włącz „uodpornienie” na różnice w wielkości liter (username sensitivity)
Fortinet wskazuje konkretne ustawienia, które mają zapobiec scenariuszowi „failover” do LDAP bez 2FA:
Dla starszych wydań (wskazanych przez Fortinet) na kontach lokalnych:
set username-case-sensitivity disableDla nowszych wersji (m.in. 6.0.13+, 6.2.10+, 6.4.7+, 7.0.1+):
set username-sensitivity disableTo powoduje, iż FortiGate traktuje jsmith, JSmith, JSMITH jako ten sam byt i nie „przechodzi bokiem” do alternatywnej polityki/grupy.
3) Przejrzyj konfigurację grup LDAP – szczególnie „secondary/failover”
Jeśli masz wtórną grupę LDAP używaną, gdy lokalne dopasowanie nie wyjdzie, rozważ jej usunięcie, jeżeli nie jest wymagana biznesowo. Fortinet wskazuje ten element jako istotny warunek umożliwiający obejście 2FA.
4) Załóż możliwość nadużycia i przygotuj playbook IR
Jeśli istnieją przesłanki, iż administratorzy lub użytkownicy VPN logowali się bez 2FA, Fortinet rekomenduje traktować konfigurację jako skompromitowaną oraz wykonać reset poświadczeń, w tym kont/hasła używanego do LDAP/AD binding.
5) Monitoring: na co patrzeć?
Nawet bez pełnych IOC od vendora (Fortinet nie opisuje publicznie szczegółów kampanii), sensowne detekcje to m.in.:
- logowania SSL VPN, gdzie nazwa użytkownika pojawia się w nietypowych wariantach case (np. „AdmIn”, „JSmiTh”), szczególnie gdy wiesz, iż organizacja normalnie używa jednego formatu;
- korelacja: udane logowanie VPN bez spodziewanej ścieżki 2FA (jeśli masz telemetrykę na flow 2FA);
- nietypowa aktywność po VPN (nowe urządzenia, nowe geolokacje, enumeracje zasobów, skoki lateralne).
Różnice / porównania z innymi przypadkami
CVE-2020-12812 to dobry przykład, iż „MFA wszędzie” nie kończy tematu, jeżeli implementacja i polityki mają alternatywne ścieżki (fallback) albo niespójność w identyfikacji użytkownika. W praktyce podobny wzorzec widujemy w:
- błędnie skonfigurowanych łańcuchach SSO/LDAP/SAML, gdzie jeden „warunek brzegowy” (tu: case) rozłącza logikę policyjną;
- urządzeniach edge, gdzie lata „dziedziczonej” konfiguracji + brak audytu polityk uwierzytelniania tworzą nieoczywiste ścieżki obejścia.
A z punktu widzenia trendów eksploatacji: Fortinet sam w 2025 r. publikował ostrzeżenia o innych nadużywanych podatnościach w swoim portfolio – co potwierdza, iż urządzenia tej klasy są stałym celem (szczególnie na styku internet sieć wewnętrzna).
Podsumowanie / najważniejsze wnioski
- CVE-2020-12812 przez cały czas żyje operacyjnie: mimo wieku, Fortinet obserwuje jej nadużywanie w 2025 r.
- Luka jest w praktyce błędem logiki uwierzytelniania wynikającym z różnic w obsłudze wielkości liter i z polityk/grup LDAP.
- Jeśli masz SSL VPN + LDAP + lokalnych użytkowników z 2FA, koniecznie zweryfikuj konfigurację, ustaw username-sensitivity i przejrzyj „secondary LDAP group”.
- W razie podejrzenia obejścia 2FA traktuj incydent poważnie: reset poświadczeń (także bindów LDAP/AD) i przegląd konfiguracji/polityk to minimum.
Źródła / bibliografia
- Fortinet PSIRT Blog: Product Security Advisory and Analysis: Observed Abuse of FG-IR-19-283 (24.12.2025) (fortinet.com)
- BleepingComputer: Fortinet warns of 5-year-old FortiOS 2FA bypass still exploited in attacks (29.12.2025) (BleepingComputer)
- NVD (NIST): CVE-2020-12812 Detail (opis, wersje podatne, CVSS, odniesienie do KEV) (NVD)
- SecurityWeek: Fortinet Warns of New Attacks Exploiting Old Vulnerability (29.12.2025) (SecurityWeek)
- The Hacker News: Fortinet Warns of Active Exploitation of FortiOS SSL VPN 2FA Bypass Vulnerability (25.12.2025) (The Hacker News)