TABLE OF CONTENTS:
Autor: Krzysztof Labuda, konsultant ds. testów bezpieczeństwa
IoT stało się na tyle obszernym fragmentem świata IT, że nie mogło zabraknąć porad i wskazówek dotyczących zabezpieczeń tych systemów na liście Fundacji OWASP. Krzysztof Labuda, inżynier bezpieczeństwa i uczestnik programu Certified Ethical Hacker CEH v11, opowie Wam więcej na temat zagrożeń wyszczególnionych w OWASP TOP 10 IoT.
Fundacja OWASP opracowuje poradniki i wskazówki dla podwyższania bezpieczeństwa różnych systemów, również IoT.
Dziś skupię się na temacie protokołów szyfrujących w systemach bezpieczeństwa IoT, temacie równie ważnym, co mało jeszcze opowiedzianym, a zaznaczonym jako jeden z ważnych w zestawieniu OWASP. Od 2014 pojawiły się 2 iteracje takich list, a aktualna znajduje się tutaj.
Więcej o fundacji OWASP przeczytasz we wpisie: OWASP TOP TEN i STRIDE – wsparcie w opracowywaniu planu testów penetracyjnych.
Kiedy podchodzimy do tematu zapewnienia cyberbezpieczeństwa w systemie IoT, należy zadbać, by dane przechowywane zarówno na urządzeniach, jak i w chmurze, używały protokołów, które w warstwie prezentacji dokonują operacji szyfrowania. W protokołach szyfrujących dla IoT należy zwrócić uwagę na to, jakich wersji współzależności używamy – OpenSSL czy serwery SSH w podatnych wersjach mogą umożliwić atakującym uzyskanie dostępu do danych wrażliwych (na przykład szeroko znana podatność Heartbleed). Dobrą i pożądaną praktyką dla bezpieczeństwa IoT jest, żeby operacje szyfrowania danych przechowywanych na urządzeniach były realizowane przez dedykowane systemy kryptograficzne takie jak TPM czy HSM.
By zapewnić należytą poufność danych, zadbaj o to, żeby mechanizmy kryptograficzne zapewniające szyfrowanie zostały użyte właściwie i starannie oraz były bezbłędnie skonfigurowane.
Powinny też wykluczać scenariusze renegocjacji połączenia, dewaluując je do schematów ze znanymi podatnościami (Downgrade Cryptographic Attack). Sposoby szyfrowania muszą nadążać za wykładniczym wzrostem mocy obliczeniowych komputerów (zgodnie z prawem Gordona Moore’a). Niektóre starsze schematy kryptograficzne zostały wycofane i uznane za niebezpieczne między innymi z powodu wzrostu mocy obliczeniowej.
Bolączką najstarszych schematów SSL – (SSlv2 DROWN attack, SSLv3 – Poodle attack) są luki w samej architekturze tych rozwiązań. Utorowały one drogę do schematów TLS – z 4 obecnych na dziś (październik 2022) już wersje 1.0 i 1.1 osiągnęły status kryptograficznej emerytury. Najgorszym z rozważanych przypadków jest dopuszczenie renegocjacji do formy komunikacji, bez szyfrowania w ogóle.
Co to jest renegocjacja? Przykład: zanim się połączymy, na jednej z warstw następuje swego rodzaju “negocjacja połączenia”, bo protokoły muszą się zestawić. Podobnie, gdy dzwonimy do kogoś, żeby zapowiedzieć swoją wizytę. Dzwonimy – jeśli ktoś nie odbiera, to jest szansa, że gdy się zjawimy nikogo nie zastaniemy, ale jeśli ktoś odbierze, istnieje większa szansa, że do spotkania dojdzie.
Z protokołami szyfrowania urządzeń IoT bywa podobnie. Jeśli klient dostaje zapytanie z jakimś typem szyfrowania od serwera, ale go nie obsługuje – proponujemy mu inny, czyli renegocjujemy. Niemniej jednak powstaje tutaj ryzyko, bo wobec klienta po stronie serwera musimy być asertywni, gdy będzie on proponował niebezpieczne na daną chwilę sposoby szyfrowania (lub w przypadku skrajnym – brak szyfrowania).
Podczas tworzenia systemów IoT trzeba jak ognia wystrzegać się używania protokołów, które w komunikacji nie stosują żadnego szyfrowania, takich jak Telnet, FTP, HTTP czy SMTP. Warto również rozważyć stosowanie technologii VPN – Virtual Private Network. Na pewno takie podejście znacząco podniesie bezpieczeństwo sieciowe oraz prywatność danych.
Autorem tego artykułu jest Krzysztof Labuda, uczestnik programu Certified Ethical Hacker CEH v11, który uczy najnowszych narzędzi, technik i metodologii hackerskich klasy komercyjnej, używanych przez hakerów i specjalistów ds. bezpieczeństwa informacji.
