stats

„Implementacje są dziurawe”

Wywiad z pracownikiem telekomu, programistą smartfonów

Grafika

„Mogę opowiedzieć jakim syfem technologicznym są obecne smartfony. […] Wyciek informacji o tym, jak dokładnie działają, mógłby skutkować pojawieniem się publicznie dostępnych exploitów, które uruchomisz na sprzęcie za 200 złotych” – wywiad z pragnącym zachować anonimowość i świadomym zagrożeń programistą smartfonów, w tym apletów dla kart SIM.

Poniższy wywiad opublikowany był pierwotnie w serwisie BAD[SECTOR].PL.

Paweł Wilk: Długo działasz w branży?

W telekomie jestem od niedawna i mam dość rygorystyczną umowę w kwestii ujawniania informacji. Zastrzegam więc, że na pewne kwestie nie udzielę odpowiedzi – albo z braku wystarczającej wiedzy, albo z obawy przed ujawnieniem tożsamości; własnej lub firmy, w której pracuję.

PW: Jak wygląda od kuchni wprowadzanie poprawek do oprogramowania na karcie SIM?

Programowanie apletów na karty SIM nie jest ani przyjemne ani wygodne, a przetestowanie jakiegoś modułu kosztowne. Trzeba mieć drogi serwer do odbierania wiadomości, inny do nadawania, przydatne jest też urządzenie wielkości szklanki, które pracuje jako mostek łączący kartę SIM z aktywnym telefonem – podłączone przez USB po prostu podsłuchuje cały ruch, a mimo małych rozmiarów kosztuje tyle, co trzy auta osobowe średniej klasy.

Aplety testuję najpierw używając kilku emulatorów i/lub maszyn wirtualnych. Są one jednak na tyle niedokładne, że potrafią zgłosić różny wyjątek dla tego samego wejścia, generując za każdym razem inne kody błędów, albo kody, które nie są opisane w żadnej dokumentacji danego modułu. Kiedyś ciągle otrzymywałem numer błędu 221, a dokumentacja kończyła się na #61. Dobrze, gdy moduł „wysypie” się w tym samym miejscu, gorzej, gdy dwa emulatory podadzą różne kody błędów, a trzeci przerwie pracę dwie linijki kodu źródłowego dalej.

Względnie dobrą sytuacją – w porównaniu z innymi – jest ta, gdy coś działa na telefonie z Androidem, a nie działa np. na Nokii 6310, z kolei na urządzeniach Apple’a zwraca różne wartości, zależnie od modelu iPhone’a. Między kolejnymi wersjami iOS-ów były różnice w działaniu komendy refresh, która instruuje telefon, że jakiś plik się zmienił, z kolei między starszymi telefonami a Androidem nie zaobserwowałem w tej kwestii różnic.

PW: W opublikowanym jakiś czas temu komunikacie przypomnieliśmy o usterkach w smartfonach, które pozwalają blokować aparaty i uruchamiać procedury niszczące bez konieczności przełamywania zabezpieczeń głównego systemu operacyjnego (np. Androida, PalmOS-a czy Symbiana) – wystarczy znaleźć słabe punkty w oprogramowaniu tzw. procesora pasma. Czy z punktu widzenia Twojego doświadczenia tak jest naprawdę?

Naprawdę może to wglądać nawet gorzej, niż zostało opisane, ale to musi być konkretny błąd, np. w funkcjonowaniu apletu. O takich błędach wiemy, że są w naszych apletach, ale naprawa ich wymagałaby sprawdzenia kilku warunków, walidacji danych wejściowych, ale jeżeli dana metoda jest wywoływana co 30 sekund, to jest to nieopłacalne. Właśnie taki przypadek mam w aplecie, który dopiero skończyłem pisać. Niepoprawne dane wejściowe mogą usunąć całą listę kontaktów zapisaną na karcie SIM. Tego akurat nie opłaca się naprawiać, bo specyfikacja jest znana tylko kilku osobom, a bufor komunikatów przychodzących ma dość specyficzną strukturę. Dlatego wspomniany w materiale exploit mający 73 bajty mnie nie dziwi. Przy okazji, SMS jest bardzo ograniczony – to teoretycznie 255 bajtowa tablica wyposażona w nagłówek.

PW: Pisaliśmy o wykonywaniu zdalnych operacji włączania mikrofonu i kamer, wykonywaniu dowolnego kodu, niszczeniu telefonu – co może być groźniejsze od tego?

Zależy, co rozumiemy przez „groźniejsze”. Jest dużo rzeczy, o których ludzie nie wiedzą. Mamy tzw. Flash SMS-y, dość popularne i używane np. przy dwuskładnikowym uwierzytelnianiu (ang. two-factor authentication, skr. 2FA), które powodują wyświetlenie małego okienka na ekranie; jest też silent SMS. W przypadku wiadomości błyskawicznie wyświetlanych (Flash SMS) implementacja ich obsługi w Androidzie 2.2 jest niepoprawna – odebranie odblokowuje ekran urządzenia, aktywuje podświetlenie ekranu, a następnie automatycznie blokuje ekran. Z kolei podczas wysyłania silent SMS-a lub Flash SMS-a na pulpicie wyświetla się mały widget z napisem „Sending”.

Inną sprawą jest to, że karty SIM mają też aplety w pamięci RAM, które są zdolne odbierać kod bajtowy, np. innego apletu, a następnie zainstalować go czy usunąć. Ciężko jest coś takiego wykonać w małej firmie, ale światowi operatorzy mają fundusze, technologie i programistów z dużym doświadczeniem, i wiem, że są w stanie przygotować tego typu środowisko w bardzo krótkim czasie.

Oprócz wysłania silent SMS-a można też wykonać tzw. cichą rozmowę (ang. silent call), czyli nawiązać połączenie z wybranym numerem, gdy telefon jest w stanie spoczynku, a mikrofon nie jest wyłączony. Można przesłać aplet, który po uruchomieniu się automatycznie zadzwoni pod podany numer, a po zakończeniu „rozmowy” zostanie usunięty1. Instalowanie takich apletów ułatwi technologia over-the-air (skr. OTA). Jest to rozwiązanie wygodne, szybkie i mniej problematyczne, gdy chodzi o zdalne operowanie na zawartości urządzeń.

PW: Jak zbudowane są karty SIM? Co zawierają?

Karty SIM mają własny system operacyjny, różne rodzaje pamięci (RAM, ROM i EEPROM – każdej używa się w innych sytuacjach), procesor, wyspecjalizowany układ scalony do szyfrowania kluczami prywatnymi z operatorem – i mówimy tu o kartach 2G2. Technologia kart 3G jest bardziej rozbudowana – głównie lepszy procesor, więcej pamięci, lepsze układy szyfrowania. Karty 3G mają inne przeznaczenie, są tworzone z myślą o wysyłaniu MMS-ów, prowadzeniu wideokonferencji i transmisji danych3.

PW: Ok, ale czy komunikat sterujący, który zawiera instrukcje instalacji czegokolwiek, nie musi być cyfrowo podpisany, żeby udowodnić, że pochodzi z zaufanego źródła?

Ruch jest oczywiście szyfrowany przez operatorów, więc takie dane musiałyby zostać wstrzyknięte. Można wykorzystać luki związane z implementacjami uprawnień na kartach SIM.

Innym, prostym przykładem może być wspomniany Flash SMS, którego da się wysyłać zależnie od operatorów i ich konfiguracji. W USA, z tego co wiem, jest to niemożliwe, w Japonii tylko operator i rząd tego używa – do ostrzeżeń przed kataklizmami. Telefon może odpowiedzieć każdemu na taką wiadomość. Mając czyjś numer, możesz np. wysłać „pinga” ze „zrootowanego” Androida, żeby sprawdzić, czy jego lub jej telefon jest online. Więcej informacji na ten temat:

W iOS-ie też można wysyłać Flash SMS-y, zaczynając wiadomość od !; np. !badsector wyśle Flash SMS-a o treści bacsector.

PW: Jaki Twoim zdaniem jest wpływ przyjętego modelu rozwoju oprogramowania na poziom zabezpieczeń?

Mogę opowiedzieć jakim syfem technologicznym są obecne smartfony. Implementacje są dziurawe, a ich kody pilnie strzeżone. Wyciek informacji o tym, jak dokładnie działają, mógłby skutkować pojawieniem się publicznie dostępnych exploitów, które uruchomisz na sprzęcie za 200 złotych.

PW: Co mogę kupić za 200 złotych?

Raczej nie kupić, a zbudować. Chodzi o mini-stacje do podsłuchiwania GSM4.

PW: Czy przepływ informacji między producentami układów, telefonów, a operatorami jest dobry? Czy dokumentacja dla programistów spełnia standardy?

Odpowiem historią z życia. Piszemy sobie jakiś aplet. Nie wiem co zrobić z danym plikiem (karty mają własny system plikowy), więc myślę sobie, że zajrzę do dokumentacji od ETSI… Mam na dysku prawie 2GB plików PDF wygenerowanych z LaTeX-a, wszelkich dokumentacji od 3GPP, ETSI, Nokii, Motorolii… Szukam folderu, dokumentu, rozdziału – po to, żeby odczytać z tabeli jedną wartość, którą mam przesłać do funkcji. W dokumentacji figuruje na przykład liczba 13, ale z doświadczenia już wiem, że nie jest to taka 13, jaką autor miał na myśli. ;)

W Javie zapisuję więc powyższą liczbę jako (byte) 0x13. Potem otwieram inny dokument, pisany przez tych samych autorów, ale już w innym roku, w innym miejscu, na innym spotkaniu. Okazuje się w nim, że tam ustalili, że 13 to jednak będzie (short) 13. Tak wygląda dokumentacja standardów OS na karcie SIM. Gdy takie oficjalne dokumentacje zawodzą, z pomocą przychodzi np. Motorola czy Nokia i ich dokumentacje, które są dobrze wykonane, ale nie są pełne. Raz, że dotyczą tego jednego wymienionego modelu telefonu, a dwa, że udokumentowane jest tylko to, co dany model obsługuje.

Takie dokumentacje telefonów czasami są upubliczniane i po kilkudniowej analizie (nawet przez osoby bez doświadczenia w telekomach) mogą zostać wykorzystane do ataków, co widzieliśmy w Berlinie. Dokumentacja jest taka sobie, ale lepsze to, niż nic.

Z doświadczenia wiem, że gdy brak opisu jakieś flagi dla kart USIM, to przeważnie działa przekazanie null-byte’u, a jakakolwiek inna wartość „crashuje” aplet. Gorsza jest implementacja, bo zastanawiam się wtedy na przykład po co dany parametr jest przekazywany do metody. Innym przykładem jest format daty, w jakim jest ona zwracana przez funkcję obsługi (YYMMDDHHMM). Otóż zwracana jest tablica bajtów w systemie semi-oktetowym (z dokumentacji specyfikacji TS 123 040), jednak jest to pomieszane: YY oznacza ostatnie dwie cyfry roku podane w odwrotnej kolejności, a 0x31 to, co mam rozumieć jako 13. Według przyjętego opisu obecna data miałaby reprezentację:

0x31 0x11 0x71 0xHH 0xMM 0xSS 0xStrefaCzasowa

PW: Czy operator może zdalnie uaktualniać karty SIM?

To chyba w Japonii znaleziono błąd w implementacji jednego apletu na karcie SIM, który usuwał inne aplety. Musiano zatrzymać wydawanie kart SIM ze sklepów, a użytkownicy, którym coś przestało działać w telefonie, czy zniknęły kontakty, zostali poproszeni o zwrot kart. Nie wiem nic o innych przypadkach, jednak obecnie jest możliwe aktualizowanie apletów. Są to koszty ponoszone przez operatora, ale najlepiej wyłapać usterki w fazie testów, bo poważne błędy mogą skończyć się pozwami lub odejściem klientów.

PW: Co musiałoby się zmienić, żeby polepszyć sytuację użytkowników, którym zależy na prywatności?

To pytanie brzmi podobnie do „jak unikać Google’a w Internecie?”. Google i Facebook śledzą wszystkich, także tych którzy nie używają ich serwisów – „Like!”, „+1”, kody Google Analytics (skr. GA) są wszędzie. Takim odpowiednikiem GA mogą być bazowe stacje przekaźnikowe (ang. base transceiver station, skr. BTS).

Operator wie, gdzie mieszkasz, gdzie pracujesz, gdzie jeździsz na zakupy, gdzie jeździsz na wakacje, ile czasu spędzasz w danym miejscu5.

Śledzenia telefonów używała policja w Londynie podczas zamieszek 3 lata temu. Dzięki liczbie zalogowanych telefonów do nadajników wiedzieli, w którą stronę przemieszcza się biegnący tłum, skąd nadchodzą inne grupy i nie potrzebowali wysyłać helikopterów do obserwacji.

PW: Stosujesz sam jakieś metody ochrony przed inwigilacją z wykorzystaniem urządzeń przenośnych?

Telefonu używam tylko do 2FA, ale robię tak już od dawna, zanim podjąłem pracę w aktualnej firmie. Służy jako budzik i do logowania się w różnych serwisach. Przez większość dnia działa w tzw. trybie samolotowym, ale to też ze względu na oszczędzanie baterii. Telefonu po prostu nie używam, bo wszystko robię przez Internet.


  1. „The Sim Toolkit Research Group” [w:] „THC Wiki”, The Hacker’s Choice, lipiec 2013 [return]
  2. C. E. Ortiz, „SIM Cards Overview”, Austin, sierpień 2009 [return]
  3. S. Sisodiya, „Difference between 2G and 3G Technology”, EngineersGarage, Jaipur, marzec 2012 [return]
  4. B. Benchoff, „Cracking GSM with RTL-SDR for Thirty Dollars”, Hack a Day, Madison, październik 2013 [return]
  5. M. Spitz, „Twój operator telefoniczny patrzy” [video], TED Conferences, Edynburg, lipiec 2012” [return]
Jesteś w sekcji .
Tematyka:

Taksonomie: