CVE-2026-24858: FortiCloud SSO ominęło logowanie do Fortinet

CVE-2026-24858 to krytyczne obejście uwierzytelniania w mechanizmie FortiCloud Single Sign-On. Fortinet nadał luce CVSS 3.1 9,4, potwierdził wykorzystanie w atakach i opisał przypadki, w których napastnik pobierał konfigurację urządzenia oraz tworzył lokalne konto administratora. To przykład błędu, w którym zaufanie do zewnętrznego kanału tożsamości staje się drogą wejścia do urządzenia brzegowego.

Podatność obejmuje wskazane w advisory wersje FortiOS, FortiManager, FortiAnalyzer, FortiProxy, FortiSwitchManager i FortiWeb. Nie oznacza to, że każda instalacja jest automatycznie możliwa do przejęcia. Warunkiem jest włączone logowanie administracyjne przez FortiCloud SSO. Funkcja nie jest domyślnie aktywna po instalacji, lecz mogła zostać włączona podczas rejestracji FortiCare, jeśli operator nie wyłączył odpowiedniego przełącznika.

Model ataku i granice twierdzeń

Fortinet klasyfikuje problem jako uwierzytelnienie przez alternatywny kanał. Napastnik potrzebował własnego konta FortiCloud i zarejestrowanego urządzenia, ale wadliwa walidacja pozwalała mu uwierzytelnić się do innego, podatnego systemu z włączonym SSO. Nie jest to więc wyciek hasła administratora ani klasyczne credential stuffing. Błąd leży w tym, że docelowe urządzenie akceptowało nieprawidłowo powiązaną tożsamość z zaufanego kanału.

22 stycznia 2026 roku Fortinet zidentyfikował dwa złośliwe konta FortiCloud i je zablokował. 26 stycznia producent tymczasowo wyłączył usługę SSO po swojej stronie, a 27 stycznia przywrócił ją z blokadą logowania dla wersji podatnych. Te działania chmurowe ograniczyły bieżący wektor, ale nie zastępują aktualizacji urządzeń ani dochodzenia. Konfiguracja pobrana przed blokadą może ujawnić topologię, konta, skróty haseł, klucze, obiekty VPN i inne dane przydatne do kolejnych etapów ataku.

Fortinet podaje, że niestandardowe konfiguracje korzystające z własnego dostawcy tożsamości nie były dotknięte tą konkretną luką. Advisory wyłącza również FortiManager Cloud, FortiAnalyzer Cloud i FortiGate Cloud. W raporcie trzeba więc dokumentować faktyczny przepływ logowania, a nie wnioskować po samym logo Fortinet.

Jak sprawdzić, czy funkcja była włączona

Najpierw ustal pełną listę instancji, również HA standby, urządzeń laboratoryjnych i wycofywanych węzłów nadal widocznych w DNS lub NAT. Dla każdej zapisz produkt, dokładny build, tryb zarządzania, ekspozycję interfejsu administracyjnego i stan FortiCloud SSO. Następnie porównaj build z tabelami poprawionych wersji w PSIRT FG-IR-26-060.

Samo stwierdzenie, że panel był ograniczony do adresów administracyjnych, nie zamyka analizy. Trzeba odtworzyć rzeczywiste ścieżki przez reverse proxy, VIP, local-in policy, management VDOM, tunele i sieci dostawców. Wiele incydentów wykorzystuje różnicę między zamierzoną architekturą a efektywną ekspozycją.

Weryfikacja powinna objąć również konfigurację FortiCare. Funkcja mogła zostać aktywowana podczas wcześniejszego onboardingu, a później zapomniana. Zrzut bieżącego GUI nie wystarcza — zachowaj kopię konfiguracji i dzienników z timestampem oraz źródłem, aby wynik dało się powtórzyć.

Konta trwałości i artefakty do przejrzenia

Producent zalecił sprawdzenie nieoczekiwanych administratorów, w tym nazw: audit, backup, itadmin, secadmin, support, backupadmin, deploy, remoteadmin, security, svcadmin, system i adccount. Lista nie jest sygnaturą kompletną. Atakujący może użyć innej nazwy, zmienić istniejące konto albo pozostawić dostęp przez klucz, token, obiekt automatyzacji czy zewnętrzny system zarządzania.

Analiza powinna odpowiedzieć na pytania:

• czy pojawiły się logowania administratorów przez FortiCloud z nietypowego źródła;
• czy utworzono, zmieniono lub ponownie włączono lokalne konto;
• czy pobrano pełną konfigurację albo wykonano nietypowy backup;
• czy zmieniono reguły zapory, obiekty VPN, certyfikaty, skrypty lub automation stitches;
• czy urządzenie inicjowało nowe połączenia wychodzące;
• czy logi zostały wyczyszczone, skrócone lub przekonfigurowane.

Logi lokalne mogą zostać zmodyfikowane po przejęciu. Porównaj je z FortiAnalyzerem, SIEM-em, syslogiem, NetFlow i telemetrią upstream. Brak lokalnego wpisu nie dowodzi braku ataku.

Reakcja krok po kroku

1. Zabezpiecz konfigurację, logi i stan urządzenia przed zmianą.
2. Ogranicz administrację do dedykowanej sieci lub bastionu; wyłącz FortiCloud SSO, jeśli nie jest niezbędne.
3. Zainstaluj poprawioną wersję dokładnie według tabeli PSIRT i potwierdź aktywny build na wszystkich członkach HA.
4. Usuń nieznane konta dopiero po zebraniu dowodów. Przejrzyj konta legalne, role, trusted hosts, klucze i tokeny.
5. Jeżeli konfiguracja mogła zostać pobrana, potraktuj zawarte w niej sekrety jako narażone i przeprowadź kontrolowaną rotację.
6. Porównaj konfigurację ze znanym dobrym baseline’em, a przy dowodach kompromitacji rozważ odbudowę zgodną z procedurą producenta.
7. Monitoruj użycie starych poświadczeń oraz próby powrotu z adresów i kont powiązanych z incydentem.

Nie przywracaj bezrefleksyjnie starego backupu: może zawierać podatną konfigurację, nieautoryzowane konto albo ujawnione sekrety. Odbudowa powinna przenieść tylko zweryfikowane elementy do poprawionej wersji.

Dlaczego cloud-side kill switch nie kończy incydentu

Centralna blokada była szybkim i cennym ruchem producenta. Nie cofa jednak operacji wykonanych przed 26 stycznia. Jeżeli atakujący utworzył administratora, pobrał konfigurację lub uzyskał materiał VPN, może wrócić inną ścieżką. Zespół powinien więc oddzielić trzy pytania: czy wektor nadal działa, czy urządzenie było osiągalne oraz czy doszło do działania po uwierzytelnieniu.

Ta luka jest także argumentem za traktowaniem tożsamości administracyjnej jako części powierzchni urządzenia brzegowego. Federacja i SSO redukują liczbę haseł, ale dodają relację zaufania, którą trzeba monitorować. Włącz przegląd tych zależności do zarządzania podatnościami, hardeningu urządzeń brzegowych i ćwiczeń incident response. Jeżeli potrzebujesz niezależnej walidacji ekspozycji i konfiguracji, BreachRoad może przeprowadzić audyt.

---

Źródła pierwotne: Fortinet PSIRT FG-IR-26-060, CISA KEV.