Jak sprawdzić czy sterowniki są wystawione do sieci? Shodan i testowanie branży przemysłowej
Sprawdź, jak za pomocą Shodana wykrywać wystawione sterowniki przemysłowe i analizować bezpieczeństwo systemów. Poradnik testów sieciowych.
Shodan i sprawdzanie wystawionych sterowników na świat: czyli jak zgubić własne ICS w internecie
Materiał ma charakter edukacyjny. Wszystko, co tu pokazuję, testuj wyłącznie na własnym sprzęcie albo za pisemną zgodą właściciela, jak w Minecrafcie: we własnym świecie, nie na cudzym serwerze. W Polsce sam nieuprawniony dostęp do systemu jest karalny (art. 267 i następne k.k.), a prywatność nie istnieje, bo logi u dostawcy, fingerprint, NASK i CBZC prędzej czy później Cię znajdą. To nie jest porada prawna.
Ze wszystkiego, co Shodan widzi otwarte, najgorsza kategoria to systemy sterowania przemysłowego. Bo tu „otwarty port" nie oznacza wycieku tabelki z bazy. Oznacza sterownik, który zarządza prądem, wodą albo ciepłem, i który właśnie odpowiada na zaczepki całego internetu. To jest ten moment, w którym rekonesans przestaje być ćwiczeniem, a zaczyna być sprawą bezpieczeństwa.
Jedna rzecz na wstępie, ważniejsza niż zwykle: w przypadku ICS robimy wyłącznie pasywne rozpoznanie, czyli czytamy to, co Shodan już zebrał. Nie wysyłamy do tych urządzeń żadnych komend. Protokoły przemysłowe w bazowej formie często nie mają uwierzytelniania, więc „sprawdzenie" zapisu to nie test, tylko realna ingerencja w proces fizyczny. Od czytania banera nikomu nie zgaśnie światło. Od wysłania ramki Modbus już może.
Dlaczego ICS w ogóle wisi w internecie
Nikt nie projektuje sterownika z myślą „wystawmy go na świat". A jednak wiszą, i to z powtarzalnych, ludzkich powodów.
Najczęstszy to zdalny serwis. Ktoś potrzebował dostać się do HMI albo PLC z domu czy od integratora, więc wystawił dostęp „na chwilę, do diagnostyki", przez przekierowanie portu, RDP, VNC albo publiczny adres. Chwila się przedłużyła do kilku lat. Drugi powód to brak segmentacji: sieć IT i OT siedzą razem, płasko, bez firewalla między nimi, więc to, co miało być w odizolowanej strefie procesowej, jest o jeden routing od internetu.
Do tego dochodzi mentalność utrzymania ruchu. W świecie OT priorytetem jest dostępność, nie poufność. „Działa, to nie ruszaj" jest racjonalne, gdy zatrzymanie linii kosztuje fortunę, ale fatalne, gdy oznacza niezmienione domyślne hasło przez dekadę. No i legacy: sprzęt bez wsparcia, firmware, którego nie da się załatać, protokoły zaprojektowane w czasach, gdy „sieć" znaczyła kabel w zamkniętej hali. Całość spina jedno błędne założenie, że skoro nikt nie zna naszego adresu, to jesteśmy bezpieczni. Shodan istnieje właśnie po to, żeby to założenie obalić.
Protokoły, które zdradzają
Sterownik nie krzyczy „jestem elektrownią". Zdradza go protokół, którym mówi, a każdy ma swój domyślny port:
- Modbus/TCP (502) to dziadek automatyki przemysłowej, wszechobecny i z natury bez uwierzytelniania
- DNP3 (20000) to protokół smart grid, używany głównie w utilities, czyli elektroenergetyce i wodociągach
- IEC 60870-5-104, w skrócie IEC-104 (2404) to standard telemechaniki sieci elektroenergetycznych, mocno europejski
- IEC 61850 MMS, ICCP oraz Siemens S7 (102) to automatyka stacji i komunikacja między centrami sterowania
- EtherNet/IP (44818), Niagara Fox (1911 i 4911), OPC UA (4840) to kolejne podejrzane, a BACnet (47808) to raczej automatyka budynkowa
I tu uwaga, która oddziela kogoś, kto rozumie temat, od kogoś, kto przepisał listę portów: port 102 dzielą naraz Siemens S7, IEC 61850 i ICCP, a wiele protokołów chodzi na kilku portach. Dlatego klasyfikacja po samym numerze portu jest zawodna. Shodan nie zgaduje po porcie, tylko parsuje baner, więc to w banerze, nie w numerze, siedzi prawdziwa identyfikacja urządzenia.
Jak to wygląda w Shodanie
Pasywne rozpoznanie zaczynasz od portu protokołu, zawężonego do interesującego obszaru:
port:502 country:PL port:2404 country:PL port:20000
Dla sterowników Shodan często wyciąga z banera konkretne dane: identyfikator urządzenia Modbus, informacje o module przy S7, vendora, model, czasem wersję firmware. To znaczy, że już z samego rekordu wiesz, z czym masz do czynienia, bez wysyłania czegokolwiek. Shodan utrzymuje też dedykowane narzędzia do ekspozycji ICS, więc skalę problemu możesz oglądać zbiorczo, a nie rekord po rekordzie.
I na tym discovery się kończy. Czytasz baner, analizujesz ekspozycję, raportujesz. Nie nawiązujesz sesji protokołem przemysłowym, nie wysyłasz odczytów ani zapisów. Powtarzam to celowo, bo to jedyna granica, której w ICS naprawdę nie wolno przekroczyć ani z ciekawości, ani „żeby potwierdzić".
Najczęstsze błędy na produkcji
Jak już patrzysz na cudzą (albo własną) ekspozycję, te grzechy powtarzają się do znudzenia:
- HMI albo panel SCADA wystawiony przez RDP (3389) lub VNC (5900) wprost na internet, regularnie z domyślnym albo słabym hasłem
- port inżynierski sterownika (502, 102, 44818) widoczny publicznie, bo „tak było wygodniej serwisować"
- zero VPN i zero jump hosta, dostęp do OT prosto z sieci publicznej
- niezmienione domyślne poświadczenia producenta
- webowy panel sterownika (na przykład Niagara) z fabrycznym loginem
- płaska sieć, w której z firmowego Wi-Fi widać strefę procesową
Każdy z tych punktów z osobna jest błędem. Razem to instrukcja, jak oddać komuś kontrolę nad procesem fizycznym.
Jak nie trafić do tego nagłówka
Obrona nie jest egzotyczna, jest tylko rzadko wdrażana. Żaden element OT nie powinien mieć publicznego adresu, kropka. Zdalny dostęp wyłącznie przez VPN i jump host, nigdy goły port. Segmentacja IT od OT z prawdziwym firewallem pomiędzy, najlepiej w duchu modelu Purdue. Zmiana domyślnych haseł i wyłączenie nieużywanych usług. A na koniec monitoring własnej ekspozycji: ustaw alert Shodana na swoje zakresy (pokazywałam to w części o CLI i API), żeby dowiedzieć się o wystawionym sterowniku od narzędzia, a nie z wiadomości.
Dirty fact: to nie są hipotezy z prezentacji. Stuxnet uderzył w sterowniki Siemens S7. Industroyer, znany też jako CrashOverride, posłużył się dokładnie protokołami energetyki, w tym IEC-104 i IEC 61850, i stoi za realnym wyłączeniem prądu w Kijowie w 2016 roku. Triton celował w systemy bezpieczeństwa instalacji przemysłowej. Każdy z tych ataków zaczynał się od dostępu do tego, co miało być nieosiągalne.
W IT otwarty port to incydent. W energetyce to ryzyko, że ktoś zgasi światło całemu miastu. Dlatego mapę ekspozycji rób sumiennie, raportuj szybko, a palca od sterownika trzymaj z daleka. A na wschodniej flance, gdzie akurat mieszkamy, to nie jest rozważanie akademickie, tylko bieżący stan zagrożenia.
Terminarz
Lista najbliższych webinariów
Zobacz inne wpisy
Wiedza i świadomość na temat aktualnych cyberzagrożeń to podstawa dobrej taktyki bezpieczeństwa. Chcesz być na bieżąco z wydarzeniami ze świata cybersecurity? A może szukasz wskazówek jak zapewnić wyższy poziom cyberbezpieczeństwa w swojej firmie? Chcesz poznać topowe rozwiązania? Dobrze trafiłeś.
Testy Socjotechniczne: Symulacje Phishingu
Sprawdź w kontrolowanych i bezpiecznych warunkach czy Twoi pracownicy są odporni na phishing i inne metody socjotechniczne. Obejmują one phishing e-mailowy, vishing (ataki telefoniczne) czy smishing (SMS), skupiając się na ludzkim czynniku w cyberbezpieczeństwie.
Testy Penetracyjne Sieci
Zapoznaj się z ofertą testy penetracyjnych sieci. Zabezpiecz infrastrukturę krytyczną przed atakami. Poznaj zagrożenia, podatności i luki. Na koniec otrzymasz szczegółowy raport z rekomendacjami.
Testy Penetracyjne Aplikacji
Testy penetracyjne aplikacji webowych to skuteczny sposób na ochronę stron internetowych, sklepów online i portali przed cyberatakami. Symulują ataki hakerskie, wykrywając luki w zabezpieczeniach, takie jak SQL Injection czy XSS, zanim wykorzystają je przestępcy.