Pentest systemu wykrywania kradzieży energii.
Od aplikacji do sieci produkcyjnej.
Jak błędy BOLA/IDOR, SSRF i niewystarczająca segmentacja pozwoliły przejść z systemu analitycznego do wydzielonego fragmentu środowiska produkcyjnego dużego dostawcy energii w Polsce.
Nie pojedyncza luka, lecz pełny łańcuch wpływu
W skrócie: podczas autoryzowanego pentestu systemu wspierającego wykrywanie nielegalnego poboru energii potwierdziliśmy błędy autoryzacji obiektowej, możliwość wykonywania żądań serwerowych do zasobów wewnętrznych oraz brak wystarczającej izolacji pomiędzy strefami. Kontrolowana eskalacja wykazała dostęp do ograniczonego fragmentu sieci produkcyjnej. Test przerwaliśmy po uzyskaniu uzgodnionego dowodu wpływu.
- Najważniejsze klasy błędów: BOLA/IDOR, SSRF, nadmiarowe uprawnienia kont usługowych i segmentacja niewymuszająca modelu deny-by-default.
- Wpływ: dostęp do danych innych obiektów, rozpoznanie usług wewnętrznych i możliwość przejścia do strefy o wyższym poziomie zaufania.
- Bezpieczeństwo realizacji: bez ingerencji w sterowanie procesem, bez zmiany parametrów produkcyjnych i bez testów powodujących niedostępność.
- Rezultat: plan naprawczy obejmujący autoryzację serwerową, egress filtering, separację kont i mikrosegmentację.
Autor: Michał Błaszczak · · BSTA sp. z o.o.
podatności
CVSS
kierunek
produkcji
Co zostało celowo zmienione
Nazwa klienta, nazwy systemów, lokalizacje, adresacja, identyfikatory zasobów, endpointy i szczegóły topologii zostały usunięte albo zastąpione danymi syntetycznymi. Zachowaliśmy klasy podatności, kierunek eskalacji i wnioski obronne. Opis nie zawiera informacji pozwalających odtworzyć środowisko klienta.
Od konta aplikacyjnego do strefy o wyższym zaufaniu
BOLA umożliwiała odczyt obiektów należących do innego zakresu organizacyjnego, ponieważ backend sprawdzał poprawność sesji, ale nie relację użytkownik–obiekt. SSRF pozwolił serwerowi aplikacyjnemu wykonywać połączenia do adresów niedostępnych bezpośrednio z Internetu. Dopiero połączenie obu błędów z nadmiarowym zaufaniem sieciowym ujawniło rzeczywisty wpływ.
Ocena techniczna i biznesowa
Serwer aplikacyjny mógł inicjować połączenia do niedozwolonych miejsc docelowych. Brak restrykcyjnego egress filtering i zbyt szerokie reguły pomiędzy strefami zwiększyły wpływ podatności.
Identyfikatory przekazywane przez klienta były traktowane jako wystarczające wskazanie obiektu. Brakowało centralnej kontroli uprawnień na poziomie rekordu i zakresu organizacyjnego.
Konto techniczne posiadało więcej uprawnień i widoczności sieciowej, niż wymagała jego funkcja biznesowa.
Logi nie łączyły działań użytkownika, żądań API i połączeń wychodzących w jeden ślad, co utrudniało szybkie wykrycie podobnego łańcucha.
Rekomendacje w kolejności redukcji ryzyka
- Autoryzacja obiektowa po stronie serwera: każda operacja odczytu i zapisu musi sprawdzać właściciela, tenant, rolę i dozwolony zakres.
- Ochrona przed SSRF: allowlista protokołów i miejsc docelowych, blokada adresów prywatnych i metadanych, ponowna walidacja po przekierowaniu oraz kontrola DNS.
- Mikrosegmentacja: komunikacja wyłącznie po jawnie dozwolonych przepływach; brak domyślnego zaufania do serwerów aplikacyjnych.
- Minimalne uprawnienia: osobne konta usługowe, krótko żyjące poświadczenia i brak sekretów w konfiguracji dostępnej dla aplikacji.
- Detekcja: korelacja nietypowych identyfikatorów obiektów, błędów autoryzacji i połączeń wychodzących w SIEM.
Jak bezpiecznie zaplanowaliśmy pentest energetyki i ścieżki IT/OT
Przed rozpoczęciem testu wspólnie z właścicielami aplikacji, infrastruktury i procesu technologicznego określiliśmy dozwolone systemy, okna czasowe, punkty zatrzymania oraz procedurę eskalacji. Celem było sprawdzenie, czy system analityczny może stać się punktem wejścia do zasobów o wyższym poziomie zaufania, bez wykonywania operacji na urządzeniach sterujących.
Zakres obejmował portal webowy, API, konta użytkowników i usług, komponent pobierający dane, segmentację sieciową oraz monitoring. Po stronie OT dopuszczono wyłącznie pasywną identyfikację i bezpieczne potwierdzenie osiągnięcia uzgodnionej strefy. Zabronione były testy dostępności, skanowanie mogące obciążyć urządzenia, zmiana nastaw, wysyłanie komend procesowych i utrwalanie dostępu.
- web i API: uwierzytelnianie, BOLA/IDOR, role, eksporty, walidacja danych i SSRF;
- infrastruktura: konta usługowe, sekrety, zaufanie serwerów i przepływy wychodzące;
- segmentacja IT/OT: firewalle, jump hosty, strefy DMZ, listy dozwolonych połączeń i mikrosegmentacja;
- detekcja: logi aplikacji, proxy, DNS, firewall, EDR/XDR i scenariusze SOC/SIEM;
- bezpieczeństwo pracy: osoba kontaktowa 24/7, punkt STOP i dokumentowanie każdego kroku.
Dlaczego BOLA, SSRF i segmentacja stworzyły jeden krytyczny scenariusz
BOLA/IDOR zwiększyła widoczność danych i ujawniła identyfikatory związane z innymi obszarami organizacji. Sama luka naruszała poufność, ale nie dawała jeszcze dostępu do sieci wewnętrznej. SSRF zmienił serwer aplikacyjny w pośrednika zdolnego inicjować połączenia z zaufanej strefy. Nadmiarowe uprawnienia konta usługowego i zbyt szerokie reguły sieciowe pozwoliły rozszerzyć ten krok.
Najważniejszym wnioskiem nie było więc „załatanie SSRF”, ale usunięcie kilku założeń o zaufaniu. Aplikacja nie powinna wybierać dowolnego miejsca docelowego, konto nie powinno widzieć więcej niż wymaga funkcja, a serwer w strefie IT nie powinien automatycznie otrzymywać drogi do sieci produkcyjnej. Kontrole muszą być niezależne, aby awaria jednej nie otwierała całego łańcucha.
Potwierdziliśmy osiągnięcie przygotowanego zasobu kontrolnego w wydzielonym fragmencie środowiska. Nie wykonywaliśmy poleceń na sterownikach, nie zmienialiśmy konfiguracji i nie pobieraliśmy danych procesowych.
Od szybkiej blokady do trwałej architektury bezpieczeństwa
Pierwsze 24 godziny
Zawężenie reguł egress, rotacja poświadczeń, blokada dostępu do metadanych i dodatkowe alarmy dla nietypowych połączeń zatrzymały potwierdzony łańcuch. Ryzykowną funkcję aplikacji ograniczono do jawnie zdefiniowanych miejsc docelowych.
Do 30 dni
Backend otrzymał centralną autoryzację obiektową, a konta usługowe rozdzielono według funkcji i strefy. Reguły firewall zostały odtworzone na podstawie zatwierdzonej macierzy przepływów. Do SIEM dodano korelację błędów uprawnień, prób dostępu do adresów prywatnych i nietypowego ruchu serwera aplikacyjnego.
Do 90 dni
Docelowy model obejmował mikrosegmentację, zarządzanie sekretami, okresowy przegląd reguł, testy negatywne w CI/CD oraz ćwiczenie reakcji SOC na ścieżkę IT→OT. Retest zweryfikował pierwotny przypadek oraz warianty z przekierowaniem, zmianą DNS i innymi klasami obiektów API.
Kiedy zamówić pentest dla energetyki, aplikacji przemysłowej lub OT/ICS
Test jest szczególnie wartościowy po wdrożeniu zdalnego dostępu, nowej aplikacji analitycznej, systemu AMI, integracji chmurowej, modernizacji DMZ albo zmianie segmentacji. Warto go wykonać także przed odbiorem systemu od integratora, po incydencie oraz przed istotną oceną bezpieczeństwa KSC/NIS2.
Do przygotowania zakresu potrzebne są: diagram stref i przepływów, lista aplikacji i API, role użytkowników, zasady pracy w OT, krytyczne aktywa, ograniczenia dostępności oraz osoby uprawnione do zatrzymania testu. Pentest może być realizowany etapami — od web/API, przez infrastrukturę, po kontrolowany test segmentacji.
Powiązane usługi: testy penetracyjne OT/ICS od 4 999 zł, pentest infrastruktury i Active Directory, testy API oraz SOC/SIEM i monitoring.
Najczęstsze pytania o pentest energetyki i bezpieczeństwo IT/OT
Czy pentest OT może zatrzymać produkcję lub dystrybucję energii?
Zakres projektujemy tak, aby nie zakłócić procesu. Testy aktywne wykonujemy w bezpiecznej strefie, kopii środowiska lub uzgodnionym oknie, a przy urządzeniach wrażliwych stosujemy analizę pasywną i bezpieczny dowód wpływu.
Czy można sprawdzić segmentację bez atakowania sterowników?
Tak. Można potwierdzić, czy konto, serwer lub jump host osiąga przygotowany zasób kontrolny w kolejnej strefie. Taki test ocenia granice sieci bez wysyłania komend do PLC, RTU lub innych urządzeń procesowych.
Co oznacza SSRF w systemie energetycznym?
SSRF pozwala aplikacji serwerowej wykonywać żądania do wskazanego miejsca. Jeśli serwer ma dostęp do usług wewnętrznych, metadanych chmury lub sąsiedniej strefy, podatność może ominąć barierę widoczną z Internetu.
Dlaczego BOLA/IDOR jest groźna w systemach pomiarowych?
BOLA/IDOR może ujawnić dane innych liczników, lokalizacji, klientów lub obszarów, jeżeli backend nie sprawdza relacji użytkownika z obiektem. W połączeniu z eksportami i automatyzacją problem może być skalowalny.
Czy test obejmuje Active Directory i konta serwisowe?
Tak, jeśli znajdują się w zakresie. Weryfikujemy uprawnienia, delegacje, sekrety, ścieżki eskalacji, konta używane w obu strefach i możliwość ruchu bocznego.
Jakie metodyki stosujecie?
Zakres budujemy w oparciu o PTES, OWASP ASVS/API, CIS i podejście właściwe dla OT/ICS. Wyniki oceniamy technicznie i biznesowo, uwzględniając bezpieczeństwo ludzi oraz ciągłość procesu.
Ile trwa pentest systemu energetycznego?
Realizacja testu zajmuje od 5 dni roboczych. Czas zależy od liczby stref, aplikacji, ról, lokalizacji i ograniczeń operacyjnych, a ostateczny termin potwierdza oferta.
Czy wykonujecie retest po naprawach?
Tak. Jedno podejście retestowe jest zazwyczaj w cenie, o ile oferta nie stanowi inaczej. Weryfikujemy poprawkę oraz to, czy podobny przepływ nie występuje w innym komponencie.
Co ten pentest wnosi do zarządzania ryzykiem
Energetyka jest sektorem kluczowym wskazanym w ustawie o krajowym systemie cyberbezpieczeństwa. KSC/NIS2 nie oznacza automatycznie identycznego pentestu dla każdej organizacji, lecz wymaga zarządzania ryzykiem i oceny skuteczności zabezpieczeń. Taki test dostarcza technicznych dowodów dotyczących autoryzacji, segmentacji, podatności i zdolności detekcji.
Źródła: Ministerstwo Cyfryzacji — sektory KSC, OWASP API Security i CIS Controls.
Chcesz sprawdzić, czy aplikacja otwiera drogę do sieci produkcyjnej?
Łączymy pentest aplikacji i API z kontrolą infrastruktury, segmentacji oraz bezpiecznym testem ścieżek IT/OT.
Zapytaj o zakres testu →