CVE-2025-64446: krytyczne auth bypass w FortiWeb

CVE-2025-64446 to krytyczna podatność FortiWeb pozwalająca zdalnemu, nieuwierzytelnionemu napastnikowi wykonywać komendy administracyjne przez specjalnie przygotowane żądania HTTP/HTTPS. Fortinet ocenił ją na CVSS 9,4 i potwierdził wykorzystanie w rzeczywistych atakach. Luka wynika z path confusion / relative path traversal w GUI urządzenia i może prowadzić do utworzenia nieautoryzowanego administratora oraz pełnego przejęcia WAF.

Najkrótsza rekomendacja: zainstaluj poprawione wydanie dla swojej linii FortiWeb, natychmiast wyłącz zarządzanie HTTP/HTTPS na interfejsach dostępnych z Internetu i sprawdź konta administratorów oraz konfigurację. WAF jest punktem kontroli ruchu, więc jego przejęcie podważa zaufanie do logów i reguł chroniących aplikacje.

CVE-2025-64446 — wersje i poprawki

Linia FortiWeb	Podatne wersje	Minimalna wersja naprawiona
8.0	8.0.0–8.0.1	8.0.2
7.6	7.6.0–7.6.4	7.6.5
7.4	7.4.0–7.4.9	7.4.10
7.2	7.2.0–7.2.11	7.2.12
7.0	7.0.0–7.0.11	7.0.12
6.4	nie jest podatna według advisory	nie dotyczy

Zakres pochodzi z Fortinet PSIRT FG-IR-25-910. FortiAppSec Cloud nie jest objęty tą podatnością. Advisory opublikowano 14 listopada 2025 r.

Jak path confusion omija logowanie

Interfejs zarządzający FortiWeb składa się z serwera HTTP, routingu ścieżek oraz backendu wykonującego operacje administracyjne. W bezpiecznej implementacji każda ścieżka prowadząca do funkcji uprzywilejowanej musi przejść tę samą kontrolę sesji i uprawnień.

CVE-2025-64446 wykorzystuje różnicę w normalizacji ścieżki pomiędzy warstwami. Specjalnie uformowany adres zawierający elementy relative path traversal może zostać inaczej zinterpretowany przez frontend i backend. Warstwa kontroli dostępu widzi żądanie jako ścieżkę niechronioną albo inną funkcję, podczas gdy backend kieruje je do operacji administracyjnej.

Skutkiem nie jest tylko odczyt strony. Według Fortinet napastnik może wykonywać komendy administracyjne, a publiczne badania demonstrują utworzenie nowego użytkownika administratora. Mając kontrolę nad urządzeniem, atakujący może:

zmieniać reguły WAF i przepuszczać kolejne ataki;
odczytywać konfigurację backendów, certyfikaty i dane uwierzytelniające;
kierować lub podsłuchiwać ruch aplikacji;
wyłączyć logowanie i ukrywać działania;
użyć sieci zarządzającej do ruchu bocznego;
utrzymać dostęp przez konta i zmiany konfiguracji.

Publiczny PoC i bezpieczne potwierdzenie

watchTowr opublikował generator artefaktu detekcyjnego FortiWeb Authentication Bypass. Kod demonstruje możliwość utworzenia użytkownika i może zmienić stan urządzenia. Używaj go tylko na laboratoryjnej instancji albo w ramach pisemnie zatwierdzonego pentestu; nie na urządzeniu produkcyjnym.

Bezpieczna walidacja:

odczytaj wersję systemu z CLI i centralnego managera, nie wyłącznie z bannera HTTPS;
zinwentaryzuj każdy HA node — wersja klastra nie gwarantuje identycznego stanu węzłów;
sprawdź, które interfejsy mają włączone HTTP/HTTPS administrative access;
zmapuj reguły NAT, load balancery i historyczną ekspozycję GUI;
wyeksportuj konfigurację, logi administratorów i zdarzenia przed aktualizacją;
potwierdź łatę na testowym appliance, a po wdrożeniu wykonaj pasywny retest.

Publiczny skaner może utworzyć artefakt w konfiguracji. Nawet późniejsze usunięcie konta nie cofa ryzyka ani nie zastępuje analizy.

Naprawa i obejście Fortinet

Zainstaluj co najmniej wersję wskazaną w tabeli lub nowsze wspierane wydanie zalecane dla modelu. W klastrze HA zastosuj procedurę producenta, potwierdź powrót synchronizacji i sprawdź wersję każdego członka.

Jeśli aktualizacja nie jest natychmiast możliwa, Fortinet zaleca wyłączenie HTTP/HTTPS dla interfejsów dostępnych z Internetu. GUI powinno być osiągalne wyłącznie z wydzielonej sieci zarządzającej lub jump hosta. Polityka local-in, ACL na upstream firewall i brak NAT do panelu są niezależnymi warstwami ochrony.

Dodatkowo:

wymagaj MFA dla wszystkich administratorów;
używaj osobnych kont imiennych zamiast wspólnego admin;
wysyłaj logi do zewnętrznego SIEM w czasie zbliżonym do rzeczywistego;
ogranicz ruch wychodzący z appliance;
zarządzaj przez dedykowany interfejs i VRF/VLAN;
regularnie porównuj konfigurację z zatwierdzonym baseline;
przechowuj zaszyfrowane, przetestowane kopie konfiguracji.

Aktywne wykorzystanie i KEV

Fortinet w advisory stwierdza, że zaobserwował wykorzystanie w środowiskach klientów. CISA umieściła podatność w Known Exploited Vulnerabilities. To istotne, ponieważ publiczne urządzenia brzegowe są skanowane automatycznie, a path bypass nie wymaga danych logowania ani interakcji operatora.

Nie wolno ograniczyć reakcji do aktualizacji. Jeżeli GUI było osiągalne w czasie podatności, należy sprawdzić, czy konfiguracja i konta zostały zmienione przed patchem.

Threat hunting na FortiWeb

Fortinet zaleca przegląd nieoczekiwanych zmian konfiguracji i nowych administratorów. Rozszerz kontrolę o:

konta utworzone poza procesem IAM i nietypowe role;
logowania administracyjne z nowych adresów i poza oknem zmian;
żądania GUI z sekwencjami traversal lub nietypową normalizacją ścieżki;
zmiany server policy, protected host, routing, certyfikatów i backendów;
wyłączenie sygnatur, logowania lub integracji z SIEM;
nowe skrypty, automatyzacje i lokalne pliki;
połączenia wychodzące z management plane;
rozbieżności konfiguracji między członkami HA;
restarty, awarie procesów GUI i luki w logowaniu.

Jeżeli istnieje nieautoryzowany administrator, traktuj appliance jako przejęty. Zabezpiecz konfigurację do analizy, odizoluj zarządzanie, obróć hasła i certyfikaty dostępne na urządzeniu, zweryfikuj backendy, a następnie rozważ odbudowę z czystego firmware i zaufanego baseline.

WAF jako część krytycznego łańcucha zaufania

FortiWeb często terminuję TLS i widzi pełne żądania użytkowników. Może przechowywać prywatne klucze certyfikatów, dane uwierzytelniające do originów oraz konfigurację wewnętrznych adresów. Dlatego zarządzanie WAF powinno podlegać podobnym kontrolom jak firewall, hypervisor czy system IAM.

Regularny audyt bezpieczeństwa aplikacji i infrastruktury powinien sprawdzać panel zarządzający z perspektywy Internetu, sieci firmowej i segmentu administratorów. Sam fakt, że WAF chroni inne systemy, nie oznacza, że jego własny GUI jest odporny.

Root cause i pełna powierzchnia zarządzania

Fortinet klasyfikuje problem jako relative path traversal prowadzący do wykonywania komend administracyjnych bez uwierzytelnienia. Kluczowym błędem bezpieczeństwa jest niespójna interpretacja ścieżki przed kontrolą dostępu i w backendzie GUI. Nie oznacza to, że każda sekwencja traversal jest skuteczna ani że sam kod odpowiedzi HTTP potwierdza wykonanie. Tę różnicę trzeba zachować w detekcji i raporcie.

Powierzchnia zarządzania obejmuje więcej niż publiczny adres panelu:

każdy interfejs fizyczny, VLAN, VRF i adres HA;
adresy floating oraz bezpośrednie adresy członków klastra;
NAT, port forwarding, reverse proxy i reguły local-in;
dostęp przez VPN, jump host i sieć dostawcy;
IPv4 i IPv6;
środowiska DR, laboratoryjne i zapasowy appliance;
centralne systemy zarządzania oraz automatyzację korzystającą z API.

Weryfikację ścieżek warto połączyć z pentestem segmentacji sieci. Tester wysyła zwykłe żądanie do strony logowania i potwierdza trasę oraz log, ale nie używa sekwencji PoC. Wynik „panel nie jest widoczny z Internetu” trzeba uzupełnić sprawdzeniem sieci partnerów i zwykłych segmentów użytkowników.

Walidacja ekspozycji i stanu bez modyfikacji appliance

Bezpieczny dowód składa się z inwentarza oraz kontroli pasywnej:

zapisz model, branch, build i rolę HA każdego węzła;
porównaj wersję z tabelą PSIRT, nie tylko z informacją centralnego managera;
odczytaj administrative access na każdym interfejsie;
przejrzyj upstream ACL, NAT, routing i historyczne zmiany;
wykonaj nieszkodliwy test TCP/TLS/HTTP z reprezentatywnych stref;
potwierdź, że próba trafia do zewnętrznego logu;
porównaj konfigurację z zatwierdzonym backupem sprzed ekspozycji.

PoC tworzący administratora nie jest skanerem wersji. Nie używaj go do masowej walidacji, health checku ani monitorowania produkcji. W laboratorium może sprawdzić regułę detekcyjną i proces usuwania artefaktu, ale wynik nie zastępuje oficjalnego statusu patcha.

Telemetria i triage przejęcia WAF

Appliance, który mógł zostać przejęty, nie powinien być jedynym źródłem dowodowym. Logi muszą być eksportowane do zewnętrznego monitoringu bezpieczeństwa. Koreluj:

Źródło	Co sprawdzić	Dlaczego
upstream firewall	źródło, NAT, czas, interfejs	potwierdza rzeczywistą ścieżkę do GUI
zewnętrzny SIEM	logowanie admina i zmiana config	pozostaje wiarygodniejszy po ingerencji lokalnej
FortiWeb admin audit	konto, rola, source IP, akcja	pokazuje zmianę i jej autora
backup/config diff	nowy administrator, policy, certyfikat, backend	ujawnia trwałą modyfikację
HA telemetry	synchronizacja i różnice węzłów	wykrywa niespójny lub pominięty node
PKI/secret systems	użycie klucza lub hasła z appliance	wskazuje wpływ poza WAF
backend access logs	nietypowe żądania po zmianie policy	pokazuje, czy ochrona aplikacji została osłabiona

Triage powinien odpowiedzieć kolejno: czy żądanie dotarło do management plane, czy nastąpiła operacja administracyjna, czy konfiguracja zmieniła się, czy zmiana zsynchronizowała się w HA oraz czy osiągalne sekrety zostały użyte poza urządzeniem. Brak lokalnego logu w okresie przerwy jest sygnałem ryzyka, nie dowodem braku ataku.

Drzewo decyzji dla CVE-2025-64446

Czy każdy węzeł ma wersję co najmniej naprawioną dla swojej linii?

Tak: sprawdź historyczną ekspozycję, integralność konfiguracji i zewnętrzne logi.
Nie/nie wiadomo: wyłącz HTTP/HTTPS na niskozaufanych interfejsach i rozpocznij pilną aktualizację.

Czy GUI był osiągalny w okresie podatności?

Tak: załóż możliwość nadużycia, przejrzyj konta, role, policy, certyfikaty i backendy.
Nie: udowodnij to trasami, ACL i logami z kilku stref; następnie popraw wszystkie węzły.

Czy istnieje nieznane konto, zmiana konfiguracji, luka w logach lub egress?

Tak: izoluj management plane, zachowaj konfigurację, obróć sekrety i odbuduj z zaufanego firmware/baseline zgodnie z procedurą incydentową.
Nie: zakończ retest oraz utrzymuj monitoring ze zwiększoną czułością w uzgodnionym okresie.

Rotacja powinna być kontrolowana przez proces zarządzania sekretami i certyfikatami. Prywatny klucz TLS, hasło do originu i konto API mają różne zależności oraz kolejność wymiany.

Weryfikacja naprawy i hardening

Po aktualizacji zapisz build każdego członka HA, potwierdź synchronizację, stan interfejsów i poprawne przetwarzanie ruchu aplikacyjnego. Sprawdź, czy awaryczna reguła blokująca GUI nie została przypadkowo usunięta, oraz czy nie istnieje alternatywny NAT. Kontrolowane żądanie do panelu z Internetu powinno zostać odrzucone i widoczne w firewallu, a ta sama próba z jump hosta — trafić do audytu.

Hardening opiera się na zasadzie Zero Trust: dedykowana strefa zarządzająca, imienne konta, MFA, minimalne role, rejestrowana sesja i brak bezpośredniego Internetu. Egress appliance ograniczamy do potrzebnych aktualizacji, SIEM, DNS, NTP i nazwanych backendów. Backup konfiguracji szyfrujemy, testujemy i chronimy przed modyfikacją przez to samo konto administracyjne.

Retest nie uruchamia PoC na produkcji. Potwierdza wersję, brak ekspozycji, integralność kont i config, działanie logowania oraz skuteczność nowej architektury dostępu.