Ataki na automatykę przemysłową
-
- 07.12.2012
Awarie automatyki przemysłowej mogą wiązać się z bardzo poważnymi zdarzeniami, obejmując swoim zasięgiem wiele obszarów. Rozwiązania te mogą być także celem ataku.
Systemy automatyki składają się ze sprzętu (kontrolerów, komputerów) oprogramowania i urządzeń komunikacji. Znajdują swoje miejsce przy nadzorowaniu procesów mechanicznych, chemicznych lub biochemicznych. Kontrolery takie są faktycznie prostymi komputerami, które wykonują pętlę programową związaną z nadzorowaniem procesów i komunikują się z pozostałą infrastrukturą za pomocą standardowych interfejsów. Człowiek zarządza takimi urządzeniami za pomocą paneli lub odpowiednich aplikacji zainstalowanych w typowym środowisku Windows. Przez całe lata uznawano, że separacja sieci jest wystarczającym zabezpieczeniem. Dzisiejsze potrzeby biznesowe związane z pozyskaniem informacji z procesów przemysłowych do analiz związanych z kosztami lub wydajnością pracy sprawiają, że nie można pozwolić sobie na pełną izolację sieci. Ponadto sieciami SCADA zainteresowali się cyberprzestępcy.
Słabe zabezpieczenia
Połączenie wielu sieci może skutkować efektem kaskadowym. Taki problem spowodował przerwę w dostawie energii do 50 milionów ludzi w USA. Przyczyną kaskadowej awarii było uszkodzenie jednego z systemów automatyki przemysłowej, co spowodowało niekompletne informacje o postępujących awariach i zmianach topologii sieci energetycznej. Stosunkowo niegroźna awaria kilku linii 345kV w północnym Ohio spowodowała kaskadowe przeciążenie innych linii 345kV i 138kV, co z kolei spowodowało awarię całej sieci energetycznej. Utracono zasilanie o mocy 61800 MW z 508 generatorów w 265 elektrowniach.
W polskim systemie zarządzania energią elektryczną zdarzenie polegające na całkowitym wyłączeniu zasilania na znacznym obszarze spowodowane przez kaskadową awarię jest mało prawdopodobne. Niemniej celowy atak przeprowadzony przeciw systemom automatyki przemysłowej może spowodować lokalne wyłączenia - przykładem mogą być wyniki ćwiczeń przeprowadzonych na jesieni 2012r. we Wrocławiu, podczas konferencji Wolność i Bezpieczeństwo. W każdym przypadku przeprowadzenie takiego ataku wymagałoby zasobów klasy militarnej.
W wielu urządzeniach, na przykład ekranach dotykowych, wykorzystuje się osadzone systemy Windows, które w odróżnieniu od korporacyjnych stacji roboczych, niemal nigdy nie są aktualizowane i nie zawierają oprogramowania antywirusowego. Podatność takich systemów wynika nie tylko z braku aktualizacji, ale także stąd, że niektóre aplikacje nie mogą być uruchomione w systemie operacyjnym, który był optymalizowany pod kątem bezpieczeństwa. Problem nie dotyczy tylko aplikacji obsługujących panele dotykowe, ale także zarządzania kontrolerami PLC lub pobieraniem danych z czujników za pomocą starszych magistrali. Komunikacja za pomocą portów szeregowych z wymaganym czasem odpowiedzi (co nadal zdarza się w starszych urządzeniach automatyki przemysłowej) wyklucza użycie o wiele bezpieczniejszych systemów Windows 7 lub Windows 8 w obecnej generacji sprzętu, gdyż ten system operacyjny nie oferuje bufora przy obsłudze portów szeregowych (RS-232, RS-422, RS-485, USB), a zatem nie gwarantuje poprawności niebuforowanej transmisji przy pomocy takiej magistrali.
Trywialne podatności
Aaron Portnoy, specjalista do spraw bezpieczeństwa współpracujący z grupą badaczy podatności Exodus Intelligence opisał na blogu grupy wyniki szybko przeprowadzonych analiz bezpieczeństwa różnych rozwiązań SCADA. Wykrył on 23 luki dnia zerowego w różnych produktach takich firm jak Rockwell Automation, Schneider Electric, Indusoft, RealFlex oraz Eaton Corporation. Wymieniane luki to przeważnie odmowa obsługi oraz możliwość zdalnego wykonania kodu, podatności te zostały zgłoszone do branżowego CERTu.
Aaron Portnoy pisze: "Pierwszą lukę znalazłem po 7 minutach od zainstalowania badanego oprogramowania. Dla kogoś, kto spędził wiele czasu na audytach oprogramowania stosowanego w biznesie i w segmencie konsumenckim, poszukiwanie błędów w systemach SCADA wydaje się czymś niesłychanie łatwym. Najtrudniejszym zadaniem było samo znalezienie oprogramowania, a nie szukanie w nim podatności. Zgłosiłem propozycję opracowania repozytorium oprogramowania SCADA, by badacze tacy jak ja mogli je łatwo znaleźć i analizować, oczywiście odnalezione w nim luki byłyby natychmiast zgłaszane".
Integracja sieci SCADA z innymi segmentami LAN sprawia, że zagrożenia mogą migrować o wiele łatwiej, niżby to miało miejsce przy całkowitej separacji. Zatem do segmentów, gdzie jest oprogramowanie SCADA, zaczęły przenikać pospolite wirusy, spotykane głównie w zwykłych sieciach domowych i biurowych. Chociaż rozwiązania SCADA nie były głównym celem ataku, również ucierpiały, gdyż korzystają z tych samych systemów operacyjnych co stacje robocze i mają te same podatności.
W styczniu 2003r. wirus SQL Slammer, atakujący serwery bazodanowe Microsoft SQL Server dostał się do wewnętrznej sieci elektrowni atomowej Davis-Besse w stanie Ohio i zaraził co najmniej jeden serwer. Skutkiem było wyłączenie systemu monitoringu bezpieczeństwa na blisko pięć godzin. Zarządzanie procesami w elektrowni zostało wyłączone na sześć godzin. Wirus przedostał się do sieci elektrowni przez łącze T1, które zostało zestawione do sieci jednej z firm trzecich poza firmowym firewallem.
W tym samym roku wirus Sobig spowodował awarię sygnalizacji kolejowej na wschodnim wybrzeżu USA. Wirus rozprzestrzeniał się za pomocą załączników poczty elektronicznej, infekował wiele firm i umożliwiał masowe wysyłanie spamu. Infekcja serwerów oraz stacji roboczych w firmie CSX w Jacksonville na Florydzie spowodowała unieruchomienie sterowanego komputerowo systemu sygnalizacji i centralnej dyspozytury. Ruch pociągów między Pittsburghiem a Florencją został zatrzymany, a regionalne pociągi Amtrak zanotowały duże opóźnienia.
Atak popularnego wiruza Zotob sparaliżował w sierpniu 2005r. 13 zakładów koncernu Daimler-Chrysler. Chociaż wirus ten atakował zwykłe sieci biurowe, unieruchomił także automatykę przemysłową, gdyż korzystała z tych samych systemów operacyjnych co biurowe stacje robocze. To samo zdarzyło się w firmach Caterpillar, Boeing oraz kilku dużych agencjach medialnych.
Atak równie popularnego Confickera sprawił, że w dwóch firmach z branży energetycznej w stanie Nevada w USA wdrożono awaryjne procedury pracy, do czasu usunięcia zagrożenia.
Sieci automatyki przemysłowej były projektowane przy założeniu, że bezpieczeństwo instalacji zostanie zapewnione za pomocą osobnych procedur, takich jak fizyczna kontrola dostępu do urządzeń aktywnych, a także brak połączenia z zewnątrz.
W tradycyjnym modelu, do takich rozwiązań wykorzystywało się osobną sieć, całkowicie oddzieloną od pozostałych segmentów. Dziś z rozwiązaniami automatyki przemysłowej integrowane są kolejne aplikacje, które wymagają zasilania danymi na bieżąco, prosto z systemów produkcyjnych. Należy także pamiętać, że wydzielona sieć nigdy nie jest całkowicie odseparowana, gdyż co jakiś czas podłącza się do niej różne urządzenia, by dokonać napraw lub diagnostyki czy aktualizacji - właśnie tą drogą przenosił się specjalizowany wirus taki jak Stuxnet czy Flame.
SCADA i systemy firmowe
W dobie potrzeb firm, które potrzebują narzędzi do analizy procesów produkcji, niezbędne stało się połączenie między siedziami PLC oraz serwerową, gdzie pracują aplikacje firmowe SCADA. Takie połączenie powoduje radykalny wzrost ryzyka naruszenia bezpieczeństwa, zatem należy niezwłocznie opracować rozwiązania, które zapewnią ochronę przed przejęciem kontroli nad kontrolerem PLC. Jest to trudne, ze względu na to, że standardowa zapora sieciowa nie ochroni kontrolera przed atakiem. Zatem dopóki producenci urządzeń PLC nie opracują nowego modelu zabezpieczenia tych urządzeń, najlepszym rozwiązaniem jest jednak minimalizacja połączeń między tymi sieciami. Bezwzględnie należy wprowadzić restrykcyjne reguły na zaporach sieciowych, ograniczając połączenia między maszynami - do kontrolerów PLC mają prawo łączyć się tylko maszyny monitorujące ich pracę, a także maszyna kontrolująca procesy. Jednocześnie należy opracować bardzo restrykcyjne założenia pracy na takim komputerze, by ryzyko zarażenia złośliwym oprogramowaniem było jak najmniejsze. W obrębie infrastruktury kontrolującej elektronicznie procesy, występuje wiele urządzeń wykorzystujących osadzone systemy Microsoft Windows - działają one na przykład w dotykowych wyświetlaczach. Założenia procedury bezpieczeństwa muszą chronić także te komputery. Producenci rozwiązań PLC pracują nad poprawą bezpieczeństwa swoich rozwiązań, ale nie należy oczekiwać radykalnej i szybkiej poprawy, gdyż proces usprawnień wymaga czasu.
Jak zaszkodzić PLC?
Urządzenia PLC przekładają komendy logiczne na fizycznie działania - otwierają i zamykają zawory, przesuwają dźwignie mechaniczne, monitorują za pomocą czujników parametry fizyczne takie jak temperatura, ciśnienie, poziom napełnienia czy stężenie określonych czynników, a następnie podejmują działania, by utrzymywać parametry procesów technologicznych w zadanych granicach. Atak przeciw PLC zakładałby sabotaż tych urządzeń w taki sposób, by te parametry przekroczyć. Skutkiem mogłaby być awaria techniczna, załamanie pracy procesu przemysłowego, wybuch, a nawet lokalna katastrofa ekologiczna, gdyby wystąpił wyciek z uszkodzonego rurociągu lub reaktora chemicznego.
Obrona przed atakiem
Niekiedy podatności ukryte są w samych kontrolerach. Urządzenia Siemens Simatic S7, badane podczas konferencji Black Hat w 2011r. okazały się podatne nie tylko na ataki na oprogramowanie sterujące, ale także na ataki ponownego odtworzenia przesyłanej informacji (replay attack), które umożliwiają napastnikom zmianę ustawień oraz wyłączenie urządzeń. Prezentacja Dillona Beresforda, badacza związanego z NSS Labs udowodniła, że luka w bezpieczeństwie tych kontrolerów jest o wiele poważniejsza, niż dotąd sądzono. Oprócz ataków odtworzenia ruchu sieciowego możliwe jest natychmiastowe przejęcie kontroli nad kontrolerem, gdyż w S7 wbudowano na stałe hasło, które uruchamiało połączenie z wierszem poleceń urządzenia. Jako ciekawostkę warto wspomnieć o wbudowanej przez producenta specjalnej opcji oprogramowania aktywowanej określonego dnia (tzw. eastern egg), wyświetlającej animację tańczących małpek. Badane urządzenia są identyczne z tymi, które atakował wirus Stuxnet w 2009, stanowiąc część cyberwojny przeciw irańskiemu programowi nuklearnemu. Obecnie producent pracuje nad poprawą bezpieczeństwa swoich rozwiązań.
Aby minimalizować ryzyko ataków po stronie elektroniki i oprogramowania, należy zastosować dodatkowe zabezpieczenia po stronie sieci. Podstawowym sposobem ochrony jest separacja sieci. Chociaż metoda ta określana jako "air gap" jest znana od początku pracy urządzeń komputerowych w przemyśle, obecnie nabiera nowego znaczenia, razem z pojawieniem się technik infekcji takich sieci przy pomocy nośników wymiennych.
Aby odseparowana sieć spełniła swoje zadanie i chroniła wrażliwe rozwiązania SCADA, należy:
- Wprowadzić żelazną zasadę stosowania osobnych urządzeń i osobnych łączy dla obu sieci. Separacja za pomocą VLAN na przełącznikach nie wystarczy, gdyż przełamanie zabezpieczeń przełącznika umożliwi uzyskanie nieautoryzowanego dostępu.
- Posiadać osobne urządzenia dla obu sieci, włącznie z osobnymi komputerami serwisowymi. Wirtualizacja i dedykowane karty sieciowe to za mało.
- Pomiędzy częścią produkcyjną a gniazdami, do których dołącza się komputery obsługiwane przez inżyniera, należy umieścić restrykcyjnie skonfigurowaną zaporę sieciową.
- Zrezygnować całkowicie z urządzeń posiadających interfejsy sieci bezprzewodowej. Jeśli jest to niezbędne, na przykład ze względu na niedostępność lub wysokie koszty dedykowanych łączy, należy użyć restrykcyjnie skonfigurowanych połączeń VPN, za którymi instaluje się zapory sieciowe. Pod pojęciem interfejsu bezprzewodowego należy rozumieć także urządzenia Bluetooth - interfejsy te należy wyłączyć sprzętowo i zabezpieczyć przed włączeniem.
- Regularnie przeprowadzać analizę ruchu w sieci, w poszukiwaniu urządzeń, które przypadkiem lub celowo mogłyby być podłączone do chronionej sieci.
- Nie wolno stosować standardowych nośników wymiennych do aktualizacji oprogramowania po stronie sieci SCADA (właśnie tę lukę wykorzystywał Stuxnet). Aby mieć pewność, że pliki aktualizacji dostarczone przez producenta są właściwe, przed użyciem należy je nagrać na płytę CD, a następnie sprawdzić skróty kryptograficzne plików już zapisanych na tym nośniku i porównać wyniki z wiarygodną listą dostarczoną przez producenta. Na płycie powinny być tylko te pliki, nic więcej, należy to sprawdzić za pomocą narzędzi innych niż powłoka systemu Windows. Każda płyta powinna być zarchiwizowana po użyciu.
- Jeśli konserwacja lub naprawa wymaga udostępnienia połączenia do instalacji wewnątrz sieci, należy zorganizować bezpieczny "punkt przesiadkowy" korzystając z mechanizmów usług terminalowych przy bardzo restrykcyjnych ustawieniach. Niekiedy informatycy stosują dodatkowo wirtualizowanie takiego serwera, udostępniając jedynie konsolę wirtualizacji Citrix czy VMware, wtedy inżynier nie ma dostępu do sieci wewnętrznej, ale może wykonać działania za pomocą narzędzi producenta rozwiązań SCADA. Całe połączenie odbywa się za pomocą osobnych kanałów VPN zestawianych do dedykowanych koncentratorów, poza siecią lokalną firmy.
- Wymiana danych między systemami przemysłowymi a serwerami pozyskiwania danych dla celów oprogramowania analitycznego musi odbywać się w jednokierunkowym kanale komunikacji. Niekiedy można zastosować wymianę danych przez łącze szeregowe przy zastosowaniu dobrze dopracowanego protokołu komunikacji, który uniemożliwia przesyłanie informacji w kierunku przeciwnym do zamierzonego.
Wyciek ścieków, wyłączenie telefonów, awaria rurociągu
Sektor energetyczny również nie był wolny od zagrożeń obejmujących sieci SCADA, przy czym niektóre z nich były spowodowane awarią oprogramowania. W elektrowni atomowej Hatch w Georgii w USA przeprowadzono awaryjne zamknięcie reaktora. Po aktualizacji oprogramowania SCADA i restarcie systemu automatyka stwierdziła brak danych i zasygnalizowała krytycznie niski poziom wody w systemach chłodzenia, co spowodowało uruchomienie procedury awaryjnego wyłączenia reaktora. Przyczyną problemów był dwukierunkowy link między sieciami biurowymi i produkcyjnymi SCADA oraz procedura synchronizacji danych. Straty sięgnęły milionów dolarów. Inżynierowie zdecydowali zatem o zamknięciu linku łączącego obie sieci.
- celowe kierowane ataki, w których napastnik uzyskał kontrolę nad komputerami w sieci automatyki, powodując ataki odmowy obsługi lub podszywania się.
- Niezamierzone konsekwencje innych ataków albo poboczne naruszenia bezpieczeństwa spowodowane atakiem wirusów lub awarii w innej części systemów firmy
- konsekwencje niezamierzonych akcji pracowników firmy, obejmując także testy oprogramowania, które nie powinno się znajdować w tej części sieci.
Pierwsza kategoria zagrożeń związana z celowymi kierowanymi atakami może powodować potencjalnie największe zniszczenia, ale są to zdarzenia najrzadsze. Celowy atak kierowany wymaga wiedzy na temat konstrukcji wewnętrznej atakowanej sieci i zazwyczaj w tym procederze obserwuje się współudział pracowników firmy.
Wbrew temu, co się powszechnie sądzi, ataki na systemy automatyki przemysłowej mają dość długą historię. W roku 2000 w Maroochy Shire Council w australijskim Queensland były pracownik firmy, która realizowała wdrożenie na potrzeby przedsiębiorstwa wodnościekowego, postanowił wywołać serię awarii, gdyż chciał uzyskać zatrudnienie za cenę usunięcia problemów, które uprzednio sam powodował. Atak ten wiązał się z uruchamianiem lub wyłączaniem pomp oraz otwieraniem i zamykaniem zaworów przy pomocy sfałszowanych komend. Skutkiem ataku było zalanie tysiącem metrów sześciennych ścieków okolicy hotelu, parku oraz pobliskiej rzeki. Intruz zrealizował aż 46 udokumentowanych ataków, zanim został schwytany.
W marcu 1997r. nastolatek z Worcester przy pomocy modemu włamał się do systemów komputerowych operatora komunikacyjnego Bell Atlantic i zablokował pewną część centrali telefonicznej obsługującej między innymi infrastrukturę lotniska (wliczając połączenia wieży kontrolnej i radiostacje, do których sygnał dostarczano liniami telefonicznymi) oraz 600 firm i domów prywatnych.
Radzieckie, a potem rosyjskie rurociągi przesyłające gaz ziemny były co najmniej dwukrotnie celem ataków. W 1982r. bomba logiczna wprowadzona do oprogramowania spowodowała eksplozję w syberyjskiej części rurociągu, z kolei w 2000r. hackerzy pozyskali kontrolę nad systemem regulacji przepływu gazu. Informacji o stratach i zniszczeniach nie opublikowano.
Najsławniejszym przypadkiem była jednak walka w cyberprzestrzeni z irańskimi instalacjami nuklearnymi za pomocą wirusa Stuxnet. Oprogramowanie to wykorzystywało cztery nieznane dotąd podatności Windows, by przeniknąć do zamkniętych sieci na nośnikach USB, a następnie poszukiwało narzędzi do programowania kontrolerów automatyki przemysłowej. Po ich odnalezieniu wybierało te kontrolery, do których podłączono silniki zasilane przez wybrane sterowniki o zmiennej częstotliwości i wprowadzało zmiany prędkości pracy silników. Spowodowane tym awarie miały skutkować opóźnieniem rozwoju irańskiego programu nuklearnego.
Dodatkowe zabezpieczenia
Rozsądny projekt kontroli procesów musi zawierać dodatkowe zabezpieczenia, które ochronią przed przekroczeniem krytycznych parametrów kontrolowanego procesu (temperatura, ciśnienie, przepływ, zakres ruchu maszyny). W wielu procesach zabezpieczenia te działają na zupełnie innej zasadzie, dzięki czemu nawet poważne uszkodzenie kontrolera nie powoduje katastrofy technicznej.
Z kolei niektórzy dostawcy (na przykład Logica) w swoich urządzeniach oferują dodatkową opcję bezpieczeństwa. Po zaprogramowaniu akcji, ich ustawienia nie mogą być już ominięte przez sieć, nawet przez komendę z panelu lub wydaną przez złośliwe oprogramowanie. Taki "programowy zawór bezpieczeństwa" można ustawić w ten sposób, by np. w przypadku wskazań termometru numer 2 przekraczających 110 stopni, otworzył zawór numer 3 bez względu na inne warunki i komendy. W nowszych terminalach takie ustawienia awaryjne są odporne nawet na upgrade treści pamięci flash przez sieć.
Wbudowanie podobnych zabezpieczeń umożliwia minimalizowanie skutków awarii, niezależnie od jej przyczyny, ale może powodować podatność na ataki odmowy obsługi. Może się także wiązać z bardzo dużymi stratami spowodowanymi zadziałaniem takiego zabezpieczenia i na przykład awaryjnym zatrzymaniem procesu.
