Cyberbezpieczeństwo urządzeń IoT oraz IIoT

| Technika

Przemysłowy Internet Rzeczy, podobnie jak tradycyjny, wymaga stosowania zabezpieczeń przed cyberatakami. Przez długi czas bezpieczeństwo nie należało jednak do priorytetów konstruktorów urządzeń IoT. Nieraz zakładano, że nikt nie będzie się chciał włamywać do inteligentnej pralki czy smart TV. Jak się jednak okazało, IoT zaczął się upowszechniać w takim tempie i w tak wielu zastosowaniach, że potencjał cyberataków wymierzonych w urządzenia Internetu Rzeczy, liczone już w miliardach sztuk na całym świecie, coraz częściej z dostępem do krytycznej infrastruktury, sieci domowych, firmowych i w zakładach przemysłowych, dostrzegli również hakerzy. W artykule przedstawiamy przegląd zagrożeń oraz zabezpieczeń w związku z tym sugerowanych do zaimplementowania w urządzeniach IoT / IIoT.

Cyberbezpieczeństwo urządzeń IoT oraz IIoT

Cyberataki na węzły sieci Internetu Rzeczy mają na celu włamanie się do samego urządzenia lub są wykorzystywane do uzyskania za jego pośrednictwem dostępu do sieci i systemów, do których jest ono podłączone. Pierwszym krokiem na drodze do zapewnienia lepszej ochrony urządzeń IoT, a dzięki temu i pozostałych zasobów przedsiębiorstwa, jest zrozumienie tego, jakie możliwości w tym zakresie mają atakujący. Są one niestety szerokie – cyberprzestępcy mogą wykorzystywać luki w oprogramowaniu urządzenia IoT, w jego systemie operacyjnym, a w sprzyjających im okolicznościach również te na poziomie sprzętowym.

Wstrzykiwanie kodu

Przykładem zagrożeniem są ataki wykorzystujące luki w parserach oraz interpreterach. Jedną z groźniejszych furtek w aplikacjach internetowych, a szczególnie w systemach IoT, jest tzw. wstrzykiwanie, pozwalające cyberprzestępcy na uruchomienie na atakowanym urządzeniu szkodliwego kodu. Przykładem jest wstrzykiwanie poleceń SQL – w ten sposób można przeprowadzić atak na bazę danych przez wstawienie swoich parametrów do zapytania SQL-owego lub zignorowanie istniejącego zapytania i wykonanie własnego. Poza tym wstrzykiwane są polecenia systemu operacyjnego. Przykładem luki na to pozwalającej jest Bash Bug, inaczej Shellshock. Jest to błąd w powłoce systemowej bash, która jest jednym z podstawowych narzędzi w systemach operacyjnych z rodziny Linux. Luka Shellshock pozwala na zdalne uruchamianie złośliwego kodu, umożliwiając nie tylko szpiegowanie, lecz nawet przejęcie całkowitej kontroli nad docelowym urządzeniem. Atak tego typu jest łatwy do wykonania i potencjalnie bardzo szkodliwy ze względu na wciąż rosnącą liczbę urządzeń z systemami wbudowanymi opartymi na systemie Linux oraz łatwość, z jaką te podatne na atak urządzenia IoT można wykryć w Internecie.

Czym było mirai?

To ostatnie jest łatwiejsze, dzięki takim narzędziom jak na przykład Shodan. Jest to wyszukiwarka urządzeń podłączonych do Internetu z filtrem wyników w zależności od podanych kryteriów. Z założenia Shodan i jej podobne publicznie dostępne narzędzia są dedykowane specjalistom od cyberbezpieczeństwa oraz testerom zabezpieczeń. Z analogicznych jednak korzystają oczywiście także cyberprzestępcy. Takie skanery w połączeniu z innym problemem, który od zawsze był zmorą specjalistów od cyberbezpieczeństwa – chodzi o niezmienianie przez użytkowników domyślnych danych uwierzytelniających, stanowią ogromne zagrożenie dla bezpieczeństwa urządzeń Internetu Rzeczy. To niestety zostało już przez hakerów potwierdzone – na masową skalę po raz pierwszy ten tandem został wykorzystany kilka lat temu.

Chodzi tu o słynny cyberatak, a właściwie o całą ich serię, który został przeprowadzony za pomocą malware’u o nazwie Mirai. Program ten wykorzystywał niezabezpieczone urządzenia Internetu Rzeczy w prosty, ale sprytny sposób, skanując sieć w poszukiwaniu otwartych portów za pośrednictwem telnetu, a następnie próbując zalogować się do znalezionych urządzeń za pomocą domyślnych danych uwierzytelniających.

Malware pod tym kątem do skutku sprawdzał kilkadziesiąt par login–hasło, które są najczęściej ustawiane fabrycznie w urządzeniach takich jak smart TV, routery, kamery IP, i zwykle nie są zmieniane przez użytkowników. Po zalogowaniu się Mirai infekowało zaatakowane urządzenie, które stawało się botem, zdalnie kontrolowanym przez to malware. W ten sposób udało się zgromadzić ich ogromną liczbę, tworząc botnet. Ten zaś został wykorzystany w serii ataków typu Distributed Denial of Service (DDoS), które polegają na zasypywaniu atakowanych serwerów jednocześnie wielką liczbą fałszywych żądań dostępu do ich usług. To zajmuje ich zasoby aż do ich przeciążenia i wyłączenia. W ten sposób przez Mirai zaatakowanych zostało wiele firm i instytucji na całym świecie.

Luki w protokołach komunikacyjnych

Słabym punktem są też niezabezpieczone sieci i "furtki" w protokołach komunikacyjnych. Przykład ostatniej to luka odkryta jakiś czas temu w protokole ZigBee. Dzięki niej możliwy stał się atak na sieć komputerową w domu albo firmie z wykorzystaniem sieci IoT składającej się z inteligentnych żarówek i ich mostku sterującego, nad którymi atakujący wcześniej przejął kontrolę. Udowodniły to udane eksperymenty przeprowadzone przez specjalistów z dziedziny cyberbezpieczeństwa, którzy najpierw włamali się do smart żarówki i zainfekowali ją złośliwym oprogramowaniem. Następnie, przejmując nad nią kontrolę, w dokuczliwy sposób zmieniali kolor oraz jasność światła. To miało sugerować użytkownikowi, że żarówka się zepsuła. Po sprawdzeniu jej statusu w aplikacji sterującej mógł on się przekonać, że jest ona "poza zasięgiem". To z kolei wymuszało reset, który polega na usunięciu danej żarówki z sieci i jej ponownym wyszukaniu przez mostek. Po dodaniu zainfekowane urządzenie, wykorzystując lukę w zabezpieczeniach protokołu ZigBee, wysyłało duże ilości danych do mostka, żeby go zablokować, jednocześnie instalując na nim złośliwe oprogramowanie. To umożliwiło dalsze rozsyłanie malware’u po sieci domowej albo firmowej, do której podłączony był mostek kontrolny żarówek IoT.

Inny przykład to odkryte jakiś czas temu luki w zabezpieczeniach sieci Bluetooth, które omijały mechanizmy uwierzytelniania, pozwalając na przejęcie kontroli nad urządzeniem. Oprócz tego umożliwiały rozprzestrzenianie złośliwego oprogramowania i przeprowadzenie ataku typu man in the middle. Biorąc pod uwagę to, że wiele urządzeń łączy się z Bluetooth automatycznie oraz domyślnie ma ten interfejs włączony, łatwo sobie wyobrazić skalę, na jaką można przeprowadzić atak, wykorzystując tę furtkę w zainfekowanym urządzeniu IoT.

Klasyfikacja luk w zabezpieczeniach

Zasadniczo zatem większość słabych punktów w urządzeniach wbudowanych, które mogą zostać wykorzystane przez osoby ze złymi zamiarami, można zaliczyć do jednej z trzech kategorii: niedociągnięcia w implementacji, niedopatrzenia we wdrażaniu lub użytkowaniu i błędy w projekcie. Pierwsze są to błędy w kodzie programu, które atakujący może wykorzystać do swoich celów podczas cyberataku. Sztandarowym przykładem takiego jest przepełnienie bufora. Skutkiem tego błędu jest zapisywanie nadmiarowych informacji do sąsiednich komórek pamięci, co prowadzi do nadpisania ich zawartości. Rezultatem jest błędne działanie programu, zaś w najgorszym razie, jeżeli nadmiarowe dane są dostarczane przez cyberprzestępcę, może pozwolić na zmiennie tych prawidłowych na złośliwe, zgodnie z jego wolą, aby na przykład włamać się, szpiegować albo przejąć kontrolę nad danym urządzeniem.

Do tej kategorii zalicza się również inicjowanie generatorów liczb pseudolosowych ziarnem, które nie jest odpowiednio dobrane. To może skutkować generowaniem łatwych do odgadnięcia kluczy bezpieczeństwa. Na szczęście błędów tego rodzaju łatwo można uniknąć, stosując się do dobrych praktyk w zakresie tworzenia oprogramowania – w tym zakresie obowiązują liczne standardy branżowe (na przykład publikowane przez OWASP, Open Web Application Security Project). Błędy, które mimo to wkradną się do kodu pozwala z kolei wyeliminować jego testowanie.

Błędy użytkownika, odpowiedzialność projektanta

Do powstawania luk bezpieczeństwa zaliczanych do drugiej kategorii przyczynia się użytkownik na etapie konfiguracji i obsługując urządzenie. Poza opisanym wyżej niezmienianiem domyślnych danych uwierzytelniających, wymienić tu można ustawianie łatwych do odgadnięcia haseł, jak też niewłączanie zalecanych zabezpieczeń.

Pozornie może się wydawać, że winić za te niedociągnięcia należy użytkownika. W rzeczywistości powinna to być jednak odpowiedzialność projektanta, żeby osoby korzystające z urządzeń IoT nie miały możliwości wpływania na poziom ich bezpieczeństwa.

Luki trzeciego rodzaju wynikają z niewdrożenia odpowiednich zabezpieczeń podczas projektowania urządzenia. Do tej grupy zalicza się m.in.: hasła zakodowane "na sztywno", czyli podane w postaci tekstowej w kodzie źródłowym programu, brak uwierzytelniania użytkownika, korzystanie z protokołów komunikacyjnych, które przesyłają hasła i inne poufne informacje w sposób jawny, niezaimplementowanie secure boot (bezpiecznego rozruchu), dopuszczenie zdalnej aktualizacji firmware’u bez uwierzytelnienia jego źródła.

"Must have" zabezpieczeń w urządzeniach IoT

Standardy w dziedzinie zabezpieczeń urządzeń Internetu Rzeczy dopiero się kształtują. W tym zakresie działa wiele organizacji, które opracowują i publikują stosowane zalecenia. Są to m.in.: w Stanach Zjednoczonych – National Institute of Standards and Technology (NIST), w Europie European Telecommunications Standards Institute (ETSI), jak też European Union Agency for Cybersecurity (ENISA) i Global System for Mobile Communications (GSMA). Ich wytyczne dotyczą różnych aspektów bezpieczeństwa urządzeń IoT, generalnie jednak dobre praktyki wymagają, żeby zaimplementować kilka standardowych funkcjonalności.

Taką jest możliwość jednoznacznej identyfikacji, fizycznej oraz logicznej. Unikalny identyfikator logiczny jest wymagany, by odróżnić urządzenie zazwyczaj w celu automatyzacji zarządzania i monitorowania węzłów sieci Internetu Rzeczy. Fizyczny może natomiast służyć do odróżnienia urządzenia od innych wtedy, gdy unikalny identyfikator logiczny jest jeszcze albo już niedostępny, na przykład podczas instalacji albo wycofywania urządzenia IoT z użytku albo w razie jego awarii.

Bezpieczna konfiguracja i aktualizacje

Zmiany w konfiguracji oprogramowania urządzenia, które mogą się okazać konieczne ze względów cyberbezpieczeństwa, powinny wymagać uwierzytelniania. Pomocna jest oprócz tego możliwość przywrócenia tej domyślnej (bezpiecznej), na wypadek, jeżeli nowa jest błędna lub istnieją podejrzenia co do pochodzenia ustawień. Urządzenie IoT powinno także chronić dane, które przechowuje i transmituje przed nieautoryzowanym dostępem i modyfikacją. Musi ponadto ograniczać logiczny dostęp do swoich interfejsów lokalnych i sieciowych oraz protokołów i usług wykorzystywanych przez te interfejsy tylko do autoryzowanych podmiotów.

Oprócz tego oprogramowanie urządzenia IoT musi być aktualizowane, m.in. żeby usunąć luki w zabezpieczeniach, tylko po uwierzytelnieniu i wyłącznie za pomocą bezpiecznego i konfigurowalnego mechanizmu. Urządzenie IoT powinno także raportować o swoim stanie, informując o próbach naruszenia cyberbezpieczeństwa i udostępniać te informacje tylko uprawnionym podmiotom.

Jak to osiągnąć?

Projektanci i programiści urządzeń Internetu Rzeczy próbują sprostać tym zaleceniom na różne sposoby. Wśród tych praktykowanych są m.in.: wspomniany bezpieczny rozruch, w oparciu o kryptograficznie podpisany kod od producenta w połączeniu ze wsparciem sprzętowym w celu zweryfikowania uwierzytelnienia kodu, co gwarantuje, że firmware nie zostało w nieuprawniony sposób zmodyfikowane albo zamienione, bezpieczne aktualizacje, dzięki weryfikowaniu podpisu cyfrowego dostawcy oprogramowania, szyfrowanie przechowywanych danych i/lub ich transmisja w postaci zaszyfrowanej, korzystanie z dedykowanych protokołów uwierzytelniania i autoryzacji, szyfrowanie transmisji z/do urządzenia, wbudowany firewall, zapewnienie możliwości logicznej dezaktywacji lub fizycznego wyłączenia wszelkich interfejsów lokalnych i sieciowych, które nie są niezbędne do podstawowej funkcjonalności urządzenia i wykrywanie fizycznej ingerencji w urządzenie, na przykład przez naruszenie plomby na obudowie.

Podsumowanie

Specyfika urządzeń Internetu Rzeczy nie ułatwia zadania specjalistom od cyberbezpieczeństwa. Przede wszystkim różnią się pod względem fizycznym – niektóre mają niewielkie rozmiary i te zazwyczaj są zoptymalizowane pod kątem oszczędności energii (jak elektronika noszona, a w przemyśle – czujniki), ponieważ muszą pracować latami na zasilaniu bateryjnym. Inne nie są natomiast projektowane pod kątem kompaktowości ani energooszczędności. Różnorodność ta przekłada się na różnice w dostępnych w nich zasobach pamięci oraz mocy obliczeniowej.

Poza tym na ich konstruktorach spoczywa duża odpowiedzialność w związku z tym, że urządzenia IoT są produkowane i instalowane na masową skalę – w razie wykrycia przez cyberprzestępców luki udany atak na jedno z tych urządzeń może zostać zreplikowany na wszystkie tego typu urządzenia. To w tym przypadku oznacza nie tysiące, a miliony, a nawet miliardy sztuk.

Z pewnością jednak sytuacja (rosnąca liczba węzłów IoT, poszerzający się zakres aplikacji Internetu Rzeczy i niestety pomysłowość hakerów) z czasem przyczynią się do rozwiązania najbardziej palących problemów, opracowania konkretnych rozwiązań i upowszechnienia się dobrych praktyk w zakresie cyberbezpieczeństwa urządzeń IoT.

 

Monika Jaworowska