Kiedy zaczynałem przygodę z pentestami, mapa świata wyglądała dość prosto. Były testy infrastruktury i były testy aplikacji webowych. Ewentualnie mobile. To wydawało się całością dostępnego terenu, więc tam właśnie szedłem: bug bounty, mniejsze zlecenia, kolejne raporty, kolejne podatności w aplikacjach.
Potem trafiłem do Boscha i okazało się, że mapa była niekompletna.
Odkrycie, że istnieje coś takiego
Automotive cyber security to dziedzina, o której w typowej ścieżce pentesterskiej po prostu się nie słyszy. Nie ma jej w popularnych kursach, rzadko pojawia się na konferencjach dla webowców, prawie nie ma programów bug bounty, do których można wejść z ulicy. A jednak jest to pełnoprawny, gigantyczny obszar bezpieczeństwa, tylko schowany za barierą wejścia w postaci sprzętu i wiedzy dziedzinowej.
Trafienie do firmy, która siedzi w samym środku tego ekosystemu, było czymś w rodzaju wejścia bocznymi drzwiami.
Warto tu oddać sprawiedliwość historii, bo to nie jest przypadkowe miejsce. CAN, czyli Controller Area Network, opracował właśnie Bosch i wypuścił go w 1986 roku. To magistrala, która do dziś stanowi kręgosłup komunikacji w praktycznie każdym samochodzie na świecie. Przy FlexRayu sprawa wygląda nieco inaczej, niż się często powtarza: konsorcjum założyły w 2000 roku BMW i DaimlerChrysler razem z Motorolą i Philipsem, a Bosch dołączył rok później jako jeden z członków rdzeniowych i wniósł do projektu doświadczenie z CAN-a i TTCAN-a. Konsorcjum rozwiązało się w 2009 roku, przekazując specyfikację do ISO, gdzie żyje dziś jako seria norm ISO 17458.
Nie piszę tego dla porządku bibliograficznego. Piszę, bo praca w miejscu, gdzie te protokoły powstawały, zmienia perspektywę. Nagle CAN przestaje być abstrakcyjnym diagramem z prezentacji, a staje się czymś, czego działanie ktoś obok Ciebie zna od strony decyzji projektowych sprzed czterdziestu lat.
Czym to się różni od pentestu webowego
To była dla mnie najciekawsza część przesiadki, więc rozpiszę ją porządnie.
Nie ma warstwy uwierzytelnienia tam, gdzie się jej spodziewasz. Klasyczna magistrala CAN to broadcast. Każdy węzeł widzi wszystko, co leci po szynie, i historycznie nie było w niej wbudowanego mechanizmu potwierdzania, kto właściwie nadał daną ramkę. Protokół projektowano w czasach, gdy model zagrożeń zakładał, że wszystko podłączone do szyny jest z definicji zaufane. Cała nowoczesna warstwa bezpieczeństwa, jak choćby mechanizmy uwierzytelniania ramek, została dobudowana później, na fundamencie, który tego nie przewidywał.
Skutki są fizyczne. To brzmi banalnie, dopóki się tego nie zobaczy. W aplikacji webowej najgorsze, co się dzieje, to wyciek danych albo przejęcie konta. Tutaj wysyłasz komunikat i element mechaniczny się rusza. Pamiętam moment, gdy po raz pierwszy wydałem polecenie bezpośrednio do sterownika i zobaczyłem realną reakcję fizyczną po drugiej stronie. To zupełnie zmienia stosunek do tego, co się robi. Nie ma przycisku "cofnij", a błąd może oznaczać uszkodzony sprzęt wart bardzo dużo pieniędzy.
Feedback loop jest wolny i drogi. W webie masz Burpa, przeglądasz sto żądań na minutę i natychmiast widzisz odpowiedź. Tutaj potrzebujesz interfejsu do magistrali, poprawnego opisu sieci, ułożonego stanowiska, czasem całego pojazdu, a każdy cykl testowy trwa. Sprzęt klasy Vector, na którym pracowałem, to narzędzia bardzo zaawansowane i bardzo kosztowne, całkowicie poza zasięgiem osoby dłubiącej po godzinach w domu. To zresztą jeden z głównych powodów, dla których ta dziedzina jest tak słabo obsadzona.
Dokumentacja jest zamknięta. W webie masz RFC, MDN i OWASP. Tutaj kluczowe opisy sieci i mapowania sygnałów są własnością producenta i objęte umowami. Bez nich zostaje Ci obserwacja ruchu i wnioskowanie, czyli reverse engineering w najczystszej postaci.
I właśnie ten ostatni punkt okazał się tym, co mnie w tym wszystkim najbardziej wciągnęło.
Warsztat
Bez wchodzenia w szczegóły projektów, bo te są objęte poufnością, zakres kompetencji, który wtedy zbudowałem, wygląda tak:
- Skrypty fuzzujące w CAPL do testowania sterowników ECU, uruchamiane w środowisku Vector. To był główny obszar mojej pracy i jednocześnie najciekawszy.
- Praca na magistralach CAN i FlexRay, w tym analiza ruchu i komunikacja z jednostkami sterującymi na stanowiskach testowych.
- Testy sterowników ECU, czyli weryfikacja, jak jednostka zachowuje się w sytuacjach, których projektant niekoniecznie przewidział.
- Reverse engineering ruchu na magistrali, czyli odtwarzanie znaczenia sygnałów bez dostępu do oficjalnego opisu sieci.
O fuzzingu w CAPL słów kilka
CAPL to język specyficzny dla środowiska Vectora, mocno zdarzeniowy, zaprojektowany wokół obsługi zdarzeń na magistrali. Dobrze pasuje do opisywania scenariuszy typu "wyślij sekwencję, poczekaj na warunek, sprawdź reakcję", a przy odrobinie pracy również do budowania generatorów wejść testowych.
Fuzzing sterownika jest pojęciowo tym samym, co fuzzing dowolnego innego oprogramowania: podajesz na wejście dane odbiegające od tego, czego implementacja się spodziewa, i obserwujesz, czy zachowuje się poprawnie. Różnice tkwią w szczegółach i to one czynią temat ciekawym.
Wyrocznia jest problemem. W klasycznym fuzzingu masz sanitizery i sygnał w postaci crasha procesu. Tutaj sterownik jest czarną skrzynką po drugiej stronie magistrali, więc trzeba zbudować własną definicję tego, co znaczy "coś poszło nie tak": brak odpowiedzi, odpowiedź niezgodna ze specyfikacją, przejście w tryb awaryjny, reset, zmiana zachowania obserwowalna dopiero na wyjściach fizycznych.
Przepustowość jest ograniczona przez fizykę. Magistrala ma swoją prędkość, sterownik swoje czasy odpowiedzi, a po nieudanej iteracji często trzeba doprowadzić urządzenie do znanego stanu początkowego. Liczba przypadków testowych na sekundę jest o rzędy wielkości niższa niż przy fuzzingu biblioteki na maszynie deweloperskiej, więc jakość generatora liczy się nieporównywalnie bardziej niż jego szybkość. Ślepe losowanie bajtów zwyczajnie się nie opłaca.
Stan ma znaczenie. Sterownik żyje w maszynie stanów: sesje diagnostyczne, poziomy dostępu, warunki zależne od tego, czy pojazd stoi, czy jedzie. Ciekawe zachowania siedzą zwykle nie w pojedynczej wiadomości, tylko w sekwencji, która wprowadza urządzenie w stan, w którym kolejna wiadomość zostaje potraktowana inaczej, niż zakładał projektant. Fuzzer, który nie modeluje stanu, odbija się od pierwszej ściany i nigdy nie wchodzi głębiej.
Reprodukowalność jest obowiązkiem. Znalezisko, którego nie da się powtórzyć, jest bezwartościowe dla zespołu, który ma to naprawić. Logowanie pełnego przebiegu, z zachowaniem kolejności i czasów, jest równie ważne jak sam generator.
Warto dodać, że fuzzing nie jest w tej branży ciekawostką badawczą, tylko elementem normalnego procesu. Norma ISO/SAE 21434 traktuje testy tego typu jako część weryfikacji bezpieczeństwa, więc producenci i dostawcy robią to, bo muszą, a nie dlatego, że ktoś się uparł.
Osobno wymienię reverse engineering ruchu na magistrali, bo to umiejętność, która w mojej ocenie przenosi się najszerzej. Kiedy nauczysz się patrzeć na strumień pozornie przypadkowych bajtów i systematycznie zawężać hipotezy o tym, co znaczą, ta sama metoda działa na protokołach binarnych, formatach plików i firmware'ach.
Projekt, który nauczył mnie najwięcej, bo go nie dokończyliśmy
Teraz historia, którą opowiem w formie ogólnej, i zaraz wyjaśnię dlaczego.
Wpadł mi kiedyś do głowy bardzo konkretny, przyziemny pomysł. W pewnym popularnym SUV-ie istnieje funkcja sygnału dźwiękowego, którą da się dezaktywować z poziomu menu, ale ustawienie nie przeżywa cyklu zapłonu. Po każdym uruchomieniu pojazdu wraca do stanu domyślnego. Klasyczna sytuacja, w której funkcja formalnie istnieje, ale jest bezużyteczna, bo stan nie jest trwały.
Pytanie brzmiało: gdzie w ogóle mieszka ten stan i dlaczego nie jest zapisywany.
Wzięliśmy z bardziej doświadczonym kolegą samochód i zaczęliśmy grzebać. I to był bardzo pouczający projekt, choć nie z tego powodu, z którego się spodziewałem, bo nigdy go nie dokończyliśmy. Zatrzymały nas trzy rzeczy i każda jest warta osobnego akapitu.
Czas. Praca w wolnych oknach między projektami oznacza, że każde wznowienie zaczyna się od odtwarzania kontekstu. Przy analizie, w której cała wartość leży w narastającym zrozumieniu systemu, ta przerywalność zabija tempo.
Ryzyko sprzętowe. To był normalny, używany samochód, a nie stanowisko testowe. Świadomość, że nieostrożna ingerencja może zamurować moduł wart tyle co przyzwoity używany samochód, bardzo skutecznie studzi zapał do agresywnych prób. Ograniczyliśmy się więc do obserwacji, bez ingerencji, i to była dobra decyzja.
Kwestie prawne. I to jest powód, dla którego nie podaję tu marki, modelu ani żadnych szczegółów technicznych. Warunki licencyjne systemu multimedialnego zawierały zakaz inżynierii wstecznej. To jest zobowiązanie umowne, całkiem niezależne od tego, że prawo autorskie w UE przewiduje pewne wyjątki dotyczące analizy oprogramowania w celu zapewnienia interoperacyjności. Do tego funkcje ostrzegania kierowcy bywają w części jurysdykcji objęte wymogami homologacyjnymi, więc publikowanie instrukcji ich trwałego wyłączania jest problematyczne z zupełnie innej strony.
Podsumowując: sam fakt, że coś jest technicznie ciekawe i że to Twój samochód, nie znaczy automatycznie, że możesz o tym opublikować pełny opis. To rozróżnienie warto sobie przyswoić wcześnie, najlepiej zanim napisze się posta.
Zostały mi z tego dwa wnioski. Pierwszy techniczny: bardzo dużo pozornie irracjonalnych zachowań w samochodzie to nie błędy, tylko konsekwencje projektowe, wynikające z tego, gdzie stan jest przechowywany i kto ma prawo go zapisać. Drugi zawodowy: w tej dziedzinie granica prawna jest częścią warsztatu, dokładnie tak samo jak umiejętność czytania ruchu na magistrali.
Co opowiadam na prelekcjach
Część z tych rzeczy prezentuję na wystąpieniach, bo automotive security ma tę zaletę, że przykłady są sugestywne nawet dla osób spoza branży. Każdy ma jakieś wyobrażenie o samochodzie, więc łatwo pokazać, gdzie to wyobrażenie się rozjeżdża z rzeczywistością.
Kradzieże, czyli ta część, po której ludzie sprawdzają własny podjazd
Urządzenie w obudowie Game Boya. W 2021 roku policja z West Yorkshire zatrzymała trzech mężczyzn, którzy ukradli pięć Mitsubishi Outlanderów o łącznej wartości ponad 180 tysięcy funtów. Narzędzie, którego używali, wyglądało jak Nintendo Game Boy, kompletnie z podrobioną obudową Supreme, a jego wartość oszacowano na około 20 tysięcy funtów. Otwierało i uruchamiało samochód w kilkadziesiąt sekund. Według późniejszych doniesień elektronika pochodziła od zewnętrznego dostawcy i została przepakowana do obudowy konsoli.
To jest mój ulubiony slajd, bo obala dwa mity naraz. Po pierwsze, że takie ataki wymagają laboratorium, skoro mieszczą się w kieszeni. Po drugie, że to działalność geniuszy, skoro sprawcy najzwyczajniej kupili gotowe urządzenie i nagrali sobie film z akcji telefonem.
CAN injection, czyli walizka i reflektor. Historia jeszcze lepsza, bo to prawdziwa robota detektywistyczna. Ianowi Taborowi ktoś dwukrotnie rozgrzebał reflektor w jego Toyocie RAV4, co wyglądało na bezsensowny wandalizm. Trzy miesiące później samochód zniknął. Tabor razem z Kenem Tindellem z Canis Automotive Labs prześledzili kody diagnostyczne i odtworzyli metodę, którą nazwali CAN injection. Dostała ona numer CVE-2023-29389.
Sedno jest takie: reflektor jest dziś sterownikiem, a nie żarówką z przełącznikiem, więc siedzi na tej samej magistrali co moduł inteligentnego kluczyka. Złodziej nie musi docierać do modułu kluczyka, wystarczy, że dostanie się do dowolnego punktu tej samej szyny, a reflektor jest po prostu najwygodniejszym punktem, bo jest za zderzakiem. Potem urządzenie podszywa się pod komunikaty modułu kluczyka. Sprzęt bywał ukrywany w obudowie głośnika Bluetooth i sprzedawany jako "awaryjny starter", w cenach rzędu kilku tysięcy euro przy koszcie części liczonym w dolarach.
I tu pada zdanie, dla którego robię ten slajd: to nie jest wada jednego producenta. To jest konsekwencja tego, że CAN zaprojektowano jako sieć, w której wszystko podłączone do szyny jest zaufane z definicji. Tindell wskazywał, że doraźnie da się to łagodzić aktualizacją oprogramowania, natomiast prawdziwym rozwiązaniem jest podejście zero trust do magistrali, czyli kryptograficzne uwierzytelnianie komunikatów.
Tesla Model X i pilot. Zespół COSIC z KU Leuven pokazał w 2020 roku, jak w kilka minut otworzyć i odjechać Modelem X, wykorzystując słabości w systemie kluczyka. Tesla załatała to aktualizacją w wersji 2020.48. Ten przykład dokładam, bo pokazuje, że problem nie dotyczy wyłącznie starszych konstrukcji, a przy okazji ilustruje, jak dużą przewagę daje możliwość wysłania poprawki bezprzewodowo do całej floty.
Materiał wideo od badaczy: youtube.com/watch?v=clrNuBb3myE
Jeep na autostradzie, czyli moment, w którym branża spoważniała
Bez tego przykładu nie da się o tym opowiadać. W 2015 roku Charlie Miller i Chris Valasek zdalnie przejęli kontrolę nad Jeepem Cherokee jadącym autostradą, z dziennikarzem Wireda za kierownicą, wchodząc przez system multimedialny i docierając stamtąd do funkcji sterujących pojazdem. Skutkiem była akcja serwisowa obejmująca około 1,4 miliona pojazdów.
To wydarzenie zrobiło dla automotive security to, co Morris worm zrobił dla bezpieczeństwa sieci. Pokazało, że sprawa nie jest teoretyczna, i uruchomiło łańcuch, który skończył się regulacjami.
Materiał: youtube.com/watch?v=MK0SrxBC1xs, opis w Wired: wired.com/2015/07/hackers-remotely-kill-jeep-highway
Eksperyment myślowy, na którym sala milknie
Jedziesz niemiecką autostradą, odcinkiem bez ograniczenia prędkości, 300 kilometrów na godzinę. W tym momencie sterownik podszywający się pod układ hamulcowy wysyła komunikat o pełnym hamowaniu.
To jest scenariusz hipotetyczny i mówię to wyraźnie ze sceny, bo nie chcę uprawiać taniej sensacji. Ale on nie jest fantastyczny, tylko wynika wprost z kierunku, w którym idzie branża. Steer by wire i brake by wire zastępują połączenie mechaniczne komunikatem w sieci. W momencie, gdy między pedałem a zaciskiem nie ma już fizycznego łącznika, integralność komunikatu przestaje być kwestią komfortu, a staje się kwestią bezpieczeństwa funkcjonalnego w najbardziej dosłownym sensie.
I dlatego cały ten wykład nie jest o kradzieżach samochodów. Kradzież jest stratą majątkową. To jest inna kategoria problemu.
To samo w powietrzu i na wodzie
Ostatni wątek, który zwykle otwiera ludziom oczy: ten sam schemat powtarza się poza motoryzacją.
Lotnictwo. Airbusy latają w architekturze fly by wire, w której wychylenie bocznego drążka to sygnał do komputerów pokładowych, a nie mechaniczne połączenie z powierzchniami sterowymi. Zasada jest wspólna z samochodowym by wire. Natomiast trzeba być uczciwym co do różnic, bo lotnictwo podeszło do tego zupełnie inaczej: inne magistrale, takie jak ARINC 429 czy AFDX, obowiązkowa redundancja, zasada dissimilar design, w której to samo zadanie realizują niezależnie zaprojektowane systemy, oraz osobne normy bezpieczeństwa informatycznego zdatności do lotu, DO-326A i ED-202A. Do tego domena rozrywki pokładowej jest oddzielona od domeny sterowania na poziomie architektury, a nie dobrych chęci. Głośne swego czasu doniesienia o przejęciu samolotu przez system rozrywki nigdy nie zostały potwierdzone i warto to mówić wprost.
Jachty i jednostki pływające. Tutaj analogia jest wręcz dosłowna, bo standard NMEA 2000, używany do komunikacji między przyrządami nawigacyjnymi, autopilotem i silnikami, jest zbudowany na CAN-ie. Ta sama warstwa, te same właściwości, ten sam brak wbudowanego uwierzytelniania. Z tą różnicą, że rynek jachtowy ma znacznie mniejszą presję regulacyjną niż motoryzacja i znacznie mniej badaczy patrzących mu na ręce.
Ta ostatnia obserwacja jest dobrym mostem do kolejnego punktu.
Dlaczego to wciąż jest tak nieprzekopany teren
Automotive security jest wąskie, bo bariery wejścia są realne. Trzeba sprzętu, dostępu do pojazdów albo stanowisk, wiedzy z pogranicza elektroniki, embedded i klasycznego bezpieczeństwa, a do tego cierpliwości do dziedziny, w której jeden cykl testowy trwa dłużej niż cały test aplikacji webowej.
Konsekwencja jest taka, że stosunek liczby badaczy do powierzchni ataku jest tu nieporównywalnie korzystniejszy niż w webie. Współczesny samochód to sieć kilkudziesięciu, a w segmencie premium ponad setki sterowników, z łącznością komórkową, Bluetooth, Wi-Fi, aktualizacjami OTA, aplikacją mobilną, backendem producenta i całym łańcuchem dostawców, z których każdy dorzuca własny kod. To jest powierzchnia ataku wielkości sporego przedsiębiorstwa, tyle że jeżdżąca po drodze.
Do tego dochodzi presja regulacyjna. Regulaminy UNECE R155 i R156 oraz norma ISO/SAE 21434 sprawiły, że producenci muszą mieć udokumentowane procesy zarządzania cyberbezpieczeństwem i aktualizacjami, żeby w ogóle homologować pojazd na wielu rynkach. To przekłada się wprost na popyt na ludzi, którzy potrafią te systemy testować, i to popyt znacznie większy niż podaż.
Producenci urządzeń spoza motoryzacji mają swój odpowiednik tej presji w Cyber Resilience Act, który działa na tej samej zasadzie: brak udokumentowanego procesu oznacza brak rynku. Czy dany produkt mu podlega, rozstrzyga test w pięciu pytaniach.
Innymi słowy: jest to nisza, w której zostało jeszcze bardzo dużo do znalezienia, a chętnych do szukania jest mało. Rzadka kombinacja.
Jak w to wejść bez dostępu do laboratorium
Nie mam zamiaru udawać, że jest to łatwe, ale kilka rzeczy da się zrobić własnym sumptem.
- Naucz się podstaw sieci pokładowych od strony teorii. CAN, CAN FD, LIN, FlexRay, Automotive Ethernet, do tego warstwa diagnostyczna. Zrozumienie, dlaczego arbitraż w CAN wygląda tak, jak wygląda, mówi Ci więcej o możliwych klasach ataków niż jakikolwiek gotowy poradnik.
- Zacznij od symulacji. Linux ma natywny stos SocketCAN z wirtualnymi interfejsami, więc kompletnie bez sprzętu można ćwiczyć narzędzia i pisanie własnych parserów.
- Tani sprzęt istnieje. Interfejsy CAN za kilkadziesiąt złotych i porzucone sterowniki z demontażu, kupione za grosze, pozwalają zbudować własne stanowisko. Sterownik na biurku nie ma jak zrobić nikomu krzywdy, w przeciwieństwie do sterownika w jeżdżącym aucie.
- Nie eksperymentuj na pojeździe, którym się jeździ. Serio. To nie jest przestroga z regulaminu, tylko praktyczna rada dotycząca pieniędzy i bezpieczeństwa.
- Traktuj embedded reverse engineering jako umiejętność bazową. Analiza firmware'u, formatów binarnych i protokołów zwraca się w tej dziedzinie natychmiast.
- Czytaj publikacje branżowe. Środowisko jest małe i sporo wartościowego materiału krąży w prezentacjach konferencyjnych oraz publikacjach akademickich, a nie w blogach.
Otwarty na współpracę
Jeśli szukasz osoby albo zespołu do projektu z obszaru automotive security, czy to analizy bezpieczeństwa funkcji wbudowanych, testów komunikacji na magistralach, czy budowy produktu w tej przestrzeni, to zapraszam do kontaktu. Interesują mnie szczególnie projekty, w których trzeba coś rozgryźć od zera, bez gotowej dokumentacji.
To akurat robię najchętniej.
Zakres testów, które prowadzę, opisałem w sekcji usług. Tematy automotive wyceniam indywidualnie, a nie z widełek dziennych, i wyjaśniam dlaczego w tekście ile kosztuje pentest. Jeśli masz projekt, który trzeba rozgryźć od zera, napisz.
Na koniec
Zaczynałem od aplikacji webowych, bo wydawało mi się, że to jest cały dostępny świat. Okazało się, że istnieje obszar, w którym te same odruchy, czyli podważanie założeń projektanta i sprawdzanie, co system zrobi w sytuacji, której nikt nie przewidział, prowadzą do czegoś, co potem fizycznie się rusza.
I szczerze mówiąc, ta fizyczność jest tu najbardziej uzależniającą częścią. Podatność w aplikacji jest abstrakcją na ekranie. Tutaj sprzężenie między tym, co wysyłasz, a tym, co dzieje się w świecie, jest bezpośrednie i natychmiastowe.
To też, nawiasem mówiąc, najlepszy możliwy argument za tym, żeby robić to odpowiedzialnie.
Materiały warte uwagi
- Standardy: ISO 11898 (CAN), ISO 17458 (FlexRay), ISO 14229 (UDS)
- Regulacje: UNECE R155 i R156, ISO/SAE 21434
- SocketCAN w jądrze Linuksa, do ćwiczeń bez sprzętu
- Publikacje z konferencji poświęconych bezpieczeństwu systemów wbudowanych i motoryzacji