FortiBleed: dlaczego wyciek hasła wystarczył do przejęcia FortiGate

6 października 2026 roku FBI i amerykańska Secret Service opublikowały wspólny komunikat w sprawie FortiBleed, kampanii wymierzonej w wystawione do internetu zapory Fortinet FortiGate i ich bramy VPN (komunikat FBI/USSS). Komunikat przytacza dane SOCRadar, według których przejęto ponad 86 644 urządzenia w 194 krajach, i opisuje kampanię jako wciąż trwającą.

Najbardziej uderza to, czego atakujący nie potrzebowali. Analiza samego Fortinetu nie pozostawia złudzeń: „To nie jest nowa podatność Fortinetu” (Fortinet PSIRT). Żaden exploit nie był potrzebny. Atakujący po prostu się zalogowali.

Jak to działało

Komunikat odtwarza przebieg kampanii na podstawie serwera samych atakujących, który pozostawili otwarty. W skrócie:

Znaleźć strony logowania. Zautomatyzowane skanowanie internetu w poszukiwaniu portali VPN FortiGate.
Wypróbować znane hasła. Credential stuffing i password spraying, zasilane wcześniejszymi zrzutami z wycieków danych Fortinetu i logami infostealerów.
Złamać resztę. Skróty haseł pobrane z przejętych urządzeń trafiały do klastra GPU, gdzie łamano je offline. Ułatwiał to słaby, przestarzały sposób przechowywania haseł administratorów w postaci skrótów SHA-256.
Utrzymać dostęp. Na zaporze zakładano nowe konta administratorów. W części przypadków konta właścicieli usuwano lub zmieniano ich hasła, a ofiary traciły dostęp do własnych urządzeń.
Sprzedać dostęp. Działające konfiguracje VPN i listy celów pakowano i sprzedawano innym przestępcom. Komunikat zaznacza, że FortiBleed był punktem wejścia dla afiliantów grup ransomware.

Każdy krok przed „utrzymaniem dostępu” opiera się na jednym założeniu: prawidłowa nazwa użytkownika i hasło wystarczą, by zalogować się do VPN lub do interfejsu administracyjnego zapory.

Co przerywa ten łańcuch

Wystarczy usunąć to założenie, a główne narzędzia kampanii przestają działać. Jeśli VPN i konsola administracyjna wymagają dodatkowo potwierdzenia na własnym telefonie użytkownika, odgadnięte, kupione czy złamane hasło nie wystarcza już do zalogowania. To nieudana próba, a przy czytelnym potwierdzeniu także sygnał: ktoś właśnie użył tego hasła, a jego właściciel widzi prośbę, której sam nie zainicjował.

Zarówno komunikat, jak i Fortinet stawiają uwierzytelnianie wieloskładnikowe na każdym koncie administratora i VPN w czołówce swoich zaleceń. Tę część obejmuje Notakey. FortiGate potrafi kierować logowania do VPN i logowania administratorów do serwera RADIUS, a Notakey auth-proxy znajduje się na tej ścieżce RADIUS: pozwala istniejącemu serwerowi RADIUS sprawdzić hasło, następnie prosi o potwierdzenie w telefonie i odpowiada twierdząco dopiero wtedy, gdy oba kroki się powiodą. Konfigurację opisuje nasz przewodnik po 2FA w VPN przez RADIUS.

Czego to nie naprawi

Wolimy być tu precyzyjni, niż coś Państwu sprzedawać.

Urządzenia, które już zostało przejęte. MFA przy nowych logowaniach nie ma wpływu na konta utworzone przez atakujących, sesje, które już utrzymują, ani na zmienioną przez nich konfigurację. Najpierw trzeba wykonać kroki z samego komunikatu: zakończyć wszystkie sesje administracyjne i VPN, zresetować hasła, porównać użytkowników i konfigurację z kopią o znanym, prawidłowym stanie oraz przechowywać hasła administratorów z użyciem PBKDF2 zamiast przestarzałych skrótów.
Wystawionego interfejsu zarządzania. Pierwsze zalecenie komunikatu to ograniczenie administracji z internetu: zaufane hosty (dobrze), polityka local-in (lepiej) albo całkowity brak administracji z internetu (najlepiej). Drugi składnik na interfejsie, który w ogóle nie powinien być osiągalny, to słabsze rozwiązanie.
Stron phishingowych pośredniczących w prawdziwym logowaniu. Komunikat zaleca MFA odporne na phishing. W definicji rządu USA oznacza to FIDO/WebAuthn lub PKI, gdzie klucz jest powiązany z prawdziwą witryną. Potwierdzenie w telefonie sprawia, że odgadnięte czy złamane hasło przestaje wystarczać, a właśnie na tym opierała się ta kampania. Samo jednak nie zatrzymuje atakującego, który przepuszcza prawdziwe logowanie przez fałszywą stronę, co wyjaśniamy w naszym artykule o zmęczeniu MFA i atakach pośrednika. Dla nielicznych kont, które administrują samą zaporą, warto rozważyć klucze powiązane z witryną.

Jeśli używają Państwo FortiGate

Trzy praktyczne uwagi, zanim umieszczą Państwo jakiekolwiek potwierdzenie w telefonie przed FortiGate. Pochodzą z dokumentacji Fortinetu; sami nie testowaliśmy FortiGate w laboratorium, a FortiGate komunikuje się z auth-proxy przez standardowy RADIUS jak każdy inny koncentrator VPN.

Zwiększyć limity czasu RADIUS. Domyślnie FortiGate daje całej wymianie RADIUS 5 sekund (remoteauthtimeout) i ponawia żądanie po 5 sekundach (timeout na serwerze RADIUS) (Fortinet: jak współdziałają oba liczniki czasu). To wystarczy na sprawdzenie hasła, ale nie na to, by człowiek sięgnął po telefon. Auth-proxy utrzymuje żądanie otwarte, dopóki użytkownik nie zdecyduje (domyślnie 30 sekund), więc obie wartości muszą być wyraźnie dłuższe niż to okno. Według wskazówki Fortinetu przy równych wartościach FortiGate i tak wysyła żądanie drugi raz. Auth-proxy rozpoznaje ponownie wysłane żądanie i je ignoruje, więc użytkownik nie otrzymuje drugiej prośby o potwierdzenie, ale gdy limit czasu ponowienia jest dłuższą z tych dwóch wartości, cała wymiana ogranicza się do jednego żądania. Na przykład 60 sekund łącznie i 90 przed ponowieniem (notakey-proxy zastępuje tu nazwę, jaką nadali Państwo wpisowi serwera RADIUS wskazującemu na auth-proxy):
```
config system global
    set remoteauthtimeout 60
end

config user radius
    edit "notakey-proxy"
        set timeout 90
    next
end
```
Administratorzy mogą korzystać z tej samej ścieżki. FortiGate obsługuje zdalne uwierzytelnianie administratorów względem serwera RADIUS (Fortinet: zdalne uwierzytelnianie administratorów), w tym konto administratora typu wildcard dla wszystkich członków grupy RADIUS (Fortinet: konfiguracja kont administratorów typu wildcard). Dzięki temu potwierdzenie chroni nie tylko VPN, ale też konsolę, do której zmierzali atakujący.
Zachować jedną drogę powrotu. FortiBleed odcinał właścicieli od ich własnych urządzeń. Warto utrzymywać lokalne awaryjne konto administratora z długim, unikalnym hasłem, dostępne wyłącznie z zaufanych hostów, i przetestować je, zanim będzie potrzebne.

Od czego zacząć

W tym tygodniu warto sprawdzić trzy rzeczy: czy administracja zaporą jest osiągalna z internetu, czy jakiekolwiek konto VPN lub administratora nadal loguje się samym hasłem oraz jak przechowywane są hasła administratorów. Jeśli odpowiedź na drugie pytanie brzmi „tak”, to właśnie luka, z myślą o której zbudowano FortiBleed.

Wypróbuj demo na żywo, aby w około dwie minuty zatwierdzić logowanie z własnego telefonu, lub poproś o prezentację, a zaplanujemy pilotaż obejmujący Państwa logowania do VPN i zapory.