Stan zagrożeń w internecie znajduje się obecnie na poziomie standardowym. Nie występują duże epidemie a eksperci z Kaspersky Lab nie zanotowali żadnych poważnych incydentów związanych z bezpieczeństwem. Poziom zagrożenia: 1

Przewodowe ładowanie telefonu komórkowego – czy to jest bezpieczne?

Dodany 27 maja 2016, 10:52 CEST
Tagi:

Telefony komórkowe. Dzisiaj to nasi wierni towarzysze, nasi powiernicy. Wiedzą wszystko o naszym codziennym życiu. Każdego dnia, gdy jesteśmy w drodze do lub z pracy, czy po prostu spacerujemy po mieście, telefony komórkowe gromadzą te informacje. Robimy zdjęcia, dzielimy się naszymi wrażeniami na portalach społecznościowych, wysyłamy wiadomości związane z pracą i prywatne, wysyłamy SMS-y i dzwonimy. Wszystko to sprawia, że nasze smartfony to cenny łup dla złodziei danych.

A my jesteśmy przekonani, że nikt niepowołany nie będzie miał dostępu do wszystkich informacji przechowywanych w naszym telefonie.

Producenci zapewniają nas, że ich urządzenia i przechowywane na nich dane są bezpieczne. Publikują aktualizacje zawierające łaty bezpieczeństwa.

My również podejmujemy pewne działania, aby chronić naszą prywatność. Użytkownicy, którzy lubią „majstrować”, instalują niestandardowy firmware, odkrywają mechanizmy systemu operacyjnego, zdobywają dostęp na poziomie administratora, aby mieć głębszą kontrolę nad swoim telefonem i wykorzystują oprogramowanie, które, według nich, jest bezpieczniejsze i wygodniejsze.

Z kolei przeciętny użytkownik, który woli po prostu korzystać z telefonu, bez większego zagłębiania się w urządzenie, ustawia PIN, złożone hasło lub zabezpieczenie w postaci odcisku palca i korzysta jedynie z oficjalnych sklepów z aplikacjami.

Większość użytkowników wierzy, że dzięki tym działaniom ich dane są bezpieczne. Ale czy jest tak rzeczywiście?

Opisany w dalszej części eksperyment pokazuje, że niekiedy samo ładowanie urządzenia może sprowadzić na Ciebie kłopoty.

Transmisja danych

Jakiś czas temu zacząłem zastanawiać się głębiej nad tym, co się dzieje, gdy telefon zostanie podłączony do komputera. Zwykle, gdy telefon jest zabezpieczony, na komputerze widać tylko nazwę urządzenia. Jeśli nie ma ustawionego PIN-u/hasła, będzie można uzyskać dostęp do wszystkich plików multimedialnych na urządzeniu.

Ilość wymienianych danych różni się w zależności od producenta, wersji systemu oraz poziomu firmware’u. Ale zawsze są jakieś dane. Nawet jeśli jest to telefon z najnowszym systemem Android (Marshmallow) czy iOS 9.

Transmisja danych – tabela porównawcza

Poniżej znajduje się tabela porównawcza dotycząca wymiany danych pomiędzy komputerem i podłączonym do niego telefonem podczas „uścisku dłoni”. Dane różnią się w zależności od konfiguracji systemów operacyjnych telefonu komórkowego i komputera: 

Kody użyte w tekście:

DN – Device Name (nazwa urządzenia)

DM – Device Manufacturer (producent urządzenia)

DT – Device Type (typ urządzenia)

SN – Serial Number (numer seryjny)

FW – Firmware info (informacje dotyczące firmware’u)

OS – Operating System info (informacje dotyczące systemu operacyjnego)

FS – File system info/file list (informacje dotyczące system plików/lista plików)

ECID – Electronic Chip ID (ID elektronicznego czipu)

 

Urządzenie

System operacyjny urządzenia

Tryb

System operacyjny hosta

Rozmiar danych (bajty)

Typ danych

Nexus 5

Android 4.4

MTP (domyślny)

Windows 8.1

32 336

DN, DM,  DT, SN, FS

MTP (niezablokowany)

Windows 8.1

32 155

DN, DM,  DT, SN,  FS

MTP + ADB

Windows 8.1

11 946

DN, DM, SN

MTP (domyślny)

Windows 10

8 827

DN, SN

MTP (niezablokowany)

Windows 10

242 206

DN, SN, FS

MTP + ADB

Windows 10

10 582

DN, SN, FW

MTP (domyślny)

OSX 10.9

1 213

DN, DM,  DT, SN

MTP (niezablokowany)

OSX 10.9

581

DN, DM,  DT, SN

Nexus 6

Android 6.0.1

Tylko ładowanie (domyślny)

Windows 8.1

8 965

DN, DM, SN

MTP (niezablokowany)

Windows 8.1

39 418

DN, DM,  DT, SN,  FS

Tylko ładowanie (domyślny)

Windows 10

8 975

DN, SN

MTP (niezablokowany)

Windows 10

91 342

DN, SN, FS

Tylko ładowanie (domyślny)

OSX 10.9

14 000

DN, DM,  DT, SN

MTP (niezablokowany)

OSX 10.9

7 674

DN, DM,  DT, SN

Samsung Galaxy S4

Android 5.0.1

MTP (zablokowany)

Windows 8.1

4 098

DN, DM, DT, SN

MTP (domyślny)

Windows 10

7 740

DN, DM, DT, SN, FS, FW

Apple iPhone 5

iOS 9.1

Domyślny (zablokowany)

Windows 8.1

5 001

DN, DM, SN

Domyślny (zablokowany)

OS X 10.9

83 272

DN, DM, DT, SN, OS, ECID, publiczny klucz urządzenia

niezablokowany + sparowany

Windows 8.1

1 829 145

UniqueChipID, klasa urządzenia, wersja iOS, ID sesji, model urządzenia, całkowity rozmiar systemu plików, wolne miejsce w systemie plików

niezablokowany + sparowany

OS X 10.9

23 223

DN, DM, DT, SN, OS, ECID, publiczny klucz urządzenia

 

To dość sporo informacji o urządzeniu.

Co jeszcze?

Przeprowadzając to badanie, natknąłem się na nietypową funkcję w smartfonie bardzo popularnego producenta. Odkryłem, że podczas instalacji sterownika CDC (używałem standardowego komputera z Windowsem i całkowicie standardowego kabla microUSB) telefon ten instaluje również port COM, określając go jako modem. Na pierwszy rzut oka nie wydaje się to niczym szczególnym. Jednak w telefonie nie włączono tetheringu USB ani trybu dewelopera czy ADB (debugowanie USB).

Port COM jest dostępny do połączenia przy użyciu metod domyślnych.

A więc zbadaliśmy modem. A dokładniej to, co zbadaliśmy, to prawdopodobnie jedynie warstwa interfejsu, która pozwala nam komunikować się z modemem; nie jest to bezpośrednie połączenie.

A teraz przejdźmy do teorii. Android składa się z różnych warstw, a jedną z nich jest RIL. RIL (Radio Interface Layer) odpowiada za umożliwianie programom na poziomie aplikacji interakcji ze sprzętem modemu za pośrednictwem określonych poleceń (zarówno wysyłanie żądań jak i otrzymywanie odpowiedzi).

Aby nie wdawać się zbytnio w szczegóły, nie opiszę subwarstwy RIL Java, która komunikuje się z demonem rild lub Vendor RIL. Określmy ją po prostu jako RIL (Radio Interface Layer).     

Historycznie, wszystkie modemy wykorzystują zestaw poleceń określany jako zestaw poleceń Hayesa, opracowany przez Dennisa Hayesa w 1981 r. Polecenia wykorzystywane do komunikowania się z modemem określa się jako polecenia AT. Polecenia dostępne dla aplikacji do wywołania za pośrednictwem RIL oraz dostępne dla RIL w celu przesłania do modemu różnią się w zależności od ograniczeń firmware’u modemu ustawionych przez producenta, ograniczeń RIL itd. Wielu producentów implementuje również własne specyficzne dla producenta polecenia dla swoich modemów. I tak Qualcomm wykorzystuje rozszerzenie AT$Q<polecenie>, Infineon – AT+X<polecenie>   

Polecenia ATI1-9 zwracają ogólne informacje dotyczące urządzenia i modemu, np. ATI1 zwraca kod wersji oprogramowania.

 

wired_mobile_eng_1_auto.png

ATI2 zwraca numery IMEI. Widać tu, że urządzenie posiada dwie karty SIM.

wired_mobile_eng_2_auto.png

 

Przy użyciu poleceń AT można znaleźć więcej informacji.

A jeśli zbada się głębiej

Kopiąc nieco głębiej, można znaleźć wszystkie polecenia dostępne dla modemu. Należy zauważyć, że wiele z nich jest ograniczonych i/lub wymaga parametrów, bo w przeciwnym razie zwróci „Błąd”.

 

wired_mobile_eng_3_auto.png

Należy podkreślić, że polecenia specyficzne dla producenta nie zostaną tu wymienione!

Poziom sygnału telefonu komórkowego można sprawdzić przez AT+CSQ. Można także skontrolować poziom baterii itd.

Szczególnie interesujące jest jedno polecenie – domyślne dla modemów – które umożliwia zadzwonienie pod dowolny numer niezależnie od tego, czy ekran jest zablokowany czy nie. Jest to dość nietypowe w przypadku telefonów zablokowanych przy użyciu PIN-u, ponieważ z zablokowanego ekranu można zwykle zadzwonić jedynie po służby ratunkowe.  

Pewne polecenia pozwalają przeczytać informacje zawarte w książce telefonicznej karty SIM. Książka telefoniczna nie jest dostępna w tym konkretnym telefonie, nie wiadomo jednak, jak jest w przypadku innych producentów.

Najstraszniejsza część

Można pomyśleć: "I co z tego? Co można zrobić, posiadając takie informacje?". Gdy jednak zastanowimy się nad tym, okaże się, że w ten sposób można uzyskać informacje dotyczące producenta czy firmware’u. To daje wystarczająco dużo danych, aby przeanalizować poziom zabezpieczeń urządzenia. Można zdobyć numer telefonu jego właściciela – dzwoniąc na ten numer. 

Określenie poziomu naładowania baterii pozwala przewidywać, jak długo użytkownik pozostawi wpiętą ładowarkę. Według mnie, to już coś.

Jednak informacje te mogą posłużyć do czegoś więcej.

Eksperymentując dalej, natknąłem się na kolejne polecenie – w rzeczywistości służy ono do ponownego rozruchu telefonu do trybu aktualizacji firmware’u. Tryb ten pozwala osobie infiltrującej wykonać wszelkiego rodzaju działania na urządzeniu użytkownika w odpowiednich warunkach.

A zatem przeprowadziłem eksperyment. Przywróciłem telefon do fabrycznego firmware’u, zresetowałem go do ustawień fabrycznych, tak aby żaden inny interfejs taki jak ADB nie był dostępny na zewnątrz. 

Najpierw, podłączyłem telefon do komputera.

Następnie, zdobyłem dane dotyczące firmware’u przy użyciu poleceń AT, aby określić typ urządzenia i system operacyjny. W dalszej kolejności wprowadziłem ostatnie polecenie, na które się natknąłem, i telefon został uruchomiony w trybie aktualizacji firmware’u!  

 

4.png

 

Co stało się później?

Przy użyciu informacji zebranych przy pomocy poleceń AT zidentyfikowałem urządzenie.

Następnie wykorzystałem łatwe w użyciu rozwiązanie jako proof-of-concept. Znalazłem odpowiedni pakiet dla urządzenia, odpaliłem aplikację aktualizacji firmware’u i oto co zdarzyło się później:

 

5.png

 

Aktualizacja trwała około minutę (plik jest bardzo mały). Telefon został powtórnie uruchomiony, aby wykonać rzeczywistą instalację na poziomie administratora:

 

6.png

 

Pakiet główny został zainstalowany i usunął się.

Telefon został ponownie uruchomiony, i oto co widać -

 

7.png

Wszystkie dane użytkownika są bezpieczne, ale teraz urządzenie posiada jedną dodatkową aplikację, której nie da się odinstalować przy użyciu domyślnych sposobów i która posiada dostęp na poziomie administratora do systemu plików. Sprawdziłem na zegarze – cała procedura trwała nieco poniżej 3 minut, uwzględniając fakt ręcznego wciskania przycisków.

Gimnastyka wyobraźni

Pora użyć trochę wyobraźni. Co by było gdyby?

Co był było, gdyby ten pakiet nie miał ogólnego celu (z wieloma dodatkowymi funkcjami), ale jedno określone zadanie zainstalowania określonej aplikacji lub zmiany konfiguracji urządzenia? Pozwoliłoby to zminimalizować rozmiar pakietu i skryptu, skracając tym samym czas instalacji.

A gdyby zainstalował demona systemowego zamiast jakiegoś pakietu? A gdyby zainstalował backdoora? A gdyby to był jakiś trojan dla Androida – które są dzisiaj bardzo rozpowszechnione – i działał w tle, udostępniając wszystko, co znajduje się w Twoim telefonie, komuś, kto znajduje się na drugim końcu świata? 

Co, jeśli włączyłby tryb dewelopera lub ADB i dodał identyfikator komputera do zaufanej bazy danych? Takie zmiany nie zostałyby wykryte przez rozwiązanie bezpieczeństwa (gdyby było zainstalowane), ponieważ są to domyślne funkcje telefonu. Również wykonanie nie zajęłoby dużo czasu.

A co można zrobić z telefonem z zaufanego komputera, do którego został podłączony, za pośrednictwem ADB?   

Odpowiedź brzmi – wiele. Można instalować i usuwać aplikacje. Można wykonać kopię zapasową bazy wiadomości, zdjęć i filmów, pamięci podręcznej aplikacji oraz plików danych. I to dość szybko.

Wymienione scenariusze dotyczą jedynie kradzieży danych.

Istnieją również inne destrukcyjne działania, takie jak wyczyszczenie telefonu, usunięcie danych, zaszyfrowanie danych czy żądanie okupu. Możliwości są nieograniczone.

A zatem, wyobraźmy sobie scenariusz, w którym jesteś na wycieczce i właśnie wysiadłeś z samolotu po podróży trwającej 5-8 godzin. Twój telefon jest prawie rozładowany. Znajdujesz stację ładującą z USB – co za błogosławieństwo!

Podłączasz telefon, aby rozpocząć ładowanie, odkładasz go i zajmujesz się własnymi sprawami przez jakieś 20-30 minut.

Teraz przeczytaj to, o czym była mowa wcześniej. Ile czasu, według Ciebie, będzie potrzebował skrypt, aby wykonać opisane działanie, pobrać każdy bit danych z Twojego telefonu i/lub zainfekować go szkodliwym oprogramowaniem?

Mając te dane, ktoś może włamać się do Twojego telefonu, śledzić Cię, może zmodyfikować lub zniszczyć Twoje dane (łącznie z danymi firmowymi).

Tak po prostu.

Podsumowanie

Na świecie istnieją duże grupy, które specjalizują się w eksplorowaniu systemów operacyjnych, modyfikowaniu tego, co znajduje się wewnątrz, i publicznym udostępnianiu wyników swojej ciężkiej pracy.

Inne osoby wykorzystują wyniki tej pracy, aby uaktualnić swoje urządzenia. Nie ma jednak żadnej gwarancji, że firmware, który właśnie zainstalowały na swoich telefonach, jest wolny od luk w zabezpieczeniach i backdoorów. Mogą zapomnieć wyłączyć tryb dewelopera lub debugowania. Mogą zainstalować ukryty pakiet lub usługę w tle służącą do gromadzenia i przesyłania danych.  

Mimo wysiłków wszystkich producentów całkowite bezpieczeństwo urządzeń mobilnych jest praktycznie nieosiągalne.

Udowodnił to nasz eksperyment. Został przeprowadzony na urządzeniu tylko jednego producenta, co nie oznacza, że podobne dziury nie istnieją w telefonach innych producentów. Cały eksperyment został przeprowadzony z wykorzystaniem jedynie publicznie dostępnych informacji.

Pogrzebałem nieco głębiej i odkryłem, że luka ta została zidentyfikowana podczas konferencji Black Hat i pisano o niej już w 2014 r. Nie zyskała dużej uwagi, jak pokazuje badanie mediów informacyjnych i portali społecznościowych, i nadal istnieje, nawet w najnowszych modelach.

Pracując nad tym artykułem, odkryłem, że te same osoby z pewnym stopniu zidentyfikowały również tę dziurę.

Technika kradzieży danych z telefonu podłączonego do komputera została wykorzystana np. podczas znanej kampanii cyberszpiegowskiej Czerwony Październik w 2013 r.

Możliwość kradzieży danych z telefonu komórkowego podczas korzystania z publicznych stacji ładowania została opisana przez naszych ekspertów w 2014 r. Być może uważasz, że to paranoja sądzić, że ktoś zada sobie trud zainstalowania złośliwych stacji ładujących na lotniskach, w kawiarniach czy dworcach autobusowych, ale my jesteśmy innego zdania.