Poprzedni odcinek mojej osobistej rozprawy z bezpieczeństwem IoT zakończyłem może nieco przedwcześnie. Ba! na pewno! Jeżeli jesteśmy jednak chociaż trochę zainteresowani metodyką MITRE ATT&CK to warto poświęcić jej cały kolejny wpis. Będzie to bowiem nakreślenie całkiem fajnej, logicznej, elastycznej i szybkiej metody podejścia do projektowania zabezpieczeń w świecie IT. Wyjście z profilu zagrożeń (scenariuszy) do nakreślenia architektury bezpieczeństwa rozwiązania i (mam nadzieję) zgrabne przejście do samych technikaliów w części trzeciej (kolejnym, ostatnim już wpisie o IoT). No tak, znowu miało być technicznie, a wyjdzie analitycznie. Bardzo jednak chcę wykonać to ćwiczenie z ATT&CK-iem, by nawet samemu sobie zademonstrować przydatność tej metodyki.
Na obrazku widzimy prosty algorytm postępowania z MITRE ATT&CK aby odpowiedzieć sobie na pytanie, co zrobić by być bezpiecznym przed konkretnym profilem zagrożeń. Nie jest to jakiś złoty środek na wszystko. Przez przypadek, domowe IoT stało się po prostu wdzięcznym przykładem dla przedstawienia tej metodyki, w miarę zwięzły sposób. Przy poważniejszych projektach, należy zabrać się jeszcze za szacowanie pracochłonności, kosztów, zasobów. Przemyśleć i oszacować wpływ na operacje i utrzymanie. Najważniejsze jednak, że mamy logiczną i spójną odpowiedź - DLACZEGO chcemy takiego wdrożenia. Bowiem jest to metodyka, którą można (i chyba nawet powinno się) stosować przy projektach cyberbezpieczeństwa. Tak by nie strzelać na ślepo, nie próbować interpretować kolorowych nonsensownych HEATMAP albo też wierzyć tylko “sejlsom”, po iluś spotkaniach (“masowania klienta”, jak to oni mówią), że teraz to już będzie dobrze.
Analityka
Przeglądając zaznaczone w poprzednim wpisie techniki w mapowaniu MITRE, uznałem, że nieco się rozpędziłem. Zawsze przyda się drugie spojrzenie i weryfikacja. Zatem według tego “drugiego spojrzenia” nasi potencjalni złoczyńcy (wg scenariuszy nakreślonych w poprzednim wpisie) mogliby posłużyć się takimi oto technikami:
A skąd akurat te, a nie inne? Pamiętajmy, że rozpatrujemy konkretne scenariusze zagrożeń, których celem jest nasza domowa instalacja IoT. Wobec tego tzw. powierzchnia ataku jest już znacznie bardziej ograniczona niż jakieś złożone systemy automatyki przemysłowej w przemyśle motoryzacyjnym czy przetwórstwa żywności (i napojów..). Przy rozpatrywaniu takich czy innych technik, nalezy też mieć na uwadze nie tylko szanse powodzenia takich technik, ale i szanse ich wystąpienia. Czyli szanse, że taki złoczyńca się pojawi, a jego zamiary będą mu się opłacać. Tym bardziej, że Shodan.io jest dość bezlitosny dla beztroskich entuzjastów IoT i Tasmoty.
I z tego punktu widzenia, taktyka “Initial Access“ czyli możliwość znalezienia punktu zaczepienia do dalszego postępowania w ataku praktycznie, przy naszych scenariuszach ograniczyć może się do max. trzech możliwości:
- “External Remote Services” - opis tej techniki może sugerować np. taką możliwość, iż istnieje jakiś portal, który poprzez SEO przyciąga uwagę amatorów Tasmoty, tam czai się już skrypt w zwykłym PHP, który wykona się na laptopie takiego amatora i sobie ładnie wypróbkuje sieć na obecność urządzeń z dostępem bez ustawionego hasła, bądź “admin/admin”. Jak włamywacz będzie miał więcej szczęścia, a entuzjasta bardziej niefrasobliwy, to od razu tamten podgra temu swój firmware. Przypadek opisany w issues na Githubie dla Tasmoty;
- “Supply Chain Attack” - ten przypadek już pokrótce opisałem w poprzednim wpisie, kupujemy sobie gniazdko z jakiegoś “tańszego” źródła, gdzie cena jest po prostu haczykiem lub wykonujemy aktualizację nie bacząc na źródło pochodzenia binarki;
- “Wireless Compromise” - i ten przypadek jest najbardziej prawdopodobny. I nieszczególnie też trudny do realizacji. Sposoby przechwytywania i łamania haszy przy wymianie komunikacji uwierzytelniającej klienta z Access Pointem są opisane na 950 tysięcy sposobów w Internecie, krok po kroku z komendami i przykładami. Wystarczy mieć laptopa z WiFi, resztę zrobi aircrack-ng nawet z tutoriali.
W taktyce “Execution“ - nie, to jeszcze nie egzekucja - mamy techniki, które pozwolą cyberzbójcerzom zacząć mościć sobie wygodne gniazdko w gniazdkach naszej sieci. O ile, oczywiście nie jest to atak jednorazowy bez specjalnie wielkich planów na przyszłość. Tasmota charakteryzuje się tym, że jak na swoje 630kB ma i WebUI z funkcjonalnością konsoli, wystawia API do którego również możemy wysłać zdalnie komendy dla urządzenia. Wisienką jest możliwość sterowania urządzeniem przez tematy MQTT (ang. topics), na przykład wysyłając urządzeniu na jego właściwy temat komendę resetu hasła do “admin/admin”:
Zastosowanie technik z taktyki “Persistence“ pozwoli natomiast cyberzbójcerzom albo na dłuższy niedostrzeżony pobyt w naszym IoT albo też na bezpieczne (dla nich) powroty w chwili gdy uznają, że mają w naszym IoT jeszcze coś do załatwienia. Tutaj wybrałem dwie techniki, możliwe do wykorzystania, skoro już udało się na samym początku, a więc:
- “Hardcoded Credentials” - Tasmota ma fabrycznie ustawionego użytkownika “admin”, zostaje albo odgadnąć hasło albo je zmienić na “admin”. O ile mnie własne testy nie mylą, to Tasmota pozostaje niewzruszona na brute-force-ową zgadywankę. Przy czym, może się okazać, że hasło jest takie samo dla wszystkich urządzeń. Ja mam cztery takie gniazdka, ale ktoś może miec ich 140..
- “System Firmware” - tutaj, w kontekście naszych scenariuszy i przedmiotu ataku, mamy tę samą praktycznie technikę, jak przy “Supply Chain Attack”. Co nie musi być regułą w innych przypadkach.
Taktyka “Discovery“ posłuży atakującym na bliższe poznanie się z naszą zaatakowaną siecią, jej strukturą i innymi domownikami. O ile powiodły się poprzednie techniki, nasz złoczyńca ma do dyspozycji konsole, wszelkie ustawienia WiFi, IP, DNS, NTP, MQTT, itd. Jeśli nie mamy ustawionej polityki Network Isolation czy też wyłączonego forwarding chain na ruterze/WAP, to bardzo ułatwiamy robotę nieproszonym odkrywcom. Dlatego też, poniższe dwie techniki będa raczej pasować:
- “Network Connection Enumeration” - popatrzy w logi, popatrzy w konfigurację
- “Remote System Information Discovery” - ..i już będzie wiedział, gdzie co jest i gdzie warto sięgnąc, aby być może twórczo rozwinąć atak na inne potencjalnie ciekawe miejsca w naszej sieci.
Techniki z “Lateral Movement“ i “Inhibit Response Function“ praktycznie wykorzystują (w naszym przypadku) już zdobyte dostępy i uprawnienia. Chodzi o rozprzestrzenienie się po sieci, np. po odgadnięciu IP/nazw i tematów innych urządzeń, schemat dla jednego zapewne zadziała dla innego tylko np. trzeba zmienić numerek IP na kolejny i w nazwie ostatnią cyfrę. To samo dotyczy maskowania swojej obecności przez modyfikację parametrów odpowiedzi na jakieś zdarzenia rejestrowane przez urządzenia IoT.
Ostatnia z taktyk to nic innego jak próba doprowadzenia do opłacalnej monetyzacji tego ataku, więc otwarcie bramy, odwrócenie kamery, zamknięcie/otwarcia zaworu itd. A więc sprowadzenie na instalację, dom, domowników zagrożenia całkiem bezpośredniego. Uszkodzenie jakiejś instalacji przez zakłocenie działania funkcjonalności dbającej o bezpieczeństwo fizyczne instalacji sterowanej i dozorowanej przez IoT. Ostatecznie sięgnięcie po inne zasoby informatyczne domowników, na ile konfiguracja sieci na to pozwalała, a co zostało rozpoznane w fazie “Discovery”.
A co z pozostałymi fazami, które nie zostały tutaj ujęte na obrazku? Navigator ma fajną funkcjonalność ukrycia rzeczy, które nas nie interesują. Dla przejrzystości rozpatrywanego obrazka. Jak już wspomniałem na początku trzymamy się konkretnego kontekstu, pamiętając, iż ICS to znaaacznie, znaaacznie szersze pojęcie, niż najszersze IoT.
Obrona
Również pamiętamy, że każda rozpatrzona tutaj technika ma w metodyce ATT&CK zamapowane mechanizmy przeciwdziałania. Aczkolwiek, jesli je zacznę tutaj jedna po drugiej mapować po kolei, to wszyscy tu zaraz usną, wraz z autorem (późno już jest.). Ale tutaj nic szczególnie skomplikowanego się nie dzieje. Co robimy?
- Mapujemy sobie nasze taktyki na mechanizmy przeciwdziałania (“Mitigation”) i detekcji (“Detection”).
- Następnie oceniamy - wciąż trzymając się kontekstu - co jest w całości możliwe do zastosowania, w częsci, co można zastąpić innym mechanizmem, a co trzeba odpuscić zupełnie. Ocena taka powinna brać pod uwagę nie tylko to co umiemy, mamy pod ręką, jesteśmy się w stanie nauczyć, czy tez kupić. Należy przy tym antycypować utrzymanie takiego systemu, który i nam może się mocno rozrosnąć w swojej złożoności, kiedy zaczniemy dodawać do niego kolejne klocki. Np. zadając sobie pytanie - czy będziemy okresowo poświęcać dzień w miesiącu, by kompilować i testować nowy firmware, wraz z pojawieniem się nowej wersji bazowej, bądź kiedy pojawi się jakaś dziura (a taką informację też musimy monitorować subskrybując jakieś źródło informacji o podatnościach. A te będziemy sumiennie przeglądać.. i tak dalej). A może sobie tę kompilację firmware-u zautomatyzować? Ale! ale to też kosztuje..i tak dalej. O ile nie jesteśmy szurnięci na punkcie bezpieczeństwa i jednak skłonni nie budować fortecy zdolnej przeżyć jednoczesny atak kilkunastu APT i nalot B-52 naraz, tylko dlatego, że umiemy albo chcemy :)
- A na koniec proponujemy sobie rozsądne i konkretne rozwiązania nie tylko nie zamieniającego naszego codziennego życie w utrzymanie naszych IoT, ale skutecznie utrudnią realizację niecnych planów, np. czyniąc takie realizacje nieopłacalnymi z punktu widzenia intencji włamywacza - np. szybki i duży zysk, minimalne szanse wykrycia - a komplikatory mają bezpośredni wpływ i na szanse wykrycia i na szybkość i wysokość zysku. Pewne sugestie co do zabezpieczeń w tekście niniejszego wpisu już padły.
Poniżej widać tabelkę z tak zmapowanymi propozycjami przeciwdziałania, dla każdej z technik. Jest to tylko próbka. Cała tabelka dostępna będzie tutaj.
| Technika | ID | Przeciwdziałanie | Przydatność | Rozwiązanie |
|---|---|---|---|---|
| Supply Chain Compromise | M0945 | Code Signing | Częściowa | Własne repozytorium kodu Tasmoty. Zródło: repozytorium Tasmoty (bez podpisów). |
| M0817 | Supply Chain Management | Nie dotyczy | Rozwiązanie dla przedsiębiorstw z w miarę przytomnym działem IT. | |
| M0951 | Update Software | Częsciowa, ręcznie | Sledzenie zmian w repozytorium źródłowym, Github: issues. | |
| M0916 | Vulnerability Scanning | Częściowa, ręcznie | J/w. Wykorzystanie platformy GitPod lub platformio.org do automatyzacji linterów i testowania kodu. | |
| Wireless Compromise | M0802 | Communication Authenticity | Częsciowa | WPA2-PSK-AES, długie mocne hasło (ze znakami specjalnymi, małe i wielkie litery i cyfry). Uwierzytelnianie przez RADIUSa.Osobne WLANy dla IoT i reszty komputerów, czy urządzeń domowych (TV, pralka?) |
| M0808 | Encrypt Network Traffic | Częściowa | J/w. | |
| M0806 | Minimize Wireless Signal Propagation | Pełna | Ograniczenie zasięgu emisji radiowej, na WAP i na urządzenia IoT. | |
| M0813 | Software Process and Device Authentication | Częściowa | Jak w przypadku M808 + można jeszcze dodać dość słabe zabezpieczenia, jak filtrowanie po MAC adresach. Certyfikaty, jeśli urządzenia wspierają. | |
| Execution through API | M0801 | Access Management | Częściowa | Ustawienie unikalnych loginów I haseł na urządzeniach. Dla każdej z usług osobno. HTTP (API), MQTT. |
| M0800 | Authorization Enforcement | Częściowa | Wszystkie ustawienia wykonane przed kompilacją firmware, a użytkownik na urządzenia bez uprawnień admina. | |
| M0938 | Execution Prevention | Pełna | Dostęp do API urządzenia, jak również do MQTT powinien być ograniczony na WAPie regułą firewallową. A wszystkie urządzenia objęte polityką "Network Isolation". | |
| M0804 | Human User Authentication | Pełna | j/w |
Detekcja
Jeśli chodzi o możliwości wykrywania podejrzanych działań, w przypadku urządzeń z Tasmotą, można po skonfigurować logowanie zdarzeń i wysyłanie ich do zdalnego sysloga. Jeżeli mamy MQTT i brokera Mosquitto, można też skonfigurować logowanie zdarzeń na tym komponencie. Logowanie zdarzeń z urządzenia z Tasmotą obejmie nam zdarzenia prób logowania się do urządzenia, aktualizację firmware, włączenia, wyłączenia zmiany parametrów. Wiele więcej nie zrobimy. Tym bardziej, że samo wysyłanie logów nam niczego nie załatwi. Musielibyśmy “uzbroić” naszego konsumenta syslogowego w jakąś warstwę pozwalającą na reakcje na określone zdarzenia przez powiadamianie, alerty w dashboardzie itd.
Architektura
Po takiej analizie, można zabrać się za rozrysowanie sobie docelowej architektury, czy też topologii z naniesioną koncepcją obrony.
Do naszej (zakładam) istniejącej sieci z ruterem internetowym, który zapewnia nam w domu tez WiFi i jest odpowiednio już zabezpieczony dokładamy kolejny WAP (Wireless Access Point).Tenże WAP może być podłączony z naszym ruterem albo ethernetem albo też po WiFi. I na tym WAPie ustawiamy osobny WLAN, a komunikację zapewniamy odpowiednimi regułami firewalla i rutingiem. Odcinamy dostęp do internetu z tego WLANu. Podczas przeglądu możliwości Tasmoty natknąłem się na funkcjonalność wystawiania metryk dla Prometheusa. Tym samym można zredukować złożoność rozwiązania rejestracji pomiarów. Zamiast:
można zrobić to tak:
Tym samym wyłączamy kompletnie MQTT i możliwości z tym związane - czyli sterowanie urządzeniem poprzez komendy wysyłane do tematu MQTT (np. Publish <device_topic>/cmnd/WebPassword 0). Pozbawiamy się tym samym możliwości np. resetu hasła na urządzeniu, czy zdalnie wysłania aktualizacji firmware-u. Aczkolwiek, również potencjalny atakujący zostaje pozbawiony tych możliwości. Kluczowe przy obu rozwiązaniach monitoringu danych z urządzeń - są bakupy konfiguracji i przechowywanie haseł w bezpiecznym miejscu. Albowiem, jeśli hasło zostanie “zapomniane” to czeka nas twardy update firmware-u przez USB-UART i WebInstaller, bo przecież nie zalogujemy się do urządzenia by wykonać zmianę hasła, którego nie pamiętamy. Prócz tego, wciąż potrzebujemy udostępnienia trzech usług z naszej sieci - nazwanej umownie “Labem”: Syslog, DNS i NTP.
Ponad to, autorzy Tasmoty w dokumentacji publikują konkretne zalecenia i przykłady możliwości zabezpieczeń urządzeń przed atakami.
Nasz Firmware
Możliwość łatwej “kastomizacji” firmware-u jest zapewniona, poprzez przegląd my_user_config.h i edycję pliku user_config_override.h gdzie wpisujemy te definicje z my_user_config.h które zapewnią wymaganą konfigurację firmware. Konfiguracja user_config_override.h nadpisuje ustawienia z my_user_config.h Zalecenia i podpowiedzi w kwestii kompilacji również są opublikowane w dokumentacji. Dobrze mieć wolne urządzenie do testów rezultatów naszych kompilacji by mieć pewność, że założone cele zostały zrealizowane. No to ściągamy kod źródłowy. Należy też mieć świadomość różnic między ESP8266/8285 a ESP32. Główna jest taka, że ten pierwszy ma 1MB RAM, a ten drugi 4MB. Dlatego to co jest dobre dla ESP32 może nie być możliwe dla ESP8266. Moje Gosund-y SP111 to ESP8285 właśnie. Przy przeglądaniu kodu Tasmoty, warto wyłączyć plugin VSC “Intellisense C/C++” będzie pyszczył o konwersję plików .ino do .cpp. Biorąc pod uwagę przyjętą strategię, że użytkownik urządzenia NIE będzie miał uprawnień administratora, możemy tam zdefiniować wszystkie niezbędne parametry do połączenia z Wifi, ustawienia NTP, MQTT, MQTT z TLSem, serwera Web, a nawe IPv6 czy TLS dla komunikacji z chmurą AWS lub Azure. Jest tam mnóstwo innych ustawień, pod konkretne sensory. Więc, jeśli czymś nie jesteśmy zainteresowani, bo nasze urządzenie po prostu tego nie robi, można spróbować wyłaczyć i dzieki temu uzyskać mniejszą objętość firmware-u.
Rozwiązanie techniczne z konfiguracją brokera, Telegrafa i InfluxDB przedstawię w ostatnim odcinku. Temat z metrykami dla Prometheusa jest wciąż testowany.