Luka o krytycznej ocenie 9.8 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki) v3.1 [^1] została zidentyfikowana w bramach jednokierunkowych Waterfall WF-500. Urządzenia te są często stosowane do ochrony sieci przemysłowych (OT), w tym w polskim sektorze energetycznym i infrastrukturze krytycznej. Problem umożliwia zdalnemu, nieuwierzytelnionemu atakującemu całkowite ominięcie mechanizmów logowania i uzyskanie pełnych uprawnień administracyjnych [^2].

Błąd dotyczy oprogramowania w wersji 7.9.1.0 R2502171040 i wcześniejszych [^3] [^4]. Ze względu na prostotę eksploatacji, wymagającą jedynie znajomości adresu IP urządzenia [^5], oraz krytyczną rolę tych bramek w architekturze bezpieczeństwa, ryzyko dla operatorów jest wysokie. Dostawca opublikował już aktualizację oprogramowania [^6].

TL;DR

  • Produkt: Bramy jednokierunkowe Waterfall WF-500 TX i RX Hosts.
  • Luka: CVE-2025-41273, ominięcie uwierzytelniania (CWE-288: Authentication Bypass Using an Alternate Path or Channel) [^7] [^8].
  • Wektor ataku: Nieuwierzytelnione żądanie HTTP GET [^9] do specjalnie przygotowanego punktu końcowego API, który nie waliduje sesji [^10].
  • Wpływ: Pełna, zdalna kontrola administracyjna nad urządzeniem [^11]. Możliwość odczytu konfiguracji, modyfikacji ustawień, a także potencjalnego ruchu bocznego do chronionej sieci OT [^12].
  • Dotyczy: Wszystkie jednostki z oprogramowaniem w wersji 7.9.1.0 R2502171040 i wcześniejszych [^4].
  • Pierwszy ruch: Identyfikacja podatnych urządzeń w sieci i natychmiastowa aktualizacja oprogramowania do wersji v7.10.0.0 R2601141040 lub nowszej [^13].

Wektor ataku

Bramy jednokierunkowe, takie jak Waterfall WF-500, to sprzętowe rozwiązania bezpieczeństwa zaprojektowane do fizycznego uniemożliwienia przepływu danych z sieci o wysokim poziomie zaufania (np. sieć przemysłowa OT) do sieci o niższym zaufaniu (np. sieć korporacyjna IT). Pozwalają na monitorowanie systemów OT bez ryzyka wprowadzenia złośliwego ruchu z zewnątrz. Luka w takim komponencie podważa fundamentalne założenia bezpieczeństwa całej architektury.

Problem, sklasyfikowany jako CWE-288 (Common Weakness Enumeration — klasyfikacja typów luk) [^8], leży w interfejsie webowym urządzenia. Telemetria wskazuje, że wewnętrzny punkt końcowy API, używany przez panel administracyjny, nie weryfikuje tokenów sesji dla niektórych żądań [^10]. Oznacza to, że serwer WWW udostępnia alternatywną ścieżkę dostępu, która nie jest chroniona standardowym filtrem uwierzytelniania [^14].

Atakujący nie potrzebuje żadnych poświadczeń. Wystarczy, że zna adres IP podatnego urządzenia [^5]. Następnie wysyła proste żądanie HTTP GET [^9] pod jeden z niechronionych adresów URL, na przykład /console/api/status lub /console/debug [^14]. Serwer, zamiast zażądać logowania, nie sprawdza ani plików cookie, ani tokenów, ani nagłówków uwierzytelniających [^15]. Przetwarza żądanie tak, jakby pochodziło od zalogowanego administratora [^16].

Skutki udanego ataku są poważne. Atakujący uzyskuje pełną kontrolę administracyjną nad bramą [^11]. Może wykonywać dowolne akcje dostępne dla administratora, w tym:

  • Odczytywać wrażliwe dane konfiguracyjne [^12].
  • Modyfikować ustawienia sieciowe i polityki bezpieczeństwa [^12].
  • Pobierać logi systemowe, potencjalnie zacierając ślady swojej aktywności [^12].
  • Wyzwoalać aktualizacje oprogramowania układowego, co może prowadzić do wgrania zmodyfikowanej wersji [^12].
  • Potencjalnie wpływać na systemy w sieci OT, które ufają bramie WF-500 [^17].

Atak nie wymaga żadnej interakcji ze strony prawowitego użytkownika [^18]. Jego złożoność jest niska, co w połączeniu z krytycznym wynikiem CVSS 9.8 [^1] czyni tę lukę szczególnie istotną dla polskich podmiotów objętych dyrektywą NIS2 (unijna dyrektywa o bezpieczeństwie sieci), zwłaszcza w sektorze energetycznym, wodociągowym czy transporcie.

Wskaźniki kompromitacji

Nie zidentyfikowano publicznych wskaźników kompromitacji (IoC — Indicators of Compromise) takich jak hashe plików czy adresy IP serwerów C2 (Command and Control — serwer kontrolujący zainfekowane maszyny). Jednakże możliwe jest poszukiwanie śladów prób wykorzystania luki. Rekomendujemy analizę logów serwera WWW na urządzeniach Waterfall WF-500 pod kątem żądań do niestandardowych ścieżek API.

Należy szukać żądań HTTP GET kierowanych do poniższych (lub podobnych) ścieżek, pochodzących z nieautoryzowanych lub nieoczekiwanych adresów IP:

/console/api/status
/console/debug

Obecność takich zapytań w logach, zwłaszcza z zewnętrznych adresów IP lub z segmentów sieci, które nie powinny mieć dostępu do interfejsu zarządzania, jest silnym sygnałem próby ataku. Należy potraktować to jako incydent bezpieczeństwa.

Co zrobić w 24-48h

Rekomendowane podejście zakłada natychmiastowe działania w celu mitygacji ryzyka. Poniższe kroki nie zastępują pełnej analizy incydentu, ale stanowią pierwszą linię obrony.

  1. Identyfikacja zasobów. Priorytetem jest stworzenie listy wszystkich urządzeń Waterfall WF-500 TX i RX w infrastrukturze. Należy zweryfikować wersję oprogramowania układowego każdego z nich. Podatne są wszystkie wersje do 7.9.1.0 R2502171040 włącznie [^4].

  2. Natychmiastowa aktualizacja. Dostawca, Waterfall Security Solutions, udostępnił poprawioną wersję oprogramowania 29 maja 2026 roku [^6]. Należy bezzwłocznie zaktualizować wszystkie zidentyfikowane urządzenia do wersji v7.10.0.0 R2601141040 lub nowszej [^13].

  3. Tymczasowa mitygacja (jeśli aktualizacja jest niemożliwa). W środowiskach OT natychmiastowa aktualizacja bywa trudna. Jeśli nie można jej przeprowadzić, należy zablokować dostęp sieciowy do interfejsu webowego (domyślnie port TCP/443) z niezaufanych sieci [^19]. Można to zrealizować za pomocą reguł na zaporze sieciowej lub list kontroli dostępu (ACL).

  4. Segmentacja sieci zarządzania. Należy zweryfikować, czy interfejs zarządzania urządzeń WF-500 jest odizolowany od reszty sieci. Rekomendowane podejście to umieszczenie go w dedykowanym VLAN-ie zarządczym lub udostępnienie go wyłącznie przez sieć VPN (Virtual Private Network) [^20]. Dostęp do panelu administracyjnego z otwartej sieci korporacyjnej, a tym bardziej z internetu, jest niedopuszczalną praktyką.

  5. Analiza logów. Przejrzyj logi dostępowe urządzeń w poszukiwaniu wskaźników opisanych w poprzedniej sekcji. Dla polskich operatorów usług kluczowych, zgodnie z dyrektywą NIS2, udokumentowanie takiej analizy jest kluczowe w kontekście zarządzania ryzykiem i raportowania incydentów do właściwego CSIRT.

Atrybucja

Luka została zidentyfikowana i odpowiedzialnie zgłoszona do producenta przez badacza Luca Borzacchiello z zespołu Nozomi Networks Labs [^21] [^7].

Zobacz też