Internet Of Things: IoT Security - Rozdział 5

1. Urządzenia IoT mają wiele różnych typów oprogramowania, takich jak firmware, systemy operacyjne i aplikacje. Każde podłączone urządzenie jest urządzeniem podatnym na ataki. Zainstalowane aplikacje mogą mieć wiele różnych typów podatności. Sprawcy zagrożeń szukają podatności, aby uzyskać dostęp. Niektóre z najczęściej wystawionych na ataki podatności:
  • "Username enumeration" - sprawca zagrożenia jest w stanie znaleźć prawidłowe nazwy użytkowników, interaktywnie działając z mechanizmem uwierzytelniania aplikacji. 
  • Słabe hasła - sprawca zagrożenia korzysta z domyślnych haseł, które nie zostały zmienione, lub ustawia hasła kont, które wybiera. 
  • Blokada konta - sprawca zagrożenia próbuje się uwierzytelnić, co powoduje zablokowanie konta po wielokrotnych nieudanych próbach. 
  • Brak wieloskładnikowego uwierzytelniania - dla sprawcy zagrożenia łatwiej jest uzyskać dostęp, gdy wymagana jest tylko jedna forma uwierzytelniania. 
  • Niebezpieczne komponenty stron trzecich - gdy odkryte zostaną podatności, wymagane będzie zainstalowanie łatek. Gdy komponenty takie jak Secure Shell (ssh), BusyBox lub serwery internetowe nie są aktualizowane, sprawca zagrożenia może wykorzystać te podatności i uzyskać dostęp.
2. Najpopularniejsze lokalne exploity:
  • Zastąpienie firmware’u - Aktualizacje i łatki do urządzeń zazwyczaj są wykonywane zdalnie. Jeśli proces nie jest bezpieczny, sprawca zagrożenia może przechwycić aktualizację i zainstalować swoją własną szkodliwą aktualizację. Mogłoby to pozwolić mu na pełną kontrolę nad urządzeniem i rozpoczęcie atakowania innych urządzeń w systemie. 
  • Klonowanie - Tworząc fizyczny duplikat urządzenia, uruchamiając podobne oprogramowanie i firmware, sprawca zagrożenia mógłby zastąpić prawdziwe urządzenie. Gdy urządzenie jest już uruchomione i działa, sprawca zagrożenia mógłby następnie kraść informacje lub kompromitować dodatkowe urządzenia. 
  • Odmowa usługi (DoS) - Sprawca zagrożenia mógłby przeprowadzić atak DoS, aby zapełnić kanał komunikacyjny, powodując opóźnienia w odpowiedzi urządzeń na żądania, lub brak odpowiedzi w ogóle. W zależności od urządzeń, mogłoby to spowodować wiele szkód. 
  • Wyodrębnianie parametrów bezpieczeństwa - Gdy urządzenie nie jest odpowiednio chronione, sprawca zagrożenia może być w stanie wyodrębnić z niego parametry bezpieczeństwa, takie jak informacje uwierzytelniające lub klucze bezpieczeństwa. 
3. Najpopularniejsze zdalne exploity:
  • Atak typu Man-In-the-Middle (MITM) - Sprawca zagrożenia dostaje się pomiędzy urządzenia w systemie i przechwytuje wszystkie dane, które są transmitowane. Te informacje mogą być po prostu zbierane lub modyfikowane w określonym celu i dostarczane do ich pierwotnego miejsca przeznaczenia. 
  • Atak podsłuchowy - Gdy urządzenia są instalowane, sprawca zagrożenia może przechwycić dane, takie jak klucze bezpieczeństwa, które są używane przez ograniczone urządzenia do nawiązywania komunikacji po ich uruchomieniu i rozpoczęciu działania. 
  • Wstrzykiwanie SQL (SQLi) - Sprawca zagrożenia wykorzystuje błąd w aplikacji Structured Query Language (SQL). Pozwala to na kradzież danych lub ich fałszowanie, nieautoryzowany dostęp do systemu plików i inne naruszenia bezpieczeństwa.
  • Atak na routing - Sprawca zagrożenia mógłby umieścić w sieci fałszywe urządzenie do routingu lub modyfikować pakiety routingu, aby manipulować routerami, aby wysyłały wszystkie pakiety do wybranego przez sprawcę zagrożenia miejsca przeznaczenia. Następnie mógłby odrzucać konkretne pakiety, znane jako selektywne przekazywanie, lub odrzucać wszystkie pakiety, co jest znane jako atak sinkhole.
4. Najczęstsze przyczyny uzyskania możliwości uzyskania dostępu i kontroli nad urządzeniami mobilnymi:
  • Niebezpieczna komunikacja - Technologia komunikacji i kanał muszą być zabezpieczone. Gdy występuje słaba negocjacja, złe praktyki nawiązywania połączenia, lub używanie nieprawidłowych wersji SSL, komunikacja nie jest bezpieczna. 
  • Niebezpieczne przechowywanie danych - Wiele aplikacji ma dostęp do obszarów przechowywania danych urządzeń mobilnych, nawet jeśli mogą tego nie potrzebować. Przechowywanie danych musi być zabezpieczone, a aplikacje muszą być testowane, aby upewnić się, że nie dochodzi do wycieku danych. 
  • Niebezpieczne uwierzytelnianie - Sesje muszą być odpowiednio zarządzane, aby zapewnić bezpieczne uwierzytelnianie. Użytkownicy muszą być identyfikowani w razie potrzeby, a ich tożsamość musi być utrzymywana w bezpieczny sposób.
  • Niewłaściwe korzystanie z platformy - Aplikacje mobilne korzystają z funkcji wbudowanych w platformy, takich jak TouchID, Keychain i Android intents. Jeśli te mechanizmy bezpieczeństwa zostaną niewłaściwie wykorzystane, dostęp do urządzenia i innych aplikacji może być naruszony.
  • Niewystarczające szyfrowanie - Szyfrowanie używane do szyfrowania wrażliwych danych musi być wystarczające i musi być stosowane w razie potrzeby.
5.  Najczęstsze podatności aplikacji internetowych i chmurowych:
  • Iniekcja - Iniekcja polega na tym, że sprawca zagrożenia wysyła polecenie wraz z innymi danymi do interpretera. Często jest to wykonywane na SQL, NoSQL (czasami nazywanym “nie tylko SQL”), Lightweight Directory Access Protocol (LDAP) i systemie operacyjnym. Dodatkowe dane wysłane przez sprawcę zagrożenia mogą zmylić interpretera, co skutkuje wykonaniem poleceń i dostępem do danych bez autoryzacji. Atak iniekcji będzie działał tylko na aplikacji, która jest podatna na atak. 
  • Zewnętrzne jednostki XML (XXE) - Nieprawidłowo skonfigurowane lub stare procesory XML ocenią zewnętrzne odniesienia do jednostek, które znajdują się w dokumentach eXtensible Markup Language (XML). Korzystanie z tych zewnętrznych jednostek może ujawnić pliki i udostępnione pliki, przeprowadzić skanowanie portów i wykonanie kodu, a nawet uruchomić atak DoS. 
  • Ekspozycja wrażliwych danych - Często interfejsy programowania aplikacji (API) i aplikacje internetowe nie chronią poprawnie danych. Mogą nie szyfrować danych lub nieprawidłowo je wymieniać z przeglądarkami. Sprawca zagrożenia może wykorzystać te dane do kradzieży tożsamości i popełnienia oszustwa. 
  • Złamana kontrola dostępu - Jeśli dostęp nie jest prawidłowo skonfigurowany, sprawca zagrożenia może być w stanie uzyskać dostęp do nieautoryzowanych danych. Przy wystarczająco wysokich uprawnieniach mogą być w stanie modyfikować prawa dostępu dla siebie lub innych. 
  • Złamane uwierzytelnianie - Zarządzanie sesją i uwierzytelnianie mogą być nieprawidłowo zaimplementowane. Pozwala to sprawcy zagrożenia na odkrycie kluczy i haseł lub na podszywanie się pod innych użytkowników.
6. Aplikacje IoT w chmurze są szeroko rozproszone i mogą przetwarzać dane na różnych poziomach sieci. Przetwarzanie danych może odbywać się na bramkach, czujnikach, siłownikach lub w chmurze. Aplikacje do obliczeń w chmurze mogą przeprowadzać skomplikowane obliczenia na dużych ilościach danych z czujników, co pozwala na przeprowadzanie konkretnych działań, ostrzeganie ludzi lub aktualizowanie bazy danych. Te obliczenia mogą być wykorzystywane do analizy poznawczej i predykcyjnej oraz do dostosowywania warunków w czasie rzeczywistym. Wszystkie te działania muszą być przeprowadzane w bezpiecznym środowisku.

7. Aby zapewnić bezpieczeństwo aplikacji chmurowych i interfejsów internetowych opartych na chmurze, należy przestrzegać następujących wytycznych:
  • Przeglądaj wszystkie aplikacje internetowe i chmurowe pod kątem podatności na zagrożenia bezpieczeństwa, w tym interfejsy internetowe i interfejsy API.
  • Wyraźnie zapobiegaj używaniu słabych haseł.
  • Wprowadź mechanizmy blokady konta, aby zapobiec atakom metodą brutalnej siły.
  • Korzystaj z uwierzytelniania dwuskładnikowego, ilekroć jest to możliwe.
  • Zawsze korzystaj z szyfrowania transmisji, takiego jak SSH i Secure Socket Layer 3.0 (SSL). SSL 3.0 jest również znany jako Transport Layer Security (TLS).
  • Dokładnie testuj pod kątem podatności na SQLi, cross-site Scripting (XSS) i cross-site Request Forgery (CSRF).
  • Ustaw hasła do wygaśnięcia po określonym czasie.
  • Zmuszaj użytkowników do zmiany domyślnej nazwy użytkownika i hasła, ilekroć jest to możliwe.
8. Aby zapewnić bezpieczeństwo aplikacji w chmurze i interfejsów internetowych opartych na chmurze, postępuj zgodnie z poniższymi wytycznymi:
  • Przeglądaj wszystkie aplikacje internetowe i w chmurze pod kątem luk bezpieczeństwa, w tym interfejsów internetowych i interfejsów API. 
  • Wyraźnie zapobiegaj używaniu słabych haseł. 
  • Wdrażaj mechanizmy blokowania kont, aby zapobiec atakom metodą brutalnej siły. Używaj dwuskładnikowego uwierzytelniania, ilekroć to możliwe. 
  • Zawsze używaj szyfrowania transportowego, takiego jak SSH i Secure Socket Layer 3.0 (SSL). SSL 3.0 jest również znany jako Transport Layer Security (TLS). 
  • Dokładnie testuj podatności na SQLi, cross-site Scripting (XSS) i cross-site Request Forgery (CSRF).
  • Ustaw hasła do wygaśnięcia po określonym czasie. 
  • Zmuszaj użytkowników do zmiany domyślnej nazwy użytkownika i hasła, ilekroć to możliwe.
9. Najczęstsze podatności interfejsu internetowego to:

Cross-site Scripting (XSS) - W ataku XSS, twórca zagrożenia wstrzykuje kod, najczęściej JavaScript, do wyjścia aplikacji internetowej. To zmusza skrypty po stronie klienta do działania w sposób, w jaki chce, aby działały w przeglądarce. Przykładowo złoczyńca mógłby wykonywać skrypty w przeglądarce użytkownika, aby przekierować ruch do złośliwych stron internetowych, lub porwać sesję użytkownika, kradnąc ciasteczka,. Skrypt ten może być wykonywany za każdym razem, gdy wykonuje się pewne zdarzenie, takie jak najechanie myszą (onmouseover), lub za każdym razem, gdy strona jest ładowana. Podatne aplikacje internetowe są celem ataków XSS, a nie użytkownik.

SQL Injection (SQLi) - atakuje samą bazę danych SQL. Gdy podatność jest wykorzystywana, autor zagrożenia może kontrolować bazę danych aplikacji. Może on zbierać, zmieniać lub usuwać dane, a nawet zmieniać sposób, w jaki baza danych korzysta z danych. Jeśli można znaleźć dane uwierzytelniające roota, aktor zagrożenia może przejąć pełną kontrolę nad bazą danych i programować jej zachowanie. Podobnie jak w przypadku XSS, SQLi polega na tym, że autor zagrożenia wstrzykuje kod do pól wprowadzania tekstu, które będą używane do zapytań do bazy danych SQL. Zamiast używać JavaScript, używane są złośliwe polecenia SQL, aby oszukać bazę danych i zwrócić nieautoryzowane rekordy i inne dane. Powodem, dla którego SQLi tak często działa, jest to, że aplikacja nie oczyszcza niezaufanych danych wprowadzanych w pola strony internetowej. Wiele organizacji jest podatnych, ponieważ ich kod nie oczyszcza prawidłowo zapytań.

Uszkodzona autentykacja obejmuje zarówno zarządzanie sesją, jak i ochronę tożsamości użytkownika. Aktor zagrożenia może porwać sesję, aby przyjąć tożsamość użytkownika, zwłaszcza gdy tokeny sesji pozostają niewygasłe. Autor zagrożenia może uzyskać dostęp do nazw użytkowników i haseł za pomocą ataków brutalnej siły, ataków słownikowych i list domyślnych danych uwierzytelniających, gdy dane uwierzytelniające nie są chronione.

10. Urządzenia IoT używają protokołów komunikacyjnych, aby uzgodnić, w jaki sposób będą się komunikować. Protokół komunikacyjny definiuje funkcje i zasady przesyłania wiadomości między urządzeniami.

Protokół Hypertext Transfer Protocol (HTTP) wraz z API Representational State Transfer (REST) są często używane do komunikacji aplikacji internetowych. Jednak wiadomości HTTP mają duże obciążenie. Powoduje to, że HTTP jest niewydajny dla urządzeń IoT z następujących powodów:
  • Urządzenia IoT mają ograniczone zasoby i mogą nie mieć możliwości instalowania usług HTTP.
  • HTTP to niewydajny protokół komunikacyjny, który zużywa więcej zasobów.
  • HTTP nie zawiera niezawodnego modelu publikacji i subskrypcji.
  • HTTP nie ma mechanizmu do zachowywania lub zapisywania wiadomości.
  • HTTP nie ma metody informowania użytkowników, że urządzenie nie jest już dostępne.
11. Podstawową zasadą działania protokołu HTTP jest model żądanie-odpowiedź. Klient (np. przeglądarka internetowa) wysyła żądanie do serwera, a serwer odpowiada na to żądanie, przesyłając odpowiedź z żądanymi danymi. Proces komunikacji pomiędzy klientem a serwerem opiera się na wymianie wiadomości tekstowych.

12. W IoT stosuje się wiele różnych protokołów komunikacyjnych. Najbardziej powszechne protokoły warstwy aplikacji IoT używanych obecnie to:
  • MQTT – Message Queueing Telemetry Transport używa protokołu Transport Control Protocol (TCP) i wymaga brokera wiadomości.
  • CoAP – Constrained Application Protocol to protokół przesyłania dokumentów, który używa protokołu User Datagram Protocol (UDP).
  • XMPP – Extensible Messaging and Presence Protocol używa TCP i został pierwotnie zaprojektowany do komunikacji natychmiastowej.
  • DDS – Data Distribution Service używa TCP i jest zaprojektowany do łączenia urządzeń z innymi urządzeniami.
  • AMQP – Advanced Message Queuing Protocol używa TCP i jest zaprojektowany do łączenia serwerów ze sobą.
13. MQTT używa modelu klient-serwer zwany publikuj-subskrybuj. Klienci łączą się z serwerem zwanym brokerem. Zazwyczaj klient albo publikuje temat, albo subskrybuje temat. Tematem jest dowolny konkretny typ wiadomości, jak wilgotność, temperatura, czy światło. Broker zarządza wszystkimi komunikatami między wydawcami a subskrybentami. 
MQTT jest zaprojektowany do zbierania danych z wielu urządzeń i dostarczania ich do infrastruktury IT. Jest używany, gdy istnieje potrzeba monitorowania wielu małych urządzeń i udostępniania ich danych w chmurze, aby wywoływać decyzje M2M. 
Model publikuj-subskrybuj działa dobrze w IoT z dwóch ważnych powodów. Po pierwsze, klienci, którzy nie są podłączeni, nie uniemożliwią działania całego systemu. Wynika to z faktu, że klienci są niezależni od siebie. Ponadto, ponieważ ten model minimalizuje ruch, pomaga to zmniejszyć ilość energii zużywanej przez urządzenia IoT podczas komunikacji.

14. CoAP to lekki protokół zaprojektowany do komunikacji M2M. CoAP używa UDP zamiast TCP, co skutkuje znacznie mniejszymi pakietami niż w MQTT. CoAP nie wymaga scentralizowanego urządzenia w roli brokera, jak to jest w MQTT; czujniki i inne węzły mogą łączyć się ze sobą i publikować do siebie nawzajem. CoAP obsługuje również transmisje multicastowe, co sprawia, że odkrywanie zasobów i aktualizacje są bardziej efektywne.

CoAP używa modelu klient-serwer, w którym klienci wysyłają żądania do serwerów, a serwery odpowiadają klientom. CoAP został zaprojektowany do współpracy z HTTP. CoAP obsługuje cztery metody HTTP: GET, POST, PUT i DELETE. Ponadto, CoAP ma możliwość obserwowania zasobu. Gdy żądanie GET CoAP ma ustawioną flagę obserwacji, serwer może odpowiedzieć klientowi nawet po zakończeniu transferu. Pozwala to klientowi informować serwery o zmianach stanu, gdy one występują, co jest kluczowe dla wielu urządzeń IoT.

15. MQTT to protokół IoT, ale nie jest bezpieczny. Eksponuje wrażliwe dane, co może prowadzić do kompromitacji urządzeń. Bezpieczeństwo MQTT musi być oparte na możliwościach brokera i klientów. Uwierzytelnianie klienta to dobry początek, ale gdy potrzebne jest wysokie bezpieczeństwo, komunikacja musi być zabezpieczona. MQTT oferuje dwa sposoby ochrony wiadomości: szyfrowanie TLS i szyfrowanie ładunku.

Podobnie jak MQTT, CoAP to lekki protokół dla M2M. CoAP używa UDP zamiast TCP, co skutkuje mniejszymi pakietami. CoAP nie wymaga brokera, a węzły mogą publikować do siebie nawzajem. Wybór implementacji MQTT lub CoAP zależy od aplikacji. MQTT jest używany głównie tam, gdzie dane na żywo są jedynymi danymi. CoAP jest powszechnie używany, gdy stan urządzenia IoT ulega zmianie i ta zmiana musi być zgłoszona.

16. Szyfrowanie TLS – Jest to ta sama technologia, która jest używana do zabezpieczania HTTP. TLS tworzy zaszyfrowane połączenie między węzłami, przez które są wysyłane wiadomości. TLS może być problematyczny do implementacji, jeśli ograniczone urządzenia nie mają wystarczającej mocy procesora i pamięci do jego użycia. 
Szyfrowanie payloadów – Wykonywane na warstwie aplikacji, szyfrowanie ładunku zapewnia szyfrowanie od końca do końca, chroniąc wiadomość nawet przed brokerem. Szyfrowanie to nie chroni żadnych haseł, które mogą być używane na połączeniu.

17. Podobnie jak MQTT, CoAP to protokół IoT, ale nie jest bezpieczny. CoAP używa UDP, więc nie może używać TLS, zamiast tego używa DTLS. DTLS przypomina TLS, co pozwala na ponowne użycie kodu i infrastruktury. DTLS może być najlepszym protokołem zabezpieczeń dla urządzeń IoT, ponieważ chroni dane, zapewnia wymianę kluczy i wykonuje uwierzytelnianie. CoAP i MQTT są wybierane w zależności od aplikacji.

18. Aby zapobiec atakom SQL injection, dane muszą być oddzielone od poleceń i zapytań, które są używane. Najlepszym sposobem na to jest użycie bezpiecznego API. Bezpieczne API dostarcza interfejs z parametrami lub w ogóle nie korzysta z interpretera. Parametryzowanie zapytań określa symbole zastępcze, które wskazują bazie danych, że są danymi, a nie częścią polecenia. Narzędzia mapowania obiektowo-relacyjnego (ORM) mogą być również używane do tworzenia wirtualnej bazy danych obiektów, używając języka zorientowanego obiektowo do konwersji danych między systemami, które nie są kompatybilne.

Na serwerze można również zaimplementować białą listę do walidacji danych wejściowych. Nie zawsze jest to skuteczne, gdy aplikacja wymaga specjalnych znaków lub specjalnych API. W systemach starszych, specjalne znaki mogą być uciekane za pomocą składni ucieczki dla konkretnego interpretera, który jest używany. Warto używać również LIMIT i innych kontroli w zapytaniach. Zapobiegnie to masowemu ujawnieniu rekordów.

19, Atak eXternal Entity injection (XXE) stał się bardzo popularną formą ataku. Bardzo ważne jest szkolenie programistów, aby byli w stanie zidentyfikować i zminimalizować ataki XXE. Według OWASP, najbezpieczniejszym sposobem na zapobieganie temu jest wyłączenie przetwarzania zewnętrznych jednostek XML i DTD w aplikacji. Aby zapobiegrać XXE należy:
  • używać mniej skomplikowanych formatów danych tj. JSON
  • aktualizowanie biblioteki XML
  • używanie białej listy po stronie serwera podczas walidacji danych wejściowych
  • wykrywanie XXE w kodzie źródłowym za pomocą narzędzi SAST