Jest taki moment w życiu każdego, kto lubi rozkręcać rzeczy, w którym przestaje wystarczać pytanie "jak to działa" i pojawia się pytanie "co się stanie, jeśli tego użyję inaczej, niż zaplanowano".
U mnie ta pierwsza część, czyli zwykła ciekawość elektroniki, była wcześniej niż jakakolwiek myśl o bezpieczeństwie. Chciałem po prostu wiedzieć, co siedzi w środku urządzeń.
Zanim pojawiło się słowo "pentest"
Elektronika interesowała mnie na długo przed tym, zanim zacząłem pracować zawodowo w bezpieczeństwie. Nie w sposób usystematyzowany, raczej właśnie tak, jak to zwykle wygląda na początku: rozebrać, obejrzeć, spróbować zrozumieć, po co jest ten konkretny układ i dlaczego akurat tutaj.
Równolegle uczyłem się programować, między innymi na CS50x, gdzie sporo pisze się w C. I to okazało się nie przypadkiem, tylko jedną z najlepszych rzeczy, jakie mogły mi się przydarzyć przed wejściem w embedded.
C uczy trzech rzeczy, które w świecie urządzeń są bezcenne. Po pierwsze, że pamięć to po prostu obszar bajtów, a nie magiczna abstrakcja. Po drugie, że wskaźnik może pokazywać gdziekolwiek, również tam, gdzie nie powinien. Po trzecie, że to programista odpowiada za granice, bo nikt inny tego za niego nie zrobi. Kiedy potem patrzysz na firmware urządzenia, które kosztuje sto złotych i ma dwieście kilobajtów pamięci, ta perspektywa jest dokładnie tą właściwą.
RFID, czyli pierwszy raz, gdy zobaczyłem, jak wygląda "bezpieczne" w praktyce
Po dołączeniu do Boscha trafiłem na tematy, o których wcześniej wiedziałem tyle, co przeciętny czytelnik prasy technicznej. Jednym z nich było testowanie bezpieczeństwa kart zbliżeniowych. Koledzy z dłuższym stażem pokazywali rzeczy, które robią wrażenie przede wszystkim tym, jak bardzo są proste.
Najlepszą ilustracją tego tematu jest historia z naszego podwórka, czyli Warszawska Karta Miejska.
Karta działała w standardzie MIFARE Classic, opartym na autorskim szyfrze Crypto1, projektowanym jako rozwiązanie tajne. To jest właśnie ten klasyczny błąd, przed którym kryptografia ostrzega od czasów Kerckhoffsa: bezpieczeństwo nie może opierać się na tym, że nikt nie zna algorytmu. W 2008 roku badacze złamali Crypto1, odzyskując 48-bitowy klucz. Rok później kolejny zespół pokazał ataki wymagające jedynie możliwości nawiązania komunikacji z kartą, między innymi dlatego, że generator liczb losowych okazał się zależny od czasu, jaki upłynął od uruchomienia układu.
Praktyczne konsekwencje w Warszawie ciągnęły się latami. Proceder nielegalnych doładowań rozwinął się mniej więcej od połowy 2011 roku, a ZTM w pewnym momencie zakwestionował bilety około dziesięciu tysięcy osób, czym zajęła się prokuratura. Do wgrania fałszywego kontraktu wystarczał telefon z NFC i odpowiednia aplikacja, a takie bilety były nie do odróżnienia podczas zwykłej kontroli.
Dla porządku i bez owijania w bawełnę: to było przestępstwo i ludzie za to odpowiadali. Nie o gloryfikację tu chodzi.
Chodzi o wniosek, który wtedy do mnie dotarł i który później potwierdzał się w każdym kolejnym projekcie. Luka była publicznie znana przez kilka lat, zanim ktokolwiek ją realnie wykorzystał na skalę. Wiedza istniała, publikacje istniały, a system dalej działał na złamanym szyfrze, bo wymiana infrastruktury kosztuje, a dopóki nikt nie kradnie, problem jest teoretyczny.
To jest w bezpieczeństwie IoT reguła, a nie wyjątek. Rzadko przegrywamy dlatego, że przeciwnik jest genialny. Znacznie częściej dlatego, że koszt naprawy pojawia się dziś, a koszt zaniechania dopiero za trzy lata.
Warto tu też zaznaczyć różnicę techniczną: nowsze rodziny kart, jak MIFARE DESFire, korzystają z jawnych, standardowych algorytmów. To nie jest kwestia mody, tylko dokładnie ta lekcja wyciągnięta na poziomie projektowym.
Bosch, czyli pentesty na zlecenie
W Boschu pracowałem w dziale wykonującym testy bezpieczeństwa na zlecenie klientów zewnętrznych. To o tyle wygodna sytuacja, że informacja o istnieniu takiej usługi jest publiczna, więc mogę o niej pisać, zachowując przy tym oczywistą zasadę: nie nazywam klientów ani nie opisuję konkretnych znalezisk w konkretnych produktach.
Mogę natomiast opisać kategorie sprzętu, który przechodził przez nasze ręce, bo to samo w sobie jest ciekawe. Roboty sprzątające. Okapy kuchenne z łącznością bezprzewodową. Mikrofalówki. Piekarnik. Ogólnie: rzeczy, które jeszcze dekadę temu nie miały prawa mieć adresu IP, a dziś mają aplikację mobilną, moduł Wi-Fi i BLE.
I to jest dokładnie ten moment, w którym temat robi się poważny. Nie dlatego, że ktoś przejmie Twoją mikrofalówkę. Dlatego, że ta mikrofalówka siedzi w tej samej sieci domowej co Twój laptop, ma stałe połączenie z chmurą producenta i została zaprojektowana przez zespół, którego głównym problemem inżynierskim było równomierne podgrzewanie jedzenia.
Jak w praktyce wygląda test urządzenia IoT
Bez wchodzenia w szczegóły projektów, sam schemat pracy jest wart opisania, bo dla osób przychodzących z pentestów webowych bywa zaskakujący. Powierzchnia ataku rozkłada się na kilka warstw i każda z nich to praktycznie osobna specjalizacja.
Warstwa fizyczna i sprzętowa. Otwarcie obudowy, identyfikacja układów, znalezienie interfejsów serwisowych, dostęp do pamięci. Tu przydaje się lutownica i cierpliwość.
Firmware. Pozyskanie obrazu, rozpakowanie, analiza systemu plików, szukanie zaszytych poświadczeń, kluczy, zapomnianych narzędzi diagnostycznych i binarek, których nikt nie usunął z wersji produkcyjnej.
Komunikacja bezprzewodowa. Wi-Fi, BLE, czasem protokoły własne. Interesujące pytania brzmią: czy transmisja jest szyfrowana, czy urządzenie weryfikuje, z kim rozmawia, i czy parowanie da się przeprowadzić komuś, kto nie powinien mieć takiej możliwości.
Aplikacja mobilna i chmura. To ta część, w której świat IoT wraca do klasycznego bezpieczeństwa aplikacji i API. I często właśnie tu leżą najpoważniejsze problemy, bo błąd w API chmury dotyczy od razu wszystkich egzemplarzy urządzenia na świecie, a nie jednego, który akurat masz na biurku.
Aktualizacje. Czy istnieją, czy są podpisane, czy podpis jest weryfikowany, i czy da się wgrać wersję starszą, w której naprawiona luka jeszcze była obecna.
Każda z tych warstw to osobny nakład pracy, dlatego test urządzenia wypada drożej niż test aplikacji. Rozpisałem to w tekście ile kosztuje pentest, a to, co warto przygotować przed przekazaniem egzemplarza, w tekście jak przygotować się do pentestu.
Znaleziska, które powtarzały się najczęściej
Tu opiszę klasy problemów, a nie konkretne przypadki, bo klasy są znacznie ciekawsze. Konkret jest własnością klienta i przemija razem z poprawką, natomiast wzorzec zostaje.
Otwarty UART. Interfejs szeregowy, używany podczas rozwoju do podglądu logów i dostępu do konsoli, potrafi zostać w wersji produkcyjnej całkowicie bez zabezpieczeń. Podłączasz się do padów na płytce i dostajesz to, co widział programista podczas debugowania, czasem razem z powłoką. To jest jeden z najczęstszych i najbardziej banalnych problemów w całym IoT.
Materiał kluczowy tam, gdzie nie powinno go być. Klucze i inne wrażliwe wartości bywają trzymane w sposób, który pozwala je odczytać, na przykład przez to, że sekwencja przygotowania danych zostawia je w pamięci w postaci jawnej, albo że są zapisane wprost w obrazie firmware'u. Ten sam klucz w każdym egzemplarzu produktu jest zresztą osobną klasyką: złamanie jednego urządzenia daje wtedy dostęp do całej serii.
Brak weryfikacji drugiej strony. Urządzenie ufa temu, kto się z nim połączy, bo w modelu zagrożeń przyjętym przez producenta połączyć się może wyłącznie legalna aplikacja użytkownika.
Zapomniana funkcjonalność deweloperska. Tryby serwisowe, ukryte polecenia, narzędzia diagnostyczne. Nikt ich nie usunął, bo nikt nie prowadził listy tego, co miało zniknąć przed wypuszczeniem produktu.
Wspólny mianownik jest zawsze ten sam i jest nim model zagrożeń. Te urządzenia projektowano przy założeniu, że użytkownik jest życzliwy, sieć domowa jest bezpieczna, a nikt nie będzie odkręcał obudowy. Każde z tych założeń jest fałszywe, a zwłaszcza ostatnie.
Lutownica, czyli po co komu hardware
Sporą część czasu spędziłem z lutownicą w ręku i uważam to za jedną z najlepiej zainwestowanych rzeczy w tym okresie.
Powód jest prosty. Bardzo dużo zabezpieczeń w IoT zakłada, że atakujący pozostaje po stronie oprogramowania. Gdy tylko wychodzisz poza to założenie i dostajesz się bezpośrednio do płytki, do pamięci, do interfejsów serwisowych, to spora część tej ochrony przestaje mieć znaczenie. A urządzenia domowe mają tę właściwość, że napastnik ma do nich fizyczny dostęp z definicji. Kupuje sobie egzemplarz w sklepie.
Dodatkowo umiejętności hardware'owe otwierają drogę do wszystkiego innego. Nie zdobędziesz firmware'u, jeśli nie umiesz go wyciągnąć z układu. A bez firmware'u zostajesz z testowaniem czarnej skrzynki, co jest znacznie mniej efektywne.
Piórnik, czyli jak niepostrzeżenie zbiera się własny warsztat
Nikt tego nie planuje. Zaczyna się od jednej przejściówki USB na UART kupionej pod konkretne zadanie, a kończy tak, że masz organizer na kable, w którym każda gumka trzyma coś innego, i pamiętasz, po co jest każdy element.
W moim siedzi mniej więcej to:
- Programator pamięci flash z klipsem SOIC. Podstawowe narzędzie do zrzucania firmware'u bezpośrednio z układu, bez wylutowywania go z płytki. Bardzo często to jest właśnie ten moment, w którym test przestaje być czarną skrzynką.
- Dwie przejściówki USB na UART. Dwie, bo pierwsza zawsze jest gdzieś zapodziana, a poza tym różne układy lubią różne poziomy napięć i przydaje się mieć wybór.
- Ośmiokanałowy analizator stanów logicznych, 24 MHz. Kosztuje tyle co obiad, a rozwiązuje problem, którego inaczej nie da się rozwiązać: co właściwie leci po tych ścieżkach i jaki to protokół.
- Multimetr z kompletem sond. Zanim cokolwiek podłączysz, warto wiedzieć, gdzie jest masa i jakie napięcie ma linia, którą chcesz dotknąć. Pominięcie tego kroku bywa kosztowne.
- Karta Wi-Fi zewnętrznego producenta. Do wszystkiego, co dzieje się w powietrzu.
- Przewody połączeniowe, pęsety, drobne moduły radiowe, pendrive'y, miernik USB. Rzeczy, których zawsze brakuje w najmniej odpowiednim momencie.
Ciekawe jest to, jak niedrogi jest w sumie ten zestaw. Praktycznie wszystko, co widać na zdjęciach, mieści się w budżecie porównywalnym z jednym przyzwoitym monitorem. To jest bardzo istotna informacja dla każdego, kto myśli, że hardware hacking wymaga laboratorium. Nie wymaga. Wymaga cierpliwości i chęci przeczytania dokumentacji układu.
Jest też różnica w stosunku do świata korporacyjnego, o której pisałem wcześniej. Sprzęt do testów motoryzacyjnych jest tak drogi, że w praktyce dostępny wyłącznie przez pracodawcę. Tutaj bariera jest niska na tyle, że każdy może zacząć w weekend.
I jeszcze jedno spostrzeżenie, tym razem lżejsze. Za każdym razem, gdy pakuję się na lotnisko, patrzę na ten organizer i myślę, że to jest przedmiot, którego nie chciałbym tłumaczyć w kolejce do kontroli bezpieczeństwa. Zestaw kabli, płytek, klipsów i czegoś podpisanego "logic analyzer", zapakowany w kostkę wielkości portfela.
Praktyczna rada, całkiem serio: bagaż podręczny, nie rejestrowany, i spokojne wytłumaczenie, że to sprzęt do pracy. To narzędzia diagnostyczne, całkowicie legalne, kupowane w normalnych sklepach z elektroniką. Ale jeśli lecisz na konferencję z warsztatem hardware'owym, warto założyć, że ktoś może chcieć zajrzeć do środka, i po prostu być na to przygotowanym.
Na razie zawsze obeszło się bez rozmowy. Kwestia czasu.
Na czyich barkach się stoi
Uczciwie trzeba powiedzieć, że w tej dziedzinie ogromną część wiedzy zawdzięcza się publicznym badaniom pojedynczych osób.
W kontekście robotów sprzątających absolutnie kluczową postacią jest Dennis Giese, prowadzący stronę dontvacuum.me. Zajmuje się bezpieczeństwem i prywatnością urządzeń wbudowanych, ma na koncie wystąpienia na Chaos Communication Congress, DEF CON, HITCON i innych konferencjach, a jego kolekcja robotów obejmuje kilkadziesiąt modeli różnych producentów. Zakres jego pracy to między innymi analiza pamięci flash, uzyskiwanie roota bez rozbierania urządzenia i uwalnianie sprzętu spod kontroli chmury producenta.
Jego materiały były dla nas realną pomocą warsztatową. Kiedy wiesz, jakie klasy problemów ktoś już opisał w tej kategorii produktów, to zamiast zaczynać od zera, zaczynasz od pytania, czy ten konkretny egzemplarz również je ma.
Warto też zwrócić uwagę na jego argumentację, bo wykracza poza czystą technikę. Robot sprzątający to urządzenie z kamerą, mikrofonem i pełną mapą Twojego mieszkania, wysyłające dane do chmury. Pytanie o to, kto ma nad tym kontrolę, jest równie ważne jak pytanie o to, czy da się to zrootować.
Materiały: dontvacuum.me, a także prezentacje z DEF CON i CCC dostępne publicznie.
Dziś: bezpieczeństwo telewizorów
Obecnie w Xperi zajmuję się bezpieczeństwem smart TV, gdzie moim zadaniem jest dbanie o to, żeby użytkownik końcowy był bezpieczny.
To ciekawa kontynuacja tej samej ścieżki, bo telewizor jest w istocie kompletnym urządzeniem obliczeniowym udającym mebel. Stały dostęp do sieci, sklep z aplikacjami, konta użytkowników, dane o tym, co i kiedy oglądasz, w wielu modelach mikrofon, coraz częściej kamera, a do tego cykl życia produktu liczony w latach, znacznie dłuższy niż w telefonach.
Ten ostatni punkt jest z perspektywy bezpieczeństwa najtrudniejszy. Telefon wymienia się co kilka lat. Telewizor stoi w salonie dekadę i przez cały ten czas ktoś musi dostarczać poprawki na komponenty, których producenci dawno przestali wspierać.
Zmienia się też charakter pracy w porównaniu z pentestami na zlecenie. Tam wchodzisz na projekt, znajdujesz, raportujesz i idziesz dalej. Tutaj jesteś po stronie produktu przez cały jego cykl życia, więc liczy się nie tylko znalezienie problemu, ale też to, żeby cała jego klasa nie wróciła w kolejnej wersji.
Smart home, czyli wszystko naraz w jednym mieszkaniu
Telewizor to jedno urządzenie. Ciekawiej robi się tam, gdzie takich urządzeń jest dwadzieścia i pochodzą od piętnastu producentów: zamek, kamera, odkurzacz, termostat, czujniki otwarcia, gniazdka, asystent głosowy. Każde z nich z osobna bywa zabezpieczone przyzwoicie. Problem zaczyna się od tego, że stoją w jednej sieci, logują się do kilku chmur naraz i spina je aplikacja, która musi umieć rozmawiać z każdym z nich.
Dlatego w domowym ekosystemie najciekawsze rzeczy rzadko siedzą w samym urządzeniu. Siedzą pomiędzy: w procedurze parowania, w tym, co widzi gość podłączony do tej samej sieci, w kopii danych trzymanej po stronie producenta i w tym, co zostaje w środku po odsprzedaniu sprzętu na giełdzie.
To temat, o którym opowiadam na prelekcjach pod tytułem "Szpiedzy w Twoim domu", i temat na osobny tekst, bo w tym już się nie mieści.
Smart home: co naprawdę widzi Twój dom. Osobny artykuł o tym, jak wygląda test domowego ekosystemu i które z tych urządzeń zasługują na własną sieć. Wkrótce.
Dlaczego IoT jest w takim stanie
Kilka obserwacji, które zebrałem po drodze.
Bezpieczeństwo przegrywa z terminem i marżą. Przy urządzeniu, które ma kosztować dwieście złotych i trafić do sklepów przed sezonem, każda dodatkowa godzina pracy i każdy dodatkowy układ scalony to realny koszt policzalny w arkuszu.
Kompetencje są rozproszone. Zespół potrafiący doskonale zaprojektować sterowanie silnikiem niekoniecznie ma doświadczenie w kryptografii, a firma zamawiająca produkt u zewnętrznego dostawcy często nie ma jak zweryfikować, co dostała.
Łańcuch dostaw jest długi i nieprzejrzysty. Moduł Wi-Fi od jednego producenta, system od drugiego, aplikacja od zewnętrznej agencji, chmura od jeszcze kogoś innego. Podatność w takim module dotyczy wtedy dziesiątek marek, które nawet nie wiedzą, że mają wspólny problem.
Aktualizacje bywają fikcją. Urządzenie potrafi mieć mechanizm aktualizacji, który nikt nigdy nie użyje, bo producent zdążył w międzyczasie zamknąć linię produktową.
Dobra wiadomość jest taka, że to się zmienia, i to głównie pod presją regulacyjną. Unijne rozporządzenie o cyberodporności, czyli Cyber Resilience Act, nakłada na producentów produktów z elementami cyfrowymi wymagania dotyczące bezpieczeństwa i obsługi podatności w całym cyklu życia. W Wielkiej Brytanii obowiązuje ustawa PSTI, która zakazuje między innymi domyślnych, uniwersalnych haseł. Istnieje też norma ETSI EN 303 645, opisująca podstawowe wymagania dla konsumenckiego IoT.
Innymi słowy, argument "to tylko czajnik" powoli przestaje być akceptowaną odpowiedzią.
Czy konkretny produkt podlega CRA, rozstrzyga test w pięciu pytaniach, a obowiązki producenta rozpisałem w tekście co CRA wymaga od producenta.
Na koniec
Patrząc wstecz, cała ta ścieżka jest zaskakująco spójna. Zaczęło się od rozkręcania rzeczy z ciekawości. Potem doszło C i zrozumienie, że pamięć to bajty, którymi ktoś musi zarządzać. Potem karty zbliżeniowe i lekcja, że złamany algorytm potrafi żyć w produkcji latami po publikacji. Potem urządzenia domowe, lutownica i odkrycie, jak wiele zabezpieczeń rozpada się w momencie otwarcia obudowy. Dziś telewizory i pytanie, jak utrzymać to wszystko w ryzach przez dziesięć lat.
Cały czas to samo pytanie, tylko na coraz większych urządzeniach: co się stanie, jeśli użyję tego inaczej, niż zaplanowano?
Nadal nie znam ciekawszego.
Testy urządzeń IoT i systemów wbudowanych, od sprzętu po proces aktualizacji, opisałem w sekcji usług. Jeśli masz produkt, który ma przez to przejść, napisz.
Materiały
- dontvacuum.me, badania Dennisa Giesego nad robotami i urządzeniami IoT
- OWASP IoT Top 10, dobry punkt startowy dla klasyfikacji problemów
- ETSI EN 303 645, wymagania bazowe dla konsumenckiego IoT
- Cyber Resilience Act oraz brytyjska ustawa PSTI
- Publikacje o podatnościach MIFARE Classic i szyfrze Crypto1