Czy narzędzie, które ma patrzeć wszystkim na ręce, może samo stać się najsłabszym ogniwem? FortiSIEM – centrum nerwowe wielu SOC-ów – właśnie dostało strzał prosto w mechanizm zaufania.
Fortinet załatał krytyczną podatność w FortiSIEM (CVE-2025-64155) umożliwiającą wykonanie kodu bez logowania, a badacze opublikowali działający exploit. Honeypoty już rejestrują ataki. W skrócie: ktoś z dostępem sieciowym do konkretnego portu może przejąć urządzenie, a potem wyczyścić po sobie ślady w logach. Jeśli to brzmi jak zły sen zespołu bezpieczeństwa, to dlatego, że nim jest.
Chodzi o system, który agreguje logi, koreluje zdarzenia i ostrzega, kiedy coś się pali. Gdy pada SIEM, zespół traci wgląd w to, co dzieje się w sieci. Atakujący może zdobyć uprawnienia root, manipulować telemetrią i otworzyć sobie drogę do reszty środowiska. Fortinet i tak ma ostatnio gorący okres: równolegle obserwujemy aktywne nadużycia innych luk w produktach firmy i pretensje branży o tempo i styl komunikacji.
O co dokładnie chodzi
Sercem problemu jest phMonitor – proces backendowy FortiSIEM, który odpowiada m.in. za monitorowanie kondycji i komunikację między węzłami (port TCP 7900). Okazało się, że część jego handlerów nie wymaga autoryzacji, a do tego przekazuje parametry od użytkownika do skryptu shella. To otwiera drogę do wstrzyknięcia argumentów i zapisu wybranych plików na dysku z uprawnieniami admina.
Badacz Zach Hanley z Horizon3.ai pokazał, jak z tej „ograniczonej” możliwości zrobić pełne przejęcie: wystarczy dopisać reverse shella do pliku /opt/charting/redishb.sh – wykonywanego co minutę przez crona z uprawnieniami root. Efekt: eskalacja do roota i całkowita kontrola nad appliance. Co gorsza, atak nie wymaga żadnych poświadczeń – wystarczy dostęp do portu 7900. PoC od Horizon3.ai jest publiczny.
Kto jest na linii strzału i co łatać
Fortinet przyznał, że podatność dotyczy tylko węzłów Super i Worker, i poprawił ją w aktualnych gałęziach. W skrócie: wersje 6.7.x, 7.0.x, 7.1.0-7.1.8, 7.2.0-7.2.6, 7.3.0-7.3.4 i 7.4.0 wymagają migracji do odpowiednich wydań naprawczych (odpowiednio: 7.1.9+, 7.2.7+, 7.3.5+, 7.4.1+). FortiSIEM 7.5 i FortiSIEM Cloud nie są podatne. Jako doraźny workaround producent zaleca ograniczenie dostępu do portu 7900.
Szerszy kontekst: Fortinet pod ogniem, a edge to dziś front
To kolejny epizod w długiej serii. Równolegle trwają ataki na świeżo załatane obejścia SSO w FortiOS/FortiProxy/FortiSwitchManager i FortiWeb (CVE-2025-59718/59719), które pozwalają zalogować się na konto admina przez sfałszowane SAML. Arctic Wolf widzi aktywne wykorzystywanie od 12 grudnia – intruzi pobierają pliki konfiguracyjne, czyli mapę sieci i hasła w formie hashy. Do tego dochodzi krytyczna, masowo nadużywana luka w FortiWeb (CVE-2025-64446), której komunikacja – zdaniem badaczy – była spóźniona i „po cichu” załatana, co nie pomogło administratorom zdążyć z aktualizacją. [7]
To nie tylko problem Fortinetu, ale i klasy urządzeń. Dostawcy edge (firewalle, SSL VPN, WAF-y) są na celowniku, bo zwykle stoją „przed” EDR-em, a ich kompromitacja daje wygodny przyczółek.
Fakty, bez waty
- Wektor: nieautoryzowane żądania do phMonitor (TCP 7900), wstrzyknięcie argumentów do skryptu, zapis pliku, cron->root.
- Status: poprawki dostępne; publiczny PoC; potwierdzone próby ataków na honeypoty dla CVE-2025-64155.
- Ryzyko: przejęcie urządzenia SIEM, ukrywanie śladów, pivot w sieci; eskalacja do roota w kilka minut.
- Działania doraźne: natychmiast ograniczyć 7900 do zaufanych segmentów/VPN, odciąć interfejsy zarządzania od internetu, przejrzeć crontaby i wskazany plik redishb.sh, rotować poświadczenia.
Komentarz z dystansem
Dla Fortinetu to „jeszcze jeden pożar” w roku, który i tak przypominał ćwiczenia strażackie non stop. Firma wciąż rośnie i sprzedaje, a w kwartalnych slajdach pojawia się nawet tytuł „Most Trusted”. Cóż, zaufanie w cyberbezpieczeństwie to nie statuetka – to codzienne punkty za szybkość łatek, transparentność i jakość kodu. W SIEM-ie błąd to nie tylko bug. To ryzyko, że ktoś wyłączy alarm i otworzy sobie drzwi.
Co robić teraz, praktycznie
Jeśli FortiSIEM stoi u was w SOC-u, zakładajcie, że atak jest kwestią czasu, nie „czy”. Aktualizujcie do wersji naprawczych (7.1.9+, 7.2.7+, 7.3.5+, 7.4.1+; 7.5/Cloud są bezpieczne). Zaatakujcie powierzchnię: segmentacja, ACL-e na 7900, wyłączone zarządzanie z internetu. Szukajcie anomalii: połączenia do 7900, modyfikacje /opt/charting/redishb.sh, nietypowe zadania crona, nowe konta admin, pobrania konfiguracji. A potem zróbcie to, co rzadko trafia do OKR-ów: audytujcie dostawcę pod kątem historii łatek i komunikacji. „Secure by design” brzmi ładnie na banerze, ale to log zmian i czas reakcji mówią prawdę.
Na koniec, spokojnie
Edge zostaje na froncie. SIEM-y, firewalle, WAF-y – to pierwsza linia i pierwsza ofiara. Pytanie nie brzmi, czy któraś z tych skrzynek znów okaże się dziurawa. Pytanie brzmi: czy wasza organizacja będzie miała już wtedy zaciągnięte rolety na interfejsach zarządzania i wdrożone łaty, zanim ktoś zapuka w port 7900.
FAQ
Które wersje FortiSIEM są podatne na CVE-2025-64155?
Podatne są gałęzie 6.7.x, 7.0.x, 7.1.0-7.1.8, 7.2.0-7.2.6, 7.3.0-7.3.4 i 7.4.0; FortiSIEM 7.5 i FortiSIEM Cloud nie są podatne. Zaktualizuj do 7.1.9+, 7.2.7+, 7.3.5+ lub 7.4.1+.
Czy luka CVE-2025-64155 jest już wykorzystywana?
Tak, odnotowano ukierunkowane próby na honeypotach i dostępny jest publiczny PoC. To zwykle prowadzi do szybkiej eskalacji ataków.
Jak natychmiast ograniczyć ryzyko, jeśli nie mogę od razu zaktualizować FortiSIEM?
Najpierw ogranicz dostęp do portu 7900 tylko z zaufanych segmentów/VPN. Dodatkowo odetnij interfejs zarządzania od internetu i monitoruj próby połączeń na 7900.
Jakie są oznaki kompromitacji specyficzne dla tego ataku na FortiSIEM?
Najbardziej charakterystyczne to modyfikacja lub wykonania pliku /opt/charting/redishb.sh oraz nowe zadania crona uruchamiane z roota. Sprawdź też nietypowe logowania do phMonitor.
Czy inne produkty Fortinet też są obecnie atakowane?
Tak, aktywnie nadużywane są obejścia SSO w FortiOS/FortiProxy/FortiSwitchManager i FortiWeb (CVE-2025-59718/59719). W FortiWeb wykryto też krytyczną lukę z opóźnioną komunikacją producenta.
Źródła
- [1] https://thehackernews.com/2026/01/fortinet-fixes-critical-fortisiem-flaw.html
- [2] https://techradar.com/pro/security/fortinet-products-hit-by-further-security-flaws-giving-hackers-access-to-systems-and-more
- [3] https://rescana.com/post/critical-fortinet-fortisiem-vulnerability-cve-2024-23108-actively-exploited-risks-attack-analysis
- [4] https://thestack.technology/fortinet-most-trusted/
- [5] https://hackread.com/fortinet-fixes-fortiweb-takeover-flaw-active-attacks/
- [6] https://bleepingcomputer.com/news/security/hackers-exploit-newly-patched-fortinet-auth-bypass-flaws/
- [7] https://cyberscoop.com/fortinet-delayed-disclosure-exploited-vulnerability/
- [8] https://techcrunch.com/2025/01/14/hackers-are-exploiting-a-new-fortinet-firewall-bug-to-breach-company-networks/
- [9] https://thehackernews.com/2025/12/fortinet-ivanti-and-sap-issue-urgent.html
- [10] https://cyberscoop.com/fortinet-fortisiem-critical-vulnerability-ssl-vpn-brute-force-traffic/
To nie jest ozdobnik. To ślad po procesie: ile informacji było szumem, ile stało się wiedzą i jak wyglądał research, zanim powstał ten tekst.
1. Zbieranie sygnałów (discovery)
- RSS - źródeł w configu
- 63
- RSS - stan źródeł
- 63 / 63 OK
- RSS - przepływ (od surowych do unikalnych)
- 2436 -> 2373 -> 377 -> 319
- RSS - usunięte duplikaty tytułów
- 1
- Pula tematów (z RSS)
- 319
- Wybrane do analizy
- 217
- Odrzucone
- 102
- Duplikaty (archiwum tematów)
- 1
- Klastry (wątki)
- 117
2. Selekcja i filtrowanie
- Odrzucono tematycznie (tytuł + słowa kluczowe)
- 3
- Odrzucono jako nieaktualne (filtr daty)
- 11
- Odrzucono semantycznie (embedding)
- 13
3. Wyszukiwanie i wzbogacanie
- Zapytania wyszukiwawcze
- 11
- Unikalne wyniki
- 66
- Kandydaci
- 24
- Dodane z wyszukiwania (cache+live)
- 10
- Przeskanowano URL-i (research)
- 1
4. Finalny kontekst
- Źródła użyte w tekście
- 10
- Źródła (domeny)
- 8
- Wikipedia - kontekst
- nie
- Expansion - kontekst
- nie
- Wyłuskane liczby
- 2




