Na sam tytuł, moja żona wymownie przewraca oczami.. Kiedy mówię, że każde gniazdko ma swój login i hasło, puka się w głowę. Po prostu wie, że żyje z lekko stukniętym typem pod jednym dachem. Ale, jak to pisze mój kolega-filozof, janieotym.
Rosnące ceny energii i ogólny rozwój “inteligencji” naszych domów i mieszkań, przy boomie na fotowoltaikę przyciągnął na dłużej moją uwagę. A jakieś ogólne rozważania o bezpieczeństwie IoT (ale też i wysokości rachunków za prąd) pchnęły mnie do działania. Na pierwszy ogień poszły gniazdka Gosund SP111 z Tasmotą na pokładzie. Fajna rzecz, wytrzymymuje obciążenie do 3,45kW i jeszcze mierzy prąd, napięcie, obiążenie i cosinus fi - czyli też przesunięcie fazowe!. A jak weterani różnych elektrycznych techników pamietają, ongi cosinus fi przynosiło się w wiaderkach. ;-) A tu proszę.. mierzy samo i z wiadrami żadnymi latać nie trzeba.
No więc do ad remu przechodząc, po głowie chodził mi temat pomiaru poboru mocy przez różne urzadzenia pożerające prąd (..i cosinus fi!), ale w jakiś uporządkowany i bezpieczny sposób. W swojej wrodzonej i nabytej nieufności do rzeczy, w których “samo się” dzieje, gdzie przy rzeczach “inteligentnych” zapala się czerwona lampka, chciałem zbudować działającą koncepcję tak realizowanych pomiarów. Najlepiej spełniającą kardynalny postulat “to co dzieje się w domu, pozostaje w domu”. Dlatego też, odpadły wszelkie chmury, historie typu “zanim wepniesz gniazdko.. załóż konto..” i “wygodne appki na telefon”. Postanowiłem zrobić PoCa (ang. Proof of Concept).
Elementy układanki
Poniższa lista przedstawia wszystkie elementy układanki, które postanowiłem złożyć w jedno rozwiązanie, działające i bezpiecznie i wygodnie i sprawnie. Dużo tego nie ma, ale myślę, że takie na pozór łatwe ćwiczenie dało mi niezłą dozę wiedzy, z jakimi przeciwnościami losu trzeba się mierzyć by zadbać o bezpieczeństwo takich instalacji.
- Gosund SP111 - inteligentne gniazdko (układ ESP8285),
- Tasmota 12.3.1 - firmware Open Source do gniazdka,
- Mosquitto - Open source-owy broker MQTT,
- Telegraf - konsument danych z MQTT, translacja danych do TSDB,
- InfluxDB TSDB.
Tu opcjonalnie, na sam koniec można dodać jeszcze Grafanę, w której można opracować ładniejsze i bardziej niż w samym InfluxDB, funkcjonalne dashboardy, alerty i powiadomienia. Na PoC wystarczy to co jest.
Analiza zagrożeń
Z życia wiemy, że zagrożenia czyhają na nas wszędzie i nie chodzi tylko o własną, niewymuszoną niefrasobliwość, bądź głupotę. Postronnym sluchaczom może się to wydawać jakąś fantasmagorią - ej, no weź.. kto Ci się będzie włamywał do gniazdek?!. I tak dalej. Nie, nie będziemy tutaj znowu uprawiać Bayesa, chociaż można by spróbować zebrawszy uprzednio jakieś wiarygodne statystyki dotyczące włamań do domowych IoT (nie przemysłowych - to inna odmiana tego samego zagrożenia, bo intencje są inne) i szkód przezeń spowodowanych. No dobrze, ale kontynuując - takie domowe gniazdka skoro mają nam służyć swoją nietuzinkową inteligencją, muszą zostać podłączone do jakiejś sieci TCP/IP (przez Wifi) i obsługiwać komunikację do i z gniazdka.
Zagrożenia
Zagrożenie właściwie jest jedno - włamanie do domowej sieci. Natomiast jedną z miar zagrożeń (przy rozpatrywaniu istotności takiego zagrożenia) mogą być intencje, które warunkują cele takich włamań. Spróbujmy je wymienić:
- Scenariusz 1: Włamanie do sieci celem przejęcia kontroli nad “inteligecją” domową - z intencją późniejszego włamania do samego domu. A zatem przejęcie kontroli nad “inteligencją” posłuży do tego, aby np. w nocy brama została otwarta, a czujniki ruchu wyłączone, a przez kamerę przy wejściu prześledzić można zwyczaje domowników, kto kiedy wychodzi i wraca..itd.
- Scenariusz 2: Włamanie do sieci celem dojścia do ważnych zasobów informacji na komputerach domowych z intencją późniejszego wykorzystania danych - wykorzystanie danych osobowych do wzięcia stu pożyczek, kompromitacja ofiar w internecie wykorzystując wrażliwe dane prywatne, itd.
- Scenariusz 3: Włamanie się do sieci celem wykorzystania zasobów domowych z intencją użycia zasobów domowych jako trampoliny do dalszych niecnych działań w internecie - np. przez instalację botnetu i realizacja kampanii phishingowych (tu mam żywy przykład u pewnej rodziny sprzed 2 tygodni, przyszła do nich policja że z IP - rutera domowego, a miał statyczny, wysyłany był malware, przez który ludzie z innych stron Polski potracili pieniądze z kont bankowych - przyczyną nie musiało być IoT, ale skądinąd akurat mogło być..)
- Scenariusz 4: Włamanie celem wyrządzenia szkód - jeśli na IoT mamy jakąś zaawansowaną automatykę sterującą pompą ciepła, piecem, regulacją fotowoltaiki itd. to człowiek z takimi intencjami i zaawansowanymi umiejętnościami, może np. popsuć urządzenia warte kilkanaście - kilkadziesiąt tys. złotych.
- Scenariusz 5: Włamanie do sieci, celem zdobycia informacji pozwalającej na wyrządzenie szkód konkurencji, bo np. ofiara jest prezesem jakieś ważnej spółki i byłoby super dostać się do jej laptopa, a jak wiemy nie tylko korporacje z zabezpieczonymi po zęby laptopami biorą udział w ważnych i dużo wartych przetargach. Wiele osób ma np. tylko darmowego Avasta, jeśli ma cokolwiek..
Jeśli w ten sposób spojrzymy na instalacje IoT i pomyślimy jako szczęśliwy posiadacz i użytkownik instalacji IoT - to którykolwiek z w/w scenariuszy zagrożenia z pewnością będzie mógł przypisać do swojej sytuacji. Ale jak!? No to prześledźmy:
Profile potencjalnych ofiar włamów do/przez IoT:
- Nie mam domu, nie mam fotowoltaiki, nie jestem prezesem i nie prowadzę w ogóle żadnej firmy, nie mam nawet konta w banku:
- Scenariusz 2 lub/i
- Scenariusz 3,
- Mam dom, nie mam fotowoltaiki, nie jestem prezesem i nie prowadzę żadnej firmy:
- Scenariusz 1,
- Scenariusz 2,
- Scenariusz 3,
- może Scenariusz 4
- Mam dom, fotowoltaikę, prowadze firmę, która startuje w różnych przetargach:
- tu właściwie wszystkie scenariusze nam się “uaktywniają” jako możliwe, a nawet ich kombinacje.
Podsumujmy ten alarmistyczny wywód w kontekście natury takich małych a inteligentnych urzadzonek jak żarówki, gniazdka, czujniki czy kamery. Są to sprzety małe, oparte o układy przemysłowe, wytwarzane na przemysłową skalę, których specyfikacje i oprogramowanie jest szeroko dostępne (jak np. Tasmota). Ze swojej natury borykają się z licznymi ograniczeniami - i nie są to tylko zaniechania producentów - jest to na przykład ograniczona pojemność RAM w którą można upakować nie tylko niezbędną funkcjonalność, ale i nie-funkcjonalność w postaci mechanizmów bezpieczeństwa. Takich jak: możliwość zmiany fabrycznie ustawionej nazwy konta admina, możliwość konfiguracji TLS 1.2 do komunikacji, bezpieczne (silnie zaszyfrowane) przechowywanie haseł czy tokenów uwierzytelniających, zaawansowane metody uwierzytelniania, obsługa WPA3 czy choćby WPA2-PSK ale z szyfrowaniem AES, zmiana MAC adresu, czy choćby nazwy urządzenia. Takie gniazdko Gosund SP111 ma 1MB RAM, z czego firmware z tym co oferuje zajmuje 630kB.
Z drugiej strony tak jak w całym świecie IT i na całym świecie mamy zaniechania, lenistwo i nieświadomość człowieczą, przy instalacji i eksploatacji. Poza tym nie każdy instalator IoT musi się znać na wszelkich typach ruterów bezprzewodowych - na jednym “network isolation” ustawia się jednym klikiem, na innych wyłącza po prostu forwarding ruchu sieciowego, ale trzeba dorzucić reguły do firewalla. No i te aspekty dodane do siebie, wyczerpują nam w zupełności powagę istotności opisanych scenariuszy zagrożeń.
Co robić, jak żyć?
Znowu (po raz któryś! dziwne..) pojawia się zasadnicze leninowskie pytanie “co robić?!”. Spróbować wybrać tak, i zaprojektować tak, i poskładać tak tę instalację aby się przed takimi zagrożeniami jednak obronić. To znaczy tak utrudnić potencjalnym amatorom silnych wrażeń w IoT zadanie, żeby im się nie opłacało w ogóle nawet chcieć. W ocenie zagrożeń i doborze technik przeciwdziałania może nam pomóc matryca MITRE dla ICS (ang. Industrial Control Systems).
MITRE
Towarzyszom niedoli z mojej branży nazwa MITRE kojarzyć się może z bazą podatności CVE. Ale nie tylko. MITRE jako organizacja non-profit sponsorowana przez rząd USA zajmuje się też rozwojem metodyki analizy zagrożeń w cyberprzestrzeni (IoT jest jej częścią) zwanej ATT&CK. Rzecz polega na bieżącej analizie i profilowaniu zagrożeń w cyberprzestrzeni i mapowaniu zaobserwowanych działań w podziale na poszczególne fazy ataków - taktyki oraz techniki i pod-techniki służące osiąganiu celów pośrednich by przejść do kolejnych faz i ostatecznie osiągnąć sukces (a przynieść straty ofiarom). I takie mapowanie właśnie wykonano też dla ICS, u nas znane bardziej jako systemy automatyki przemysłowej. Bo z tego właśnie nasze domowe IoT wyewoluowało wraz z postępującą miniaturyzacją, standaryzacją protokołów komunikacji, niskimi kosztami wytwórczymi i upowszechnieniem internetu. I jak się okazuje - całkiem nieźle pasuje nawet do tak niewyszukanych instalacji IoT jak moja.
No to nieźle. Z głupiego (sorry.. inteligentnego!) domowego gniazdka wypłynęliśmy na szerokie wody cyberprzestrzeni i sponsoring USA! A to by się Lenin zdziwił, taką odpowiedzią. ;) No niestety, jeśli chodzi o bezpieczeństwo w cyberprzestrzeni (też!) to nikt nie dzwoni do Szwecji. Bierzemy się do pracy. Pokażę, jak te groźne scenariusze zagrożeń opisane powyżej, przekładają się na metodykę ATT&CK. A także jakie zabezpieczenia adekwatne do skali i możliwości naszego rozwiązania mogą przeciwdziałać tym zagrożeniom.
ATT&CKujemy IoT
Sprawczość pomocnicza w ochronie naszego IoT, objawia się w możliwości odpowiedzi na następujące pytania:
- Na jakie scenariusze zagrożeń jesteśmy narażeni posiadając taki-a-taki system IoT, który ma zaimplementowane takie-a-takie mechanizmy bezpieczeństwa i przeciwdziałania włamaniom?
- Jakie mechanizmy bezpieczeństwa i przeciwdziałania włamaniom powinniśmy zaimplementować, aby udaremnić realizację danych scenariuszy zagrożeń?
- Czy zaimplementowane mechanizmy bezpieczeństwa i przeciwdziałania włamaniom uchronią nas przed danymi zagrożeniami?
I jak myślicie - na które pytanie zechcemy sobie odpowiedzieć? No tak, robimy PoC-a, jakieś pojęcie mamy, ale chcemy uzyskać konkretną listę, konkretnych tematów do implementacji w naszym PoC-u, aby nie martwić się o scenariusze, którymi sam siebie wystraszyłem tam nieco powyżej w tekście. A więc będzie to pytanie nr 2.
Co przeanalizujemy? Potencjalny atak, jego wektor i cele atakującego zakładamy w treści scenariusza nr 2 i 3. Celem ataku będzie zwyczajna, powszechna sieć domowa WiFi, czyli ruter WiFi podpięty do infrastruktury dostawcy z jakąś konfiguracją zapewniającą szybki internet dla domu, kilka urzadzeń domowych - komputerów/laptopów, może serwer jakiś, może jakiś TV i nasze gniazdka.
Otwórzmy sobie w przeglądarce narzędzie analityczne ATT&CK Navigatora. Wybierzmy “Create New Layer” i poniżej kliknijmy w “ICS”. Pojawi nam się matryca z ponazywanymi kolumnami, a w każdej z kolumn techniki realizacji ataku. Coś takiego:
Jeśli wrócimy do domowej strony matrycy dla systemów automatyki przemysłowej i klikniemy np. w pierwszą na samym dole technikę “Wireless Compromise”, to w taktyce “Initial Access” zobaczymy zamapowane scenariusze przeciwdziałania (ang. Mitigations) dla podstawowej taktyki ataku naszego systemu IoT. Bowiem, moim zdaniem, domowe IoT nie będą w dużej mierze celem samym w sobie, a słabością, którą wykorzysta atakujący by zrobić nam krzywdę (albo nawet nie nam) gdzie indziej - o czym mowią opisane wyżej scenariusze. Więc ruszajmy dalej. Pierwszym zadaniem na liście “Mitigation” jest “M0802 Communication Authenticity “ czyli zapewnienie autentyczności komunikacji. Klikając w tę pozycję dostajemy zwrotnie listę technik atakującego, które zostaną uniemożliwione lub utrudnione przez to przeciwdziałanie. W treści tego przeciwdziałania jest link do CISA (kolejne agencji bezpieczeństwa) gdzie w prosty sposób wyszczególnione są konkretne działania do realizacji. Pasuje do naszych scenariuszy? Pasuje. Dalej pod “Mitigation” mamy mechanizmy detekcji - “Detections” z listą co powinniśmy mieć skonfigurowane, by realizację tej techniki przez atakującego wykryć! W Navigatorze zaznaczamy tę technikę na czerwono. Drugą techniką w taktyce “Initial Access”, która może realna dla naszego przypadku to moim zdaniem “Supply Chain Compromise”, czyli naruszenie łańcucha dostaw. Przekładając to na realia - możemy mieć już w nierozpakowanym pudełku gniazdko z firmwarem, które zawiera nieprzyjemną niespodziankę - wgrany firmware ma dwie malutkie zmiany, praktycznie powodujący może minimalne zmiany w wielkości pliku firmware-u - podmieniony został URL do aktualizacji i uaktywniona opcja automatycznej aktualizacji. Albo też, jeszcze nieobeznani, nieostrożni, ale zapaleni do działania, sami ściągamy upgrade firmware-u z jakiejś nieznanej nam bliżej witryny w internecie. A i w repozytorium Tasmoty - open source-owego firmware-u dla mojego gniazdka, sygnatur nie stosuje się.
I w ten sposób przeglądamy resztę taktyk zaznaczając te, które nam możliwie pasują do rozpatrywanych scenariuszy mając na uwadze zaproponowany (i już nieco rozpoznany) stos technologiczny naszego PoC-a. Tym sposobem, przeglądając resztę technik oraz ich “Mitigation” i “Detection” dochodzimy do końca matrycy. Na czerwono w matrycy w Navigatorze zaznaczamy te, które uznamy za właściwe, możliwe i zgodne z celem i intencją rozpatrywanego przez nas scenariusza zagrożenia. Ostatecznie dostajemy coś w rodzaju takiego obrazka:
Odpowiedź na pytanie
Jakie mechanizmy bezpieczeństwa i przeciwdziałania włamaniom powinniśmy zaimplementować, aby udaremnić realizację danych scenariuszy zagrożeń? Poniżej jest lista, opracowana przeze mnie na podstawie analizy poszczególnych technik. Należy naturalnie wziąć pewną poprawkę na to, że propozycje implementacji tych mechanizmów dotyczą ICS a nie IoT i nie w domu a w przedsiębiorstwie. Wobec tego zalecenia dotyczące np. audytu tego czy owego wypada “przełożyć” na rozwiązanie domowe, np. lepsze ustawienie alertów, albo okresowy jakiś prosty przegląd logów, ostatecznie skreślić z listy. No bo skąd niby w domu miałby się wziąć jakiś audyt? :) Tak samo “Supply chain management” czy “Vulnerability management”. Będą więc propozycje, które:
- Da się zrealizować,
- Częsciowo da się zrealizować,
- Da się zastąpić inną metodą,
- Nie da się zrealizować.
Przy tworzeniu tej listy robimy od razu coś w rodzaju “oceny przydatności”. Z całą tą listą z zawartą tam oceną przydatności i uzasadnieniem rozprawimy się w kolejnym wpisie. Ten wydaje się już i tak dość długi.
Nie mniej jednak, dzięki tej liście, będziemy mogli odpowiedzieć na kolejne pytanie - czy dobór komponentów do PoC zapewni nam oczekiwany poziom bezpieczeństwa (np. uchroni nas przed paskudnymi skutkami scenariuszy zagrożeń). Odpowie nam też na pytanie jaką pracochłonność powinniśmy zaplanować na wdrożenie, ile rzeczy trzeba się nauczyć, ile przetestować, które elementy w naszym PoCu podmienić. No i wreszcie ile to wszystko będzie kosztować.
Podsumowanie
Ten wpis miał być o technicznym wdrożeniu prostego systemu pomiaru poboru mocy przez urządzenia domowe przy pomocy gniazdka Gosund SP111 z Tasmotą na pokładzie. A jednak (surprise, surprise!) przerodził się w rozważania analityczne o bezpieczeństwie takiego rozwiązania. Nic nie szkodzi, w kolejnym wpisie przedstawię techniczną implementację tego PoC wg nakreślonych na samym początku założeń. Przykład, hmm.. może nie być zbyt adekwatny do popularnych potrzeb (mało kto w domu ma serwery z Nomadem, Consulem i Vaultem gdzie w bezpieczny sposób może składować i wymieniać dane uwierzytelniające poszczególnych komponentów rozwiązania). No ale tez chodzi o to, aby pokazać, że nie jesteśmy bez szans, ani nie jesteśmy skazani na umowne “bezpieczeństwo” danych w jakichś tam chmurach producenckich.