Aktualności

FrostyGoop i cyberzimna wojna: jak złośliwe oprogramowanie zakłóciło lwowską infrastrukturę krytyczną

W styczniu 2024 r. cyberatak zaatakował ciepłownię we Lwowie na Ukrainie [1], pozostawiając prawie 600 budynków bez ogrzewania przez 48 godzin, podczas gdy temperatura na zewnątrz oscylowała wokół zera [2]. Dragos, firma specjalizująca się w cyberbezpieczeństwie przemysłowych systemów sterowania (ICS) i technologii operacyjnych (OT), dokładnie przeanalizowała ten incydent[3]. [W kwietniu 2024 r. zespół Dragos zidentyfikował złośliwe oprogramowanie odpowiedzialne za ten atak, nadając mu nazwę FrostyGoop. To złośliwe oprogramowanie atakuje urządzenia przemysłowe korzystające z protokołu Modbus TCP/IP. Wykorzystując ten protokół, FrostyGoop może zakłócać regularne działanie tych urządzeń, potencjalnie prowadząc do wielu problemów, takich jak ich wyłączenie. Aby lepiej zrozumieć, jak działa FrostyGoop, najpierw należy omówić protokół Modbus.

Modbus

Protokół Modbus, opracowany przez firmę Modicon w 1979 roku, jest jednym z najczęściej używanych protokołów komunikacyjnych w sektorze przemysłowym. Pomimo ponad czterech dekad, Modbus pozostaje kamieniem węgielnym w automatyce przemysłowej ze względu na swoją prostotę i niezawodność. Protokół ten umożliwia wymianę danych między różnymi urządzeniami, takimi jak czujniki, siłowniki, napędy i sterowniki.

Tabela 1 Kilka arbitralnie wybranych przykładów rozwiązań oferowanych przez najbardziej renomowanych producentów automatyki. Tabela pokazuje, że Modbus jest nadal szeroko stosowany.

Pierwotnie Modbus był używany z protokołami komunikacji szeregowej, takimi jak RS-232 i RS-485. Jednak w miarę jak sieci przemysłowe stawały się coraz bardziej wyrafinowane, Modbus został rozszerzony do pracy przez TCP/IP, pakiet protokołów używany w większości nowoczesnych sieci, w tym w Internecie. Modbus TCP/IP pozwala urządzeniom komunikować się za pośrednictwem sieci Ethernet, dzięki czemu integracja z istniejącą infrastrukturą IT jest bardziej dostępna i umożliwia zdalne monitorowanie i sterowanie procesami przemysłowymi.

Modbus TCP/IP działa w architekturze klient-serwer, jak pokazano na rysunku. W tej konfiguracji serwer jest zazwyczaj urządzeniem, takim jak czujnik, miernik lub siłownik, który przechowuje dane w określonych lokalizacjach pamięci zwanych rejestrami. Klient, taki jak sterownik PLC (Programmable Logic Controller) lub system SCADA (Supervisory Control and Data Acquisition), żąda danych z serwera lub wysyła do niego polecenia.

Rysunek 1 Architektura klienta/serwera Modbus TCP/IP. Klient Modbus TCP/IP może kontrolować (zapisywać wybrane wartości do rejestrów) lub monitorować (odczytywać wybrane wartości rejestrów) komponenty przemysłowe z zaimplementowanym serwerem Modbus TCP/IP.

Jedną z krytycznych koncepcji w protokole Modbus jest użycie rejestrów przechowujących. Rejestry przechowujące to 16-bitowe lokalizacje pamięci w urządzeniu serwerowym, które mogą przechowywać różne dane. Rejestry te umożliwiają klientowi bezpośredni odczyt lub zapis danych. Klient może odczytywać rejestry przechowujące z serwera w celu uzyskania danych, takich jak odczyty czujników lub informacje o stanie. Na przykład, jeśli masz czujnik temperatury z zaimplementowanym serwerem Modbus, bieżąca temperatura może być przechowywana w określonym rejestrze przechowywania. Klient może pobrać wartość temperatury, odczytując ten rejestr w celu monitorowania lub dalszego przetwarzania. Oprócz odczytu danych, klienci mogą również zapisywać dane do rejestrów przechowywania. Jest to powszechnie używane do sterowania urządzeniami. Na przykład, klient może zapisać wartość do rejestru przechowującego, aby ustawić cel

temperatura na termostacie lub dostosuj prędkość silnika. Możliwość ta pozwala na kontrolę procesów przemysłowych w czasie rzeczywistym w oparciu o dynamiczne dane wejściowe.

Ze względu na wiek protokołu Modbus, ma on znaczące ograniczenie w nowoczesnych standardach bezpieczeństwa – brakuje mu wsparcia zarówno dla uwierzytelniania, jak i autoryzacji. Aby nawiązać komunikację z serwerem Modbus TCP/IP, klient potrzebuje tylko następujących informacji:

Jako prosty protokół, Modbus pozwala jedynie na odczyt i nadpisywanie wartości liczbowych w określonych rejestrach. Zmienne te nie są z natury opisane w samym protokole. Producenci, którzy produkują urządzenia ze zintegrowanym serwerem Modbus TCP/IP, zazwyczaj dostarczają mapę rejestrów w swojej dokumentacji, wyszczególniającą, które parametry odpowiadają poszczególnym adresom.

Poniższy przykład ilustruje połączenie z serwerem Modbus TCP/IP hostowanym na komputerze lokalnym o adresie IP 127.0.0.1 i identyfikatorze urządzenia 1. W tym scenariuszu odczytywanych jest 20 rejestrów, począwszy od pierwszego rejestru pod adresem 0. Pierwsze sześć rejestrów(adresy 0-5) zwraca aktualną datę i godzinę. Jednak określenie znaczenia kolejnych wartości wymagałoby zapoznania się z dokumentacją urządzenia.

Rysunek 2 Przykład oprogramowania klienckiego Modbus TCP/IP. Widoczne są wartości rejestrów przechowywania. Narzędzie umożliwia nadpisanie wartości rejestru poprzez wybranie danego pola i edycję numeru. Oprogramowanie jest bezpłatne i można je pobrać ze strony https://en.radzio.dxp.pl/modbus-master-simulator/.

FrostyGoop

Po omówieniu teoretycznych podstaw protokołu Modbus łatwiej jest zrozumieć koncepcję stojącą za złośliwym oprogramowaniem FrostyGoop, które wyraźnie atakuje urządzenia korzystające z tego protokołu.

FrostyGoop to złośliwy program przeznaczony do uruchamiania w systemach Windows. Został napisany w języku programowania Golang i wykorzystuje publicznie dostępne biblioteki Modbus na GitHub[4]. [ To złośliwe oprogramowanie może odczytywać i nadpisywać rejestry przechowywania na serwerze Modbus TCP/IP. Jego konfigurację można ustawić za pomocą opcjonalnych argumentów wiersza poleceń lub określając plik konfiguracyjny w formacie JSON. Aby złośliwe oprogramowanie działało, wymagany jest adres IP serwera Modbus TCP/IP, tryb działania (tryb odczytu lub zapisu rejestrów) oraz docelowe adresy rejestrów . Dlatego, jak wspomniano wcześniej, FrostyGoop może być postrzegany jako klient Modbus TCP/IP, który wykonuje złośliwe działania poprzez wstrzykiwanie nieprawidłowych danych do rejestrów urządzenia. Ponieważ dane te często reprezentują parametry kontrolne urządzeń przemysłowych, złośliwe oprogramowanie może znacząco wpłynąć na działanie procesów technologicznych.

Poniższa ilustracja przedstawia przykład ruchu sieciowego generowanego przez FrostyGoop, zaobserwowanego w Wireshark.

Rysunek 3 Przykładowy ruch generowany przez FrostyGoop wydaje się być legalnym ruchem generowanym przez innych klientów Modbus TCP/IP. Możemy zobaczyć pakiety związane z odczytem danych z serwera (Read Holding Registers) i zapisem danych do urządzenia (Write Single/Multiple Registers). [3]

Według analizy przeprowadzonej przez zespół Dragos, złośliwe oprogramowanie zostało wykryte w sieci ofiary, która składała się z routera, serwerów i kontrolerów systemu grzewczego (hakerzy prawdopodobnie uzyskali dostęp do tej sieci poprzez lukę w routerze). Złośliwe żądania Modbus były wysyłane bezpośrednio do sterowników systemu grzewczego z routera.

do komputerów hakerów za pośrednictwem zakodowanych tras sieciowych. Celem ataku były sterowniki systemów grzewczych marki ENCO. Co ciekawe, atakujący zdalnie obniżyli również klasę tych urządzeń, powodując, że odczyty pomiarów stały się niedokładne i utraciły widoczność dla operatorów ciepłowni. Powiązany plik konfiguracyjny FrostyGoop(task_test.json) zawierał adres IP należący do urządzenia sterującego ENCO ujawnionego w Internecie. Doprowadziło to Dragosa do oceny ze średnią pewnością, że przed tym atakiem FrostyGoop był również używany do atakowania jednego lub więcej kontrolerów ENCO, w których port TCP 502 był dostępny w Internecie[3]. [W związku z tym złośliwe oprogramowanie było najprawdopodobniej odpowiedzialne za brak ciepła w ponad 600 budynkach we Lwowie w styczniu 2024 roku.

Jak niebezpieczny jest FrostyGoop?

Urządzenia z protokołem Modbus TCP/IP wystawione na działanie publicznego Internetu są bezpośrednio podatne na złośliwe oprogramowanie podobne do FrostyGoop. Ponieważ protokół Modbus TCP/IP nie obsługuje uwierzytelniania, możliwe jest połączenie się z dostępnymi hostami i próba zmiany wartości rejestrów, co może mieć bezpośredni wpływ na działanie fizycznych urządzeń przemysłowych.

Poniższa ilustracja przedstawia szacunkową liczbę urządzeń z portem 502 otwartym online. Grupa Dragos szacuje, że z tych 640 000 zasobów, około 46 000 urządzeń może być podatnych na ataki.

Rysunek 4 Wyniki wyszukiwania publicznie dostępnych urządzeń z otwartym portem 502 na platformie Shodan.

Urządzenia znajdujące się w lokalnych sieciach przemysłowych znajdują się na drugim poziomie ryzyka. Jeśli atakujący uzyska dostęp do sieci wewnętrznej, złośliwe działania przeciwko tym urządzeniom mogą stać się możliwe. Jeśli atakujący ma na celu zakłócenie prawidłowego funkcjonowania sieci przemysłowej

Urządzenia komunikujące się za pośrednictwem protokołu Modbus mogą być jednym z ich głównych celów.

Zalecenia

Ta sekcja będzie cenna dla tych, którzy pracują z urządzeniami z zaimplementowanym serwerem Modbus TCP/IP i chcą ograniczyć związane z tym ryzyko. Powyższa dyskusja prowadzi do jednego kluczowego wniosku:

Jest to najbardziej podstawowa i krytyczna zasada zwiększania bezpieczeństwa przemysłowych systemów sterowania (ICS) i środowisk technologii operacyjnych (OT), które wykorzystują protokół Modbus. Aby jeszcze bardziej wzmocnić bezpieczeństwo tych systemów, możemy rozważyć wdrożenie dodatkowych środków wymienionych w poniższej tabeli.

Tabela 2 Proponowane środki mające na celu ograniczenie ryzyka związanego z urządzeniami ICS komunikującymi się za pośrednictwem protokołu Modbus TCP/IP. Warto jednak zauważyć, że środki te mogą skutecznie przeciwdziałać znacznie szerszemu zakresowi zagrożeń. Środki te są powiązane ze środkami łagodzącymi opisanymi w ramach MITRE ATT&CK ICS w ostatniej kolumnie.

ZmierzOpisMITRE ATT&CK ICS Mitigations Reference
Sieć SegmentacjaZaimplementuj segmentację sieci, aby odizolować urządzenia Modbus TCP/IP od innych części sieci, w szczególności od publicznego Internetu i innych niezaufanych sieci. Tworząc odrębne strefy sieciowe, ograniczasz potencjalne rozprzestrzenianie się ataku, utrudniając intruzom dostęp do wrażliwych systemów. M0930: Sieć Segmentacja
Korzystanie z alternatywnych protokołów przemysłowychTam, gdzie to możliwe, szyfruj ruch sieciowy, aby chronić dane przesyłane między klientami a serwerami. Chociaż sam Modbus nie obsługuje szyfrowania, możesz tunelować ruch Modbus przez VPN (Virtual Private Network). M0802: Komunikacja Autentyczność
Ciągły Monitorowanie sieciWdróż ścisłą kontrolę dostępu, aby ograniczyć, kto może komunikować się z urządzeniami Modbus. Użyj zapór sieciowych, aby ograniczyć dostęp do serwera Modbus TCP/IP tylko do zaufanych adresów IP. M0931: Sieć Zapobieganie Zapobieganie
Dostęp Kontrola i Zapory siecioweRegularnie monitoruj swoją sieć przemysłową pod kątem nietypowej lub nieautoryzowanej aktywności. Wdrożenie systemu wykrywania włamań (IDS) lub systemu zapobiegania włamaniom (IPS) specjalnie dostosowanego do sieci przemysłowych może pomóc w identyfikacji potencjalnych zagrożeń w czasie rzeczywistym, umożliwiając szybką reakcję. M0807: Sieć Zezwalaj na listy
Szyfrowanie ruchu Ruch sieciowyJeśli to możliwe, szyfruj ruch sieciowy, aby chronić dane przesyłane między klientami a serwerami. Chociaż Modbus nie obsługuje szyfrowania, możesz tunelować ruch Modbus przez VPN (Virtual Private Network). M0808: Szyfruj Ruch sieciowy
Bezpieczeństwo AudytyPrzeprowadzaj regularne audyty bezpieczeństwa i oceny podatności środowisk ICS i OT. Oceny te mogą pomóc zidentyfikować słabe punkty w bieżącej konfiguracji i zapewnić wgląd w obszary wymagające poprawy. M0947: Audyt

Postępując zgodnie z powyższymi praktykami, możemy znacznie zmniejszyć ryzyko cyberzagrożeń dla naszych urządzeń Modbus TCP/IP i poprawić ogólne bezpieczeństwo sieci przemysłowej.

Głębsze zanurzenie w hakowaniu Modbus

W celu lepszego zrozumienia zagrożeń związanych z protokołem Modbus przygotowano i przedstawiono w tej sekcji niewielką symulację. W ramach symulacji napisano trzy krótkie programy w języku Python przy użyciu biblioteki pyModbusTCP. [5]

Pierwszy program symuluje sterownik systemu grzewczego działający jako serwer Modbus TCP/IP.

Następny program jest przykładem klienta Modbus TCP/IP. Po uruchomieniu tego programu pojawi się okno podobne do pokazanego na poniższym rysunku. Okno to symuluje interfejs wizualizacji zwykle używany przez operatorów odpowiedzialnych za monitorowanie i sterowanie systemem grzewczym. Program pobiera dane z wcześniej uruchomionego serwera. W interfejsie dostępne są następujące parametry:

Rysunek 5 Proste okno przypominające SCADA do monitorowania systemu ogrzewania.

Temperatura wewnętrzna budynku zmienia się w sposób ciągły podczas symulacji. System ogrzewania wyłącza się po przekroczeniu temperatury zadanej(Status ogrzewania: Wył.). Następnie temperatura zaczyna spadać. Gdy temperatura spadnie poniżej wartości zadanej pomniejszonej o histerezę, system ogrzewania włączy się (Status ogrzewania: Wł.), a temperatura wzrośnie. System działa prawidłowo, utrzymując temperaturę w pobliżu temperatury zadanej.

Trzeci program symuluje klienta próbującego wykonać złośliwą akcję przeciwko systemowi grzewczemu. Uruchom go za pomocą następującego polecenia:

Ten program wykonuje prosty atak – łączy się z serwerem Modbus TCP/IP i rozpoczyna zapisywanie zer do rejestrów podtrzymujących co sekundę. To działanie resetuje temperaturę zadaną i histerezę do zera. Ponieważ temperatura zadana wynosi zero, system ogrzewania nigdy się nie aktywuje, powodując spadek temperatury. Ostatecznie na wizualizacji pojawia się status ostrzeżenia. [COLD!].

Rysunek 6 Symulacja prostego ataku destrukcyjnego na system grzewczy z serwerem Modbus TCP/IP. Atakujący wpisuje zera do rejestrów podtrzymujących.

W tym scenariuszu przeprowadziliśmy podstawową symulację ataku na serwer Modbus TCP/IP, zakłócając działanie systemu grzewczego i zmuszając go do ciągłego wyłączania.

Podziękowania

Z przyjemnością uczestniczyłem w webinarium Cold Reality: The Impact of FrostyGoop Modbus Malware on Connected OT Systems w dniu 6 sierpnia 2024 r., przygotowanym przez zespół Dragos . Chcę im podziękować za publiczne udostępnienie ich analizy.

Bibliografia

[1] Н. Карнаух, “Частина Львова залишилась без опалення та гарячої води: слідчі перевіряють версію про хакерську атаку,” styczeń 2024. [Online]. Dostępne: https://suspilne.media/lviv/667490-castina-lvova-zalisilas- bez-opalenna-ta-garacoi-vodi-slidci-pereviraut-versiu-pro-hakersku-ataku/.
[2] A. Greenberg, “How Russia-Linked Malware Cut Heat to 600 Ukrainian Buildings in Deep Winter,” WIRED, lipiec 2024. [Online]. Dostępne: https://www.wired.com/story/russia-ukraine-frostygoop-malware-heating-utility/.
[3] Dragos, “Impact of FrostyGoop ICS Malware on Connected OT Systems”, lipiec 2024. [Online]. Dostępne: https://hub.dragos.com/hubfs/Reports/Dragos-FrostyGoop-ICS-Malware-Intel-Brief-0724_r2.pdf?hsLang=en.
[4] [Online]. Dostępne: https://github.com/rolfl/modbus.
[5] [Online]. Dostępne: https://pymodbustcp.readthedocs.io/en/latest/quickstart/index.html.