FortiBleed: wyciek poświadczeń FortiGate

W czerwcu 2026 roku administratorzy urządzeń FortiGate dostali ostrzeżenie, którego nie da się rozwiązać zwykłym „wgraj łatkę”. W sieci pojawił się zbiór danych logowania odnoszących się do dziesiątek tysięcy zapór i bram VPN. Kampania otrzymała nazwę FortiBleed, a oficjalne alerty wydały między innymi brytyjskie NCSC, singapurska CSA, CSIRT NASK oraz sam Fortinet.

Cyber Security Agency of Singapore podała, że ujawniony zbiór obejmował poświadczenia dotyczące ponad 70 tysięcy urządzeń FortiGate na świecie. To poważny sygnał, ale nie dowód, że każde urządzenie z listy zostało skutecznie przejęte albo że wszystkie opublikowane hasła nadal działają.

Najważniejsze doprecyzowanie pochodzi od producenta: Fortinet stwierdził wprost, że nie jest to nowa podatność produktu ani kampania związana z nowym advisory. Według wstępnej analizy aktywność łączy ponowne użycie danych z wcześniejszych incydentów z brute force i credential stuffing przeciw urządzeniom o słabej higienie haseł, bez MFA.

Co zostało potwierdzone

18 czerwca brytyjskie NCSC opisało globalne ataki na publicznie dostępne zapory i portale VPN Fortinet. Według alertu baza poświadczeń powstała po próbach brute force, atakach słownikowych i credential stuffing. Dzień później Fortinet poinformował, że identyfikuje potencjalnie dotknięte systemy i kontaktuje się z klientami.

W Polsce CSIRT NASK wydał pilne rekomendacje dla wszystkich instytucji korzystających z FortiGate. Zespół zalecił nie tylko aktualizację, lecz także audyt kont, analizę alarmów, wyłączenie panelu webowego i SSH z Internetu, MFA oraz zewnętrzne logowanie zdarzeń.

Te komunikaty są zgodne w jednym punkcie: organizacja nie powinna czekać na indywidualne potwierdzenie od producenta. Musi sama ustalić, czy jej urządzenie było wystawione, czy dane logowania mogły znaleźć się w zbiorze i czy w konfiguracji istnieją ślady nieautoryzowanej aktywności.

Jak działa atak bez nowego CVE

Credential stuffing wykorzystuje dane skradzione wcześniej z innej usługi. Jeżeli administrator użył podobnego loginu i hasła na kilku urządzeniach, bot może automatycznie sprawdzić je na publicznym portalu FortiGate. Brute force i atak słownikowy próbują natomiast dużej liczby popularnych lub przewidywalnych kombinacji.

W obu przypadkach udane logowanie wygląda dla zapory bardziej „legalnie” niż exploit. Napastnik przechodzi przez normalny formularz i używa poprawnego hasła. Jeżeli nie ma MFA, a panel nie ogranicza źródłowych adresów IP, samo aktualne oprogramowanie nie zatrzyma takiego wejścia.

To ważna lekcja: proces zarządzania podatnościami jest konieczny, ale nie rozwiązuje kradzieży tożsamości. Tutaj kluczowe są konfiguracja dostępu, unikalne poświadczenia, wieloskładnikowe uwierzytelnianie i monitoring.

Dlaczego przejęcie FortiGate jest szczególnie groźne

Zapora i brama VPN znajdują się na granicy sieci. Konto administratora pozwala zmieniać reguły, tworzyć użytkowników, obserwować konfigurację i przygotowywać dalszy ruch do środowiska wewnętrznego. Konto VPN może dać bezpośredni punkt wejścia, z którego atakujący zacznie rozpoznanie i ruch boczny.

CSA i Fortinet ostrzegają przed możliwością:

• dodawania nieautoryzowanych kont i zmian w konfiguracji,
• utrzymania dostępu po zmianie pojedynczego hasła,
• wejścia do systemów dostępnych z sieci VPN,
• wykorzystania kont integracyjnych AD lub LDAP,
• ruchu bocznego do kontrolerów domeny i innych serwerów.

Jeśli FortiGate korzysta z konta serwisowego do AD/LDAP, po potwierdzonym włamaniu trzeba potraktować również to konto jako zagrożone. Samo zresetowanie administratora zapory może wtedy pozostawić napastnikowi ważny sekret w domenie.

Plan reakcji krok po kroku

1. Ustal ekspozycję i właściciela urządzenia. Zinwentaryzuj publiczne adresy, portale SSL VPN, panele webowe oraz SSH. Sprawdź, które systemy rzeczywiście należą do organizacji i kto nimi zarządza.

2. Zabezpiecz materiał dowodowy. Zanim wykonasz reset fabryczny, pobierz logi, konfigurację i inne artefakty potrzebne do analizy. Operacje odtworzeniowe mogą je bezpowrotnie usunąć.

3. Zakończ sesje i zmień poświadczenia. Fortinet zaleca zakończenie aktywnych sesji administracyjnych i VPN oraz reset wszystkich haseł na urządzeniach wystawionych do Internetu. Hasła muszą być unikalne; ich rotacja powinna objąć także sekrety współdzielone z innymi urządzeniami.

4. Wymuś MFA. Włącz drugi składnik dla każdego administratora i użytkownika VPN. Wdrożenie powinno objąć również konta uprzywilejowane, a nie tylko zwykłych pracowników. Praktyczne zasady opisujemy w poradniku wdrożenia MFA.

5. Zaktualizuj i wzmocnij haszowanie. Producent rekomenduje aktualne wydania linii FortiOS 7.4, 7.6 lub 8.0, wspierające PBKDF2 dla poświadczeń administratorów, oraz usunięcie starszych ustawień poleceniem set login-lockout-upon-weaker-encryption. Dobierz wersję zgodnie z oficjalną ścieżką aktualizacji dla swojego modelu.

6. Porównaj konfigurację z bezpieczną kopią. Szukaj obcych użytkowników, zmian reguł, nowych tras, polityk i ustawień VPN. Fortinet zwraca uwagę na nieznane konta o nazwach udających wsparcie, np. fortinet-support czy fortinet-tech-support.

7. Przejrzyj logi urządzenia i domeny. Sprawdź logowania administracyjne z nietypowych adresów, resetowanie haseł, tworzenie użytkowników i połączenia VPN z nowych lokalizacji. W AD szukaj późniejszego ruchu bocznego i nowych kont.

8. Usuń panel zarządzania z Internetu. Ogranicz go przez trusted hosts, regułę local-in albo całkowicie wyłącz zewnętrzną administrację. CSIRT NASK rekomenduje dostęp wyłącznie z dedykowanych adresów wewnętrznych.

9. Przy śladach włamania izoluj i odtwórz. NCSC oraz CSA wskazują, że zmiana haseł może nie wystarczyć, jeśli napastnik uzyskał trwałość. Po zachowaniu dowodów może być potrzebny reset fabryczny i odbudowa z pewnej, zweryfikowanej konfiguracji. Taką decyzję warto prowadzić w ramach planu reagowania na incydenty.

Czego nie należy wnioskować

FortiBleed nie jest nazwą nowego zero-daya i nie potwierdza włamania do sieci producenta. Liczba ponad 70 tysięcy odnosi się do rekordów lub urządzeń reprezentowanych w ujawnionym zbiorze, a nie do 70 tysięcy niezależnie potwierdzonych pełnych kompromitacji. Część danych może pochodzić ze starszych incydentów albo z nieskutecznych prób zgadywania.

Nie wolno jednak używać tej niepewności jako wymówki do bezczynności. Obecność urządzenia na liście, publiczny panel, brak MFA lub ponownie używane hasło to wystarczające powody do pilnej analizy.

Podsumowanie

FortiBleed przypomina, że urządzenie może być w pełni załatane, a mimo to dostępne dla napastnika z poprawnym hasłem. Odpowiedź musi więc łączyć aktualizacje z rotacją poświadczeń, zakończeniem sesji, MFA, przeglądem konfiguracji i analizą ruchu bocznego. Najważniejsze jest również poprawne nazwanie incydentu: to kampania przejmowania poświadczeń, nie nowa luka FortiGate. Właściwa diagnoza prowadzi do właściwej reakcji.

---

Źródła i dalsza lektura: Fortinet PSIRT — analiza FortiBleed, NCSC UK — alert o globalnej kampanii, CSA Singapore — advisory FortiBleed, CSIRT NASK — pilne rekomendacje dla FortiGate.