FortiBleed

FortiGate w Internecie, czyli gdzie kończy się normalna ekspozycja, a zaczyna zła praktyka?

W dyskusjach o FortiBleed łatwo skupić się na elementach najbardziej medialnych typu dziesiątkach tysięcy urządzeń, hasłach w plaintext, hashach SHA-256, klastrach GPU i pytaniu, czy Fortinet coś „przemilcza”, czy badacze coś „podkręcają”. To wszystko jest istotne, ale z perspektywy praktyka bezpieczeństwa pojawia się tu prostsze pytanie:

Czy wystawianie FortiGate do Internetu nie jest po prostu złą praktyką?

Odpowiedź brzmi: to zależy, co dokładnie wystawiamy.

FortiGate z natury stoi na brzegu sieci. Jego rolą jest obsługa ruchu z Internetu, filtrowanie połączeń, terminowanie tuneli VPN, publikowanie usług i ochrona organizacji przed światem zewnętrznym. Sam fakt, że urządzenie ma publiczny adres IP, nie jest niczym dziwnym. Problem zaczyna się wtedy, gdy do Internetu wystawiamy nie funkcję brzegową, lecz interfejs zarządzania.

Innymi słowy - publiczny VPN to często uzasadniony przypadek użycia. Publiczny panel administracyjny firewalla to zupełnie inna historia.

VPN to funkcja. Panel admina to ryzyko.

Warto rozdzielić dwie rzeczy, które w wielu komentarzach trafiają do jednego worka.

Pierwsza to SSL-VPN albo IPsec VPN dostępny z Internetu. W wielu firmach to normalny model prac, bo użytkownicy zdalni, administratorzy, partnerzy czy serwisanci muszą mieć możliwość zestawienia tunelu. Taka usługa jest publiczna, bo z definicji ma być osiągalna spoza organizacji.

Druga to panel administracyjny FortiGate dostępny z Internetu to GUI po HTTPS, SSH, API administracyjne albo inny kanał zarządzający osiągalny bezpośrednio z publicznego adresu. To nie jest już zwykła ekspozycja usługi. To wystawienie najbardziej krytycznego miejsca w całej infrastrukturze.

Firewall to nie kolejna aplikacja webowa. To urządzenie, które decyduje, kto wchodzi do sieci, którędy idzie ruch, jakie tunele są aktywne, które reguły blokują atakującego, jakie logi są zbierane i jakie wyjątki istnieją w konfiguracji. Jeżeli atakujący przejmie panel zarządzania firewalla, nie zdobywa „jednego serwera”, zdobywa punkt sterowania ruchem na brzegu organizacji.

Dlatego, w mojej opinii, publicznie wystawiony management FortiGate należy traktować jako poważny błąd architektoniczny. W zależności od kontekstu może to być finding klasy High, a czasem Critical, szczególnie gdy brakuje MFA, allowlisty adresów IP, trusted hosts, monitoringu i regularnej rotacji poświadczeń.

Czy ukrycie managementu zapobiegłoby FortiBleed?

Nie należy twierdzić tego z absolutną pewnością, bo publicznie nie mamy pełnej jasności, jak dokładnie wszystkie dane w FortiBleed zostały pozyskane. Część źródeł mówi o credential harvestingu, brute-force, starszych incydentach, wykradzionych konfiguracjach i crackowaniu hashy offline. Fortinet podkreśla, że według firmy nie chodzi o nową podatność ani nowe advisory, lecz o kampanię opartą na poświadczeniach i danych z wcześniejszych źródeł. Badacze z kolei wskazują, że skala i aktualność części danych sugerują realne, bieżące ryzyko.

Z punktu widzenia modelowania zagrożeń ważniejsze jest jednak inne pytanie:

Czy schowanie panelu administracyjnego z Internetu przerwałoby najbardziej prawdopodobne i najbardziej użyteczne etapy ataku?

W wielu przypadkach, myślę, że tak.

Jeżeli panel administracyjny nie jest dostępny z Internetu, atakujący nie może go masowo skanować, łatwo wykonywać prób logowania, bezpośrednio testować podatności w interfejsie administracyjnym ani wykorzystać poprawnego hasła z Internetu, o ile nie ma innej ścieżki dostępu do sieci zarządzającej.

To nie znaczy, że organizacja staje się magicznie bezpieczna. Publiczny VPN nadal bywa wektorem. Stare poświadczenia nadal mogą być problemem. Wykradziona konfiguracja nadal może zawierać sekrety. Zmienia się jednak ekonomia ataku: atakujący traci prosty, masowy, internetowy dostęp do najważniejszego panelu w organizacji.

Ale to jest ogromna różnica.

Rotacja haseł to nie formalność.

Drugim elementem, który bardzo mocno ograniczyłby skuteczność scenariusza FortiBleed, jest okresowa rotacja haseł, zwłaszcza kont lokalnych, administracyjnych i VPN.

Wyciek poświadczeń jest groźny tak długo, jak długo te poświadczenia działają. Jeżeli hasło wykradziono rok temu, ale od tego czasu je zmieniono, jego wartość operacyjna dla atakującego mocno spada. A jeśli dodatkowo unieważniono sesje, przejrzano konta, wymuszono MFA i sprawdzono konfigurację pod kątem backdoorów, wyciek staje się incydentem do obsłużenia, a nie katastrofą.

W przypadku FortiBleed rotacja ma jeszcze jeden wymiar. W części analiz pojawia się problem starszych hashy haseł zapisanych w konfiguracjach. Sam update systemu może nie wystarczyć, jeśli stare poświadczenia pozostają zapisane w starszym formacie aż do ponownego logowania albo zmiany hasła. „Zrobiliśmy update” nie zawsze równa się więc „zakończyliśmy proces bezpieczeństwa”.

Konkretnie: domyślny algorytm hashujący hasła administratorów zmienił się z SHA-256 na PBKDF2 od FortiOS 7.2.11, 7.4.8 i 7.6.1. Po aktualizacji ze starszej wersji hasło danego konta pozostaje w SHA-256 do czasu, aż ten administrator pierwszy raz zaloguje się na nowym firmware albo ręcznie zmieni hasło. Co jest czym, sprawdzisz w show system admin po prefiksie hasha: PB2 to PBKDF2 (OK), SH2 to SHA-256 (do wymiany):

show system admin config system admin edit “admin” set accprofile “super_admin” set vdom “root” set password ENC SH2D4n<…ciach…>Nc= ← SHA-256, do wymiany next end

Jest tu haczyk, o którym łatwo zapomnieć. Po przejściu na PBKDF2 poprzedni hash SHA-256 domyślnie zostaje w ukrytym polu old-password „dla kompatybilności wstecznej”. Nie widać go w GUI ani w show zalogowanego admina, ale pojawia się w backupie konfiguracji robionym przez superadmina, a samo zalogowanie się czy nawet zmiana hasła go nie usuwają. Gorzej: jeśli administrator „zmienił” hasło na takie samo jak poprzednie tylko po to, by przełączyć typ hasha, w old-password siedzi SHA-256 wciąż aktualnego hasła. Stary hash realnie kasuje dopiero włączenie polityki lockout:

FortiOS 7.6.x

config system password-policy set login-lockout-upon-weaker-encryption enable end

FortiOS 7.2.x / 7.4.x — ta sama funkcja, inna nazwa

config system password-policy set login-lockout-upon-downgrade enable end

Po włączeniu tej opcji trzeba pamiętać o jednym: downgrade FortiOS do wersji bez obsługi PBKDF2 zablokuje wtedy logowanie administratorom, więc warto uwzględnić to w planie ewentualnego rollbacku.

Po aktualizacji urządzenia brzegowego powinno paść pytanie:

Czy po update zmieniliśmy hasła i sekrety, które mogły istnieć jeszcze przed poprawką?

Jeżeli odpowiedź brzmi „nie”, proces nie jest zamknięty, jesteś dopiero w połowie.

Update to początek końca, nie koniec procesu.

W wielu organizacjach patchowanie wygląda tak, że pojawia się advisory, administrator wykonuje upgrade, urządzenie wstaje, ruch działa, ticket zostaje zamknięty. Operacyjnie, spoko - zrozumiałe. Z punktu widzenia bezpieczeństwa jednak w mojej opinii niewystarczające.

Aktualizacja usuwa podatność w kodzie. Nie zawsze usuwa skutki tego, co mogło wydarzyć się wcześniej. Nie zmienia starych hashy. Nie rotuje sekretów. Nie usuwa backdoorowych kont. Nie odwraca zmian w konfiguracji. Nie sprawdza, czy ktoś nie pobrał wcześniej backupu urządzenia.

Dlatego dla urządzeń brzegowych, takich jak FortiGate, update powinien uruchamiać dodatkowy playbook:

1. aktualizacja FortiOS,
2. rotacja haseł administratorów,
3. rotacja haseł lokalnych kont VPN,
4. wymuszenie MFA,
5. unieważnienie aktywnych sesji tam, gdzie to możliwe,
6. przegląd kont administracyjnych,
7. przegląd użytkowników VPN,
8. przegląd reguł, tuneli, tras i obiektów,
9. analiza logowań z ostatnich miesięcy,
10. ograniczenie dostępu do managementu.

Dopiero wtedy można mówić, że proces został domknięty.

Najgorsza kombinacja, czyli publiczny management, brak MFA i stare hasła.

FortiBleed dobrze pokazuje, że pojedyncza słabość rzadko działa w izolacji. Prawdziwy problem pojawia się, gdy kilka zaniedbań nakłada się na siebie.

Publiczny panel administracyjny sam w sobie jest ryzykowny. Ale jeśli dołożymy do tego brak MFA, lokalne konta, długo nierotowane hasła, starszy format przechowywania poświadczeń, brak trusted hosts i brak monitoringu logowań, to otrzymujemy środowisko idealne dla atakującego.

Przy „braku MFA” warto uczciwie nazwać, z czego on wynika. Na FortiGate drugi składnik dla kont lokalnych oznacza w praktyce FortiToken, mobilny albo sprzętowy (darmowe są tylko dwie licencje FortiToken Mobile), ewentualnie kod przez e-mail lub SMS. Skalowalne MFA dla administratorów zwykle realizuje się inaczej: przez konta nielokalne uwierzytelniane na zewnętrznym IdP po RADIUS lub SAML (na przykład EntraID), który MFA obsługuje po swojej stronie.

I tu jest sedno: w wielu organizacjach „brak MFA” nie bierze się z tego, że nikt o nim nie pomyślał, lecz z budżetu. Zakup samego FortiGate bywa traktowany jako koniec wydatków („mam drogie urządzenie na brzegu, po co dokładać licencje?”), i to, a nie niewiedza, jest najczęstszym blokerem. Warto o tym pamiętać, formułując rekomendacje, bo „włączcie MFA” i „znajdźcie budżet na MFA” to dwie różne rozmowy.

W takim modelu atakujący nie potrzebuje zero-daya. Wystarczy credential stuffing, brute-force, stary dump, wykradziona konfiguracja, podatność sprzed miesięcy albo po prostu poprawne hasło, którego nigdy nie zmieniono.

I to jest najważniejsza lekcja - wiele incydentów nie wynika z jednego spektakularnego błędu, lecz z kilku małych furtek/zapominajek, które razem tworzą szeroko otwarte drzwi.

Jak powinien wyglądać rozsądny model dostępu?

Najprostsza zasada:

FortiGate może być wystawiony do Internetu jako firewall albo brama VPN. Nie powinien być wystawiony do Internetu jako panel zarządzania.

Dostęp administracyjny powinien być możliwy wyłącznie przez kontrolowaną ścieżkę, na przykład:

• dedykowany management VLAN, • bastion / jump host, • VPN administracyjny z MFA, • allowlistę konkretnych adresów IP, • trusted hosts per administrator, • osobny out-of-band management, • lokalne zarządzanie z sieci administracyjnej.

Jeżeli organizacja z jakiegoś powodu musi dopuścić administrację z zewnątrz, powinno to być rozwiązanie tymczasowe, udokumentowane, monitorowane i silnie ograniczone. Publiczny panel admina „bo tak było wygodniej” nie powinien przechodzić przeglądu/audytu bezpieczeństwa.

Czy te dwie kontrole wystarczą?

Niewystawianie managementu do Internetu i okresowa rotacja haseł to bardzo mocne kontrole, ale same nie rozwiązują całego problemu.

Jeśli SSL-VPN jest publiczny i działa bez MFA, organizacja nadal jest narażona. Jeśli kont lokalnych nikt nie przegląda, atakujący może mieć dostęp awaryjny. Jeśli po incydencie zmieniono hasła, ale nie sprawdzono konfiguracji, backdoorowe konto może pozostać aktywne. Jeśli nikt nie analizuje logów, poprawne logowanie z nietypowego kraju będzie wyglądać jak zwykły dzień pracy.

Dlatego minimalny zestaw kontroli powinien obejmować:

• brak publicznego dostępu do panelu administracyjnego, • MFA dla administratorów i użytkowników VPN, • regularną rotację haseł i sekretów, • reset haseł po istotnych aktualizacjach, • aktualny FortiOS, • trusted hosts dla kont adminów, • local-in policies ograniczające dostęp do usług zarządzania, • monitoring logowań i zmian konfiguracji, • alerty na nowe konta, nowe tunele i nietypowe reguły, • okresowy backup i porównywanie konfiguracji.

I to nie jest nadmiarowa biurokracja, lecz podstawowa higiena dla urządzenia stojącego między Internetem a siecią organizacji.

Taki wniosek mi się nasuwa

FortiBleed nie powinien być czytany wyłącznie jako historia o Fortinecie, hashach i wycieku haseł. To przede wszystkim przypomnienie, że urządzenia brzegowe są zbyt ważne, by zarządzać nimi tak samo jak zwykłą aplikacją.

Najważniejsze pytanie po takiej historii nie brzmi „czy mamy najnowszy numer wersji FortiOS?”. Lepsze pytania brzmią:

• Czy nasz panel administracyjny jest dostępny z Internetu? • Czy każde konto administracyjne ma MFA? • Kiedy ostatnio rotowaliśmy hasła lokalne i VPN? • Czy po aktualizacji wymusiliśmy zmianę haseł? • Czy sprawdziliśmy, czy ktoś nie dodał kont, tuneli lub reguł? • Czy potrafimy wykryć logowanie poprawnym hasłem z nietypowego miejsca?

Jeżeli odpowiedzi są niejasne, problemem nie jest sam FortiBleed. Problemem jest model zarządzania infrastrukturą brzegową Twojej organizacji.

A ten model trzeba naprawić, zanim ktoś inny wykorzysta go jako gotową instrukcję wejścia do sieci.

FortiBleed

*PS Jeśli po przeczytaniu tego tekstu sprawdzasz właśnie, czy Twój panel admina przypadkiem nie wita całego Internetu, to spokojnie, ktoś już to za Ciebie sprawdził. Prawdopodobnie ma nawet zrzut Twojej konfiguracji i lepszy dashboard niż Ty.*