Sytuacja kobiet w IT w 2024 roku
4.03.20207 min
Marcin Sikorski

Marcin SikorskiSenior Test Engineer

Internet rzeczy naprawdę taki groźny?

Sprawdź, co powoduje lęk przed Internetem rzeczy i czy rzeczywiście jest się czego obawiać.

Internet rzeczy naprawdę taki groźny?

Dyskusja na temat IoT to ideowa konfrontacja przepełniona fałszywymi wyobrażeniami. Argumentum ad populum – „dobrze wiecie, że technologia jest niebezpieczna” – ma zapchać każdą dyskusję i postawić tech entuzjastów na stanowisku ignorantów - ślepo zapatrzonych miłośników i czcicieli smart symbolu.

Ale ile jest w tym wszystkim prawdy? Gdzie przebiega ta cienka granica między problemem, a ludowymi mitami, w których korporacje są złe, a my dajemy się oczarować manipulacji zamykając się w szklanym domu. Czy lepiej jest być nad wyraz przewrażliwiony czy zrównoważony w czasie gdy świat wali się na naszych oczach? I co to w ogóle znaczy, że „IoT jest skomplikowany i niebezpieczny”?

Zacznijmy od zdarcia królewskich szat i sprawdzenia czy Internet rzeczy jest istotnie zawiły. 

Masy twierdzą, że nijak nie da się tego pojąć, a tymczasem wystarczy, że użyjemy raptem 7 słów: percepcja, sieć, aplikacja; connect, collect, calculate, create i argument trafi do kosza.

Co ciekawe groźno brzmiące „zagrożenia” też nie są aż tak straszne gdy prześwietlimy je z osobna.

Sumę wszystkich strachów możemy sprowadzić do trzech, stałych lęków:

  • ryzyko związane z Internetem,
  • ryzyko związane ze specyfiką urządzeń IoT
  • ryzyko związane z bezpieczeństwem – działaj w myśl swego przeznaczenia.


Co ciekawe obawy te są spójne z innymi przedmiotami codziennego użytku, które nie są jakoś stawiane w negatywnym świetle. Zarówno telefony komórkowe czy nasze laptopy również łączą się z Internetem, muszą działać w myśl określonej specyfikacji oraz wykonywać określone zadanie i rolę, a jednak nie palimy ich na stosie.

Lęki dotyczące IoT, pozornie błahe i stereotypowe, da się rozdmuchać stosując makro perspektywę. To dzięki niej nagle okaże się, że zagrożenia można dowolnie modelować i interpretować! Dołóżmy tylko przymioty określające IoT - skalowalność, łączność, autentykacja, identyfikacja – i sami zaczniemy mieć pewne zastrzeżenia.

 „Przecież nie zabezpieczysz urządzeń, których można liczyć w milionach.” 

„Przecież setki protokołów nie sprawią, że łatwiej będzie nam utrzymać zdrową i bezpieczną przepustowość.”

„Przecież autentykacja i autoryzacja ciągle kuleją.”


Bardziej szaleni rzucą sloganem o śmiercionośnym 5G, umiarkowani sceptycy wytkną nieudolność branży, a techniczne osoby skupią się na detalach pokroju identyfikacji tekst/Base64 zamiast JWT (JSON Web Tokens), która jest równie ułomna co niedoskonała.

Będąc adwokatem diabła muszę przyznać, że istnieje całkiem spory wachlarz narzędzi, których moglibyśmy użyć by zagrozić ekosystemowi opartemu o IoT.

Można zacząć do fizycznego ataku - by stosując reverse engineering albo microprobing – dobrać się do wnętrzności urządzenia. Niektórzy są zdziwieni ale większość informacji dotyczących specyfikacji jest ogólnodostępna i nie wymaga od nas setek godzin mozolnej pracy. Część cennej wiedzy zdobędziemy wyszukując numer FCC, część trafi do nas wprost z githubowych repozytoriów, część dostarczy nam shodan.com. Uprzejmość w branży bywa ujmująca.

Następnie polecam atak na środowisko – sugeruję na początek klasyczny cache-timing attack, który w przypadku IoT jest niezwykle przyjemny sprowadzając się do trzech metod - Evict + Time | Prime + Probe |Flush + Reload – a które mają ten sam cel – manipuluj pamięcią podręczną do znanego stanu, a następnie „poczekaj” na aktywność ofiary i sprawdź, co się zmieniło.

Ewentualnie zawsze można posłużyć się atakiem side-channel, które polegają na wykorzystaniu pewnych detali implementacji, które niosą ze sobą nieprzewidziane wcześniej konsekwencje. Mając precyzyjny sprzęt pomiarowy możemy np. obserwować zużycie energii, a co za tym idzie, emisję elektromagnetyczną urządzenia. Badając właściwości fizyczne urządzeń, dowiadujemy się co dzieje się wewnątrz wnioskując przetwarzane informacje. Nasłuchujemy, analizujemy i badamy zużycie energii, które daje nam cenną wiedzę.

Potem możemy posłużyć się atakiem w oparciu o kryptoanalizę – chosen-plaintext, man-in-the-middle lub zwykły atak ze znanym tekstem jawnym, w którym dysponujemy pewną ilością oryginalnych wiadomości wraz z ich szyfrogramami. Może i jest to prosty trik lecz nader skuteczny ale czego oczekiwać w dobie „releasu za wszelką cenę”.

Na koniec zostaje nam atak na oprogramowanie – trojany, wirusy, robaki, bomby logiczne, denial of service. Czasem zwyczajny dex2jar na oficjalnej aplikacji producenta ujawnia wszelkie luki i fakt, że nikt dostatecznie nie zabezpieczył urządzenia.

O samej sieci celowo nie wspomniałem bo gama dostępnych opcji – nasłuchiwanie, analiza pakietów, node subversion, routing attack – to czubek góry lodowej, której celem jest dobranie się do zawartości produktu i identyfikacji cennych danych.


Winić za ten stan rzeczy można wiele czynników.


Bezpieczeństwo to studnia bez dna, która pochłania mnóstwo zasobów finansowych i czasowych. Nie mówiąc o konieczności upchania w „zbyt małe urządzenia, o zbyt wątłej baterii i niskiej mocy obliczeniowej” czegoś co mogłoby spełniać sensowną funkcję ochronną, a przy okazji nie zeżreć połowy przestrzeni pamięci.

Sama kryptografia również nie należy do najtańszych, a uświadomienie klientom pleonazmu “lekki, skuteczny, darmowy algorytm” jest syzyfową pracą.

Na domiar złego nie istnieje złoty środek i uniwersalne remedium, które zawsze zadziała. Każdy przypadek jest indywidualny i wymagający. Każdy będzie potrzebować osobnej analizy. A jak wiemy z doświadczenia w wielu projektach nietechnicznych klient nie zrozumie tego, że potencjalnie i w przyszłości może dopuścić do utraty dobrego imienia i wycieku cennych danych. Wartość ma tylko to co tu i teraz.

Ostatecznie i tak wszystko pęka w drobny mak gdy uzmysłowimy sobie poziom skomplikowania. Każde kolejne urządzenia, kolejny protokół, kolejny pakiet, kolejna metoda, kolejny sposób – wszystkie te elementy rozpychają już i tak nabrzmiały balonik, który czeka tylko aby pęknąć. Niby są standardy, niby są wytyczne, niby są dobre praktyki ale większość z nich to mistyczne istoty, które nie osiedlają się w pobliżu projektów.

No ale weź tu przekonaj klienta, że trzeba wydać mnóstwo pieniędzy by zabezpieczyć interfejs WWW, wzmocnić uwierzytelnienie, zapewnić bezpieczne usługi sieciowe, dodać szyfrowanie podczas transportu danych, uchronić chmurę, osłonić interfejs mobilny oraz przygotować fizycznie urządzenie do trudnych i nietypowych warunków atmosferycznych i transportowych. 


Za dużo, za drogo, za długo.


Jeszcze trudniej jest wyjaśniać mu takie koncepcje jak: sinkhole attack – tzn. jeśli czujniki pozostaną w sieci bez nadzoru przez określony, zwykle długi czas, stają się podatne na atak. Zaatakowany węzeł udostępnia informację ze wszystkich otaczających go węzłów – selective forwarding attack – czyli nody, które mogą wybierać pakiety i je usuwać selektywnie filtrując i upuszczając określone pakiety z cennym ładunkiem - witch attack - atak ma miejsce, gdy złośliwy węzeł IoT wykorzystuje występującą awarię oficjalnego węzła.

Co zabawne w przypadku awarii takie łącze przekierowuje przez złośliwy węzeł dla całej istniejącej i przyszłej komunikacji – klasyczny już HELLO flood attack - wysyłając niezliczone ilości wiadomości do wszystkich sąsiadów, których ma w zasięgu częstotliwości. Gdy wkupi się w ich łaski ponownie zaczyna wysyłać wiadomość co z kolei wpływa na ich dostępność. Ataki te powodują niedostępność zasobów kreując ocean nonsensownych żądań do określonej usługi- czy wytłumaczyć czym jest replay attack – czyli atak podczas wymiany informacji związanych z tożsamością. Następuje ich sfałszowanie lub zwielokrotnienie. Na upartego to swego rodzaju aktywny man-in-the-middle-attack.

Jak na ironię brzmi to wszystko niezwykle poważnie i groźnie ale w rzeczywistości nie jest to dużo bardziej przerażające niż to co oferuje nam obecnie Internet.

Pomijając trojany i wirusy mamy w sieci “do dyspozycji” DDOS, MitM, Phishing, drive-by attack, jak również wszelkiej maści wstrzykiwanie SQL, ataki XSS, nasłuchiwania, malware czy inne socjotechniki, które mają na celu wyłudzenie naszej tożsamości i danych. A mimo to mało kto panikuje wieszcząc, że oto nadchodzi nasza zguba i kres.

Okres młodzieńczej niedoskonałości IoT z całą pewnością da się wyleczyć stosując podstawowe metody zapobiegawcze lub nowo powstające techniki. Może blockchain w połączeniu ze schematem szyfrowania homomorficznego umożliwi nam sposób obsługi urządzeń bez ujawniania wzorców wyszukiwania czy faktycznego oglądania oryginalnych informacji. Na to wszystko nałożony będzie łańcuch, który sprosta wymogom zaufania.

Przyszła infrastruktura oprzeć się może o zaufanie na bazie inteligentnych umów. Te realizowane będą wraz z kolejnymi blokami łańcucha będącego sposobem na interakcje między poszczególnymi urządzeniami. Co najważniejsze ominiemy w ten sposób czynnik ludzki. BIM (inteligentne budynki) już zmierzają w tę stronę umacniając mnie w przekonaniu, że może to być słuszna droga.

Ale rozmowa na ten temat to jak wróżenie z fusów.

Niby słyszymy o modzie na holistyczną koncepcję świata, w której security stawiany jest na piedestale całego trwania cyklu projektu, ale kiedy i jak ma to niby nastąpić w dobie „szybko, szybciej”? Czasem potrafimy polegnąć nawet na tak prozaicznym detalu jak konieczność generowania setek aplikacji do kontroli IoT zamiast skupieniu się na jednym ekosystemie, w postaci mega aplikacji, jak czynią to np. w Chinach za sprawą WeChata.

Potrzeba będzie wielu niezrealizowanych projektów nim znajdziemy w sobie zdolność do wspólnego diagnozowania problemu i spróbujemy wdrożyć plany zapobiegawcze już na wczesnym etapie.

Bo cała ta sytuacja dotycząca bezpieczeństwa Internetu rzeczy przypomina mi trochę historię związaną z testowaniem. Musiało upłynąć naprawdę wiele wody w Wiśle niż branża zrozumiała ich istotną rolę. Teraz dostrzegam podobną sytuację z rynkiem IoT, który zapełnia się on kolejnymi produktami, wykorzystuje konsumpcyjny głód społeczeństw i cieszy się z krótkotrwałych zwycięstw ale nie widzi potrzeby w zatrudnianiu specjalistów od zabezpieczeń.

A z czasem słyszymy o braku wsparcia dla urządzeń, negatywnym PRze firm, które gwarantowały skuteczność działania, podsłuchiwaniu wtłoczonym w kolejne aktualizacje czy złamaniu produktu, który zagroził czyjemuś życiu. Czasem jest śmiesznie, czasem jest straszno. Tylko, że koniec końców odbija się to potem echem na całej branży.

Prawda jest taka, że dyskusja na temat zagrożeń ze strony IoT to tak naprawdę zawsze będzie walka z “czterema jeźdźcami wykluczenia”:

  • Niezainteresowaniem
  • Pomówieniem
  • Zwątpieniem
  • Niedoinformowaniem


To w naszej gestii będzie aby stopniowo i sukcesywnie obalać kolejne wątpliwości i uczyć prawidłowych wzorców. Rozwijać dobre praktyki, rozwiązywać problemy i edukować świat.

Może będzie to wymagać mnóstwa czasu i zaangażowania ale hej – nikt nie zaprzeczy, że cel wart jest wysiłku.

<p>Loading...</p>