Kategorie
Android Bezpieczeństwo iOS Komunikatory

Aplikacja mobilna nie wie, czy telefon jest zhackowany

Poufność komunikacji prowadzonej przy użyciu popularnych komunikatorów mobilnych jest przedmiotem wielu badań i analiz. Omawiane i implementowane są takie koncepcje, jak „forward secrecy” („utajnianie z wyprzedzeniem”), „plausible deniability” („wiarygodna wykręcalność”?), wiele uwagi poświęca się też poprawności implementacji protokołów szyfrowania. Modelowanie zagrożeń pozwala ocenić, czy dane i metadane zbierane przez dostawców usług stanowią rzeczywiste lub potencjalne zagrożenie.

Żaden z najbardziej znanych komunikatorów, jak Signal, Whatsapp, Messenger czy Telegram, nie oferuje jednak funkcji nadzorowania bezpieczeństwa telefonu. Powód jest prosty – apka na komórce nie ma możliwości wiarygodnego sprawdzenia integralności systemu operacyjnego. Pokażemy, że złośliwe oprogramowanie działające z uprawnieniami superużytkownika może skutecznie ukrywać swoją obecność przed „zwykłymi” (pobranymi ze sklepu) aplikacjami uruchamianymi na zainfekowanym urządzeniu.

Garść rozważań o budowie systemów operacyjnych

Uwaga, dygresja. Wybierzemy się na małą wycieczkę w przeszłość i sprawdzimy, jak ewoluowały możliwości interakcji między programami działającymi jednocześnie na tym samym komputerze domowym (komputery mainframe dysponowały takimi możliwościami dobre 20 lat wcześniej). Jeśli ta dygresja cię znudzi, przeskocz do następnego rozdziału.

Komputery 8-bitowe

Mamy rok 1985. W domach na całym świecie królują komputery 8-bitowe. W każdym z nich zaszyty jest język programowania BASIC a komputer po włączeniu automatycznie uruchamia interpreter tego języka.

Rola systemu operacyjnego jest tu bardzo ograniczona – pośredniczy w komunikacji z napędem taśmowym i dyskowym, obsługuje przerwania sprzętowe (IRQ) dzięki którym program może reagować np. na użycie klawiatury i… to w zasadzie tyle. Program mógł wyłączyć przerwania, zmienić wektory wywołań systemowych lub wręcz całkowicie zrezygnować z usług systemu operacyjnego – na przykład po to, by przeznaczyć na własne potrzeby cały obszar pamięci RAM.

Jedną z nielicznych prób równoległego wykonania kodu w rzeczywistych warunkach był chyba BHP-Virus, wirus podmieniający systemowe procedury dostępu do stacji dysków Commodore 64, kryjący się w bankach pamięci RAM przesłoniętych pamięcią ROM. W warunkach eksperymentalnych wielozadaniowość na C-64 realizował system pico]OS for 6502.

Komputery 16-bitowe

Rok 1990. Najlepszym domowym komputerem jest Amiga 500. Jednym z możliwych trybów pracy jest użycie graficznego interfejsu Workbench.

Workbench wersja 2.0

Jądro systemu operacyjnego Amigi obsługuje wielozadaniowość, czyli pozwala na „jednoczesne” działanie wielu programów. Użyłem cudzysłowu, bo po dziś dzień mamy tak naprawdę do czynienia z szybkim przełączaniem między aktywnymi programami. Jednostka obliczeniowa (CPU core) w danej chwili wykonuje kod tylko jednego z nich.

Widać od razu, że w takiej sytuacji różne programy mogłyby wejść sobie w drogę, na przykład używając tego samego obszaru pamięci RAM komputera (i wzajemnie nadpisując jego zawartość). System operacyjny otrzymał więc nowe zadania – przydzielanie programom fragmentów pamięci o żądanym rozmiarze oraz pilnowanie, które obszary są w użyciu, a które zostały zwrócone do puli. Problem polegał na tym, że błędnie działający program mógł zamazać fragmenty pamięci należące do innych aplikacji lub – co gorsza – do systemu operacyjnego. To prawie zawsze skutkowało zawieszeniem komputera i utratą danych.

Wczesne pecety

Na przełomie lat ‘80 i ‘90 ubiegłego wieku pecety korzystały z systemu DOS, pozwalającego na pracę jednego programu naraz. Ponieważ jednak modularna budowa komputerów PC pozwalała na złożenie zestawu z dużą ilością pamięci i względnie szybkim procesorem, wielozadaniowość była bardzo pożądaną cechą systemu operacyjnego. Możliwość równoległej pracy kilku aplikacji zaoferował m.in. Windows 3.1, poprzednik Windows 95.

Mało znanym dziś faktem jest to, że Windows 3.1 to system implementujący model wielozadaniowości kooperacyjnej (cooperative multitasking). W modelu tym aplikacje dostają na chwilę pełną władzę nad komputerem, ale po ułamku sekundy powinny dobrowolnie oddać ją systemowi operacyjnemu, który przekaże władzę kolejnemu programowi, który także po bardzo krótkim czasie powinien zrzec się jej na rzecz systemu operacyjnego i tak dalej.

Jeśli aplikacja nie oddała sterowania, wszystkie pozostałe programy zastygały, zawartość ekranu przestawała się odświeżać a użytkownikowi pozostawało jedynie zrestartowanie komputera. Nadal mieliśmy więc do czynienia z sytuacją, w której błędny lub złośliwy kod mógł doprowadzić do przerwy w realizacji zadań.

Współczesne pecety i smartfony

Budowa współczesnego sprzętu i oprogramowania systemowego rozwiązuje oba wspomniane problemy.

Po pierwsze – w użyciu jest wielozadaniowość z wywłaszczaniem, dzięki której to system operacyjny decyduje o przydziale czasu procesora i może w dowolnej chwili przymusowo zmienić wykonywany proces na inny. Przełączanie takie ma miejsce setki lub tysiące razy na sekundę – stąd wrażenie, że wiele programów działa jednocześnie. Jeśli któraś aplikacja działa błędnie – zawiesza się sama i na własną odpowiedzialność, pozostałe programy działają bez zakłóceń.

Po drugie – układy zarządzające pamięcią (MMU) gwarantują, że dwa programy nie wejdą sobie w drogę. System operacyjny przydziela aplikacjom osobne obszary pamięci a program zostaje awaryjnie zatrzymany, gdy tylko próbuje sięgnąć do komórki pamięci spoza przydzielonego sobie obszaru.

Z powyższego opisu wynika, że istnieją co najmniej dwa poziomy uprzywilejowania programów. Tylko jądro systemu operacyjnego i wybrane komponenty (np. sterowniki urządzeń peryferyjnych) działają z wysokimi przywilejami i mają nieskrępowany dostęp do wszystkich zasobów – dlatego właśnie źle napisany sterownik nadal może zawiesić komputer.

Koniec dygresji pierwszej.

Garść rozważań o systemie plików

Dygresja druga, krótsza.

W wielozadaniowych systemach operacyjnych także dostęp do pamięci masowej musi być regulowany przez odpowiedni moduł koordynujący operacje zapisu i odczytu danych.

Programy operują na poziomie plików i katalogów, nie mogą więc powiedzieć: „drogi systemie operacyjny, proszę o ustawienie głowicy nr 1 dysku twardego nad ścieżką nr 15 i zapis do sektora 1234 następujących bajtów”. Zamiast tego muszą zwracać się do systemu operacyjnego z prośbami w stylu „proszę o utworzenie pliku c:\users\tomek\artykul.txt i przekazanie uchwytu do tego pliku” albo „proszę o informację, czy istnieje plik c:\users\tomek\notatki.txt”.

W środowiskach przeznaczonych do jednoczesnej pracy wielu osób od dziesiątek lat stosuje się systemy plików pozwalające na selektywny przydział uprawnień do plików i katalogów. To sprawia, że na pytanie „czy istnieje plik c:\users\tomek\notatki.txt” istnieją trzy możliwe odpowiedzi: tak / nie / nie masz uprawnień by to wiedzieć.

Koniec dygresji drugiej, początek trzeciej.

Programiści często korzystają z możliwości przechwycenia tzw. wywołań systemowych (czyli tych funkcji, które na zlecenie programu realizuje system operacyjny). Dzięki temu są w stanie sprawdzać, czy ich program rezerwuje a potem zwalnia potrzebną ilość pamięci, czy odwołuje się do właściwych plików albo czy – rezerwując na wyłączność któreś z urządzeń – przeprowadza prawidłową sekwencję operacji.

Taki mechanizm może być jednak wykorzystany przez złośliwe oprogramowanie, które – działając z podwyższonymi uprawnieniami – może przechwycić wywołania systemowe i zwracać fałszywe odpowiedzi. Przykładowa komunikacja będzie wówczas wyglądała tak:

  • program: „czy istnieje plik c:\users\tomek\notatki.txt?”
  • złośliwy kod (nie sprawdza, od razu odpowiada): „NIE ISTNIEJE”
  • system operacyjny: milczy, bo pytanie do niego nie dotarło, choć plik istnieje

W takiej sytuacji program będzie kontynuował pracę w oparciu o błędne dane.

Na zakończenie trzeciej dygresji dochodzimy do niepokojącego spostrzeżenia – program działający we współczesnym systemie operacyjnym nie ma żadnej metody sprawdzenia, czy środowisko pracy jest zainfekowane złośliwym kodem. Nie przeskanuje całej pamięci RAM pod kątem sygnatur znanych wirusów, bo ma dostęp tylko do swojego kawałka przestrzeni adresowej. Nie przeskanuje systemu plików, bo złośliwy kod może go okłamywać przy każdym odwołaniu do dowolnego pliku czy katalogu.

Aby było trudniej, obie platformy mobilne (Android i iOS) wywodzą się z systemów uniksowych, po których dziedziczą wiele mechanizmów wzmagających izolację programów. Aby było jeszcze trudniej – aplikacje uruchamiane są w tzw. piaskownicy, co jeszcze bardziej ogranicza ich możliwości interakcji z otoczeniem.

Jak aplikacja mobilna miałaby przy tych wszystkich ograniczeniach wykrywać złośliwe oprogramowanie? Odpowiedź: nie będzie w stanie. Owszem, czasem zaistnieje możliwość wykrycia efektów ubocznych infekcji, ale to rzadkość. Co do zasady: gdy malware przejmie kontrolę nad twoim urządzeniem, przegrywasz.

Rootujemy Androida

Informacja o konfiguracji urządzenia testowego może przydać się osobom, które zechcą przeprowadzić eksperymenty we własnym zakresie. Pamiętaj, aby nie brać do badań swojego podstawowego telefonu, bo po pierwsze jego zawartość zostanie zresetowana a po drugie dramatycznie obniżamy jego odporność na ataki.

Ja użyłem telefonu HTC One M9. Zabezpieczenia programu rozruchowego (bootloadera) w tym telefonie zostały zdjęte, zaś program ratunkowy (recovery) został podmieniony na TWRP, co pozwoliło na zainstalowanie alternatywnej wersji Androida o nazwie LineageOS.

Od lewej: odblokowany bootloader; recovery TWRP, LineageOS

System ten został dodatkowo zrootowany, co oznacza, że użytkownik ma możliwość uruchamiania dowolnej aplikacji z uprawnieniami superużytkownika (tzw. root). W fabrycznym oprogramowaniu taki poziom uprzywilejowania jest zarezerwowany dla wybranych komponentów systemowych.

Wymienione wyżej oprogramowanie instalowałem świadomie i dobrowolnie. Autorzy złośliwego oprogramowania (malware) obierają inną ścieżkę: wyszukują usterki systemu Android i wykorzystują je do tego, by ich kod podniósł swoje własne uprawnienia a następnie – już bez żadnych ograniczeń – działał na szkodę użytkownika. Rezultatem obu tych podejść jest to samo – program działający na telefonie z uprawnieniami superużytkownika.

Przygotujmy środowisko pracy. Moim ulubionym narzędziem jest framework Xposed – głównie dlatego, że pozwala na szybkie i łatwe wpinanie w badany program. W Androidach od wersji 4 do 8 instalowaliśmy Xposed jako samodzielną modyfikację systemu operacyjnego. Ja używam LineageOS 16.0 opartego na Androidzie 9, więc jedyną opcją jest użycie Magiska, Riru oraz EdXposed. Pamiętajcie, że wielu ludzi spędziło tysiące godzin tworząc i testując wszystkie te narzędzia. Serio, stajemy na ramionach gigantów.

W jaki sposób aplikacja może wykrywać zrootowanie?

Kto i dlaczego chciałby wykrywać zrootowane urządzenie? Często robią to np. dostawcy platform streamingowych oferujących oglądanie filmów przez internet – obawiają się, że na urządzeniach ze zdjętymi zabezpieczeniami strumień audio-wideo może zostać rozkodowany i zapisany do pliku a w konsekwencji film trafi do nielegalnej dystrybycji. Jak zwykle przy tego typu wysiłkach – najbardziej cierpią klienci.

Czasem fakt rootowania jest wykrywany przez aplikacje bankowe, które przekazują taką informację na serwery banku. Taki sygnał może (ale wcale nie musi) pomagać w szacowaniu ryzyka oszustw w kanale mobilnym – oczywiście jako jeden z kilkudziesięciu innych parametrów zlecanej transakcji.

Jedną z metod wykrywania roota jest użycie biblioteki programistycznej RootBeer, którą każdy zainteresowany może dołączyć za darmo do swojego programu. Przyjrzyjmy się dokładnie, co też takiego sprawdza RootBeer. Powie nam to aplikacja RootBeer sample demonstrująca działanie tej biblioteki.

powyżej: apka RootBeer sample uruchomiona na naszym urządzeniu

RootBeer wykrył następujące sygnały wskazujące, że urządzenie jest niezaufane: obecność Magiska i Xposed oraz programów BusyBox i su. Sprawdzane były też prawa dostępu do pewnych katalogów, certyfikaty którymi podpisano ROM oraz parametry jądra i ustawień systemowych, ale tu RootBeer nie wykrył nieprawidłowości. Dodajmy, że czasem będziemy mieli do czynienia z tzw. false positive, czyli przypadkiem, gdy nietknięty telefon zostanie uznany za niegodny zaufania (przykład – w oryginalnych ROM-ach OnePlusa znajdziemy BusyBoxa).

Jak to się ma do prawdziwego modus operandi malware? Nijak. Złośliwe oprogramowanie działa w ukryciu. Nie potrzebuje busyboxa ani su, nie instaluje Xposed, nie podmienia certyfikatów którymi podpisano aplikacje systemowe, nie zmienia uprawnień do katalogów systemowych. Powiedzmy to jeszcze raz – znaczna większość zrootowanych telefonów nie jest zainfekowana. Znaczna większość zainfekowanych telefonów nie jest zrootowana.

Oszukujemy RootBeer-a

Przekonamy się teraz, że oszukanie RootBeer-a jest bardzo proste i nie wymaga od nas pisania żadnego nowego kodu.

Wrzucenie w Google hasła “rootbeer bypass” prowadzi do artykułu z którego dowiadujemy się o module Xposed noszącym nazwę UnRootBeer. Jego źródła nie były dotknięte od 3 lat, ale co nam szkodzi spróbować.

Na obrazkach powyżej widzimy, że moduł został zainstalowany, aktywowany, po obowiązkowym restarcie uruchamiamy ponownie RootBeer sample.

powyżej: apka RootBeer sample uruchomiona w obecności UnRootBeer

Ha! Wszystkie atrybuty świecą na zielono, biblioteka RootBeer w aplikacji testowej utraciła zdolność wykrywania zrootowanego urządzenia. Okazuje się, że gotowiec sprzed kilku lat, którego użyliśmy by oszukać aplikację testową biblioteki RootBeer, pozbawi tej możliwości dodatkowo także aplikacje, w kodzie źródłowym których nie zmieniono nazw klas ani metod (jeśli je zmieniono, konieczne będą niewielkie korekty).

Co tak naprawdę zrobiliśmy?

Zajrzyjmy do źródeł biblioteki UnRootBeer. Zobaczymy tam powtarzalny schemat – automat wyszukuje („findAndHookMethod”) funkcje oryginalnej biblioteki RootBeer (np. „checkForSuBinary”) by zastąpić ( „replaceHookedMethod”) je kodem informującym, że zagrożenia nie wykryto ( „return false”).

Jak to działa? Wspomniany wcześniej komponent Riru podłącza się do tzw. zygoty czyli zalążka każdego programu uruchamianego przez użytkownika. To pozwala innym modułom na zmianę sposobu działania tych programów i to właśnie robi EdXposed – przy jego użyciu możemy dostarczać kod który przesłania oryginalną funkcję i zamiast niej wstrzykuje inne polecenia.

Wstrzykujemy kod do komunikatora Signal

Zastanówmy się, jak trudne byłoby wstrzyknięcie kodu do komunikatora Signal. Zajrzyjmy do kodu źródłowego klasy ConversationActivity  (Signal jest produktem na licencji GNU GPL i jego kod jest powszechnie dostępny). W klasie tej można znaleźć metodę getMessage() używaną m.in. w momencie wysyłania nowej wiadomości. Metoda ta zwraca napis obecny w kontrolce ekranowej composeText czyli polu tekstowym do wpisywania wiadomości.

Skorzystamy teraz z innej opcji EdXposed – wepniemy się z własnym kodem nie zamiast, lecz przed metodę getMessage(), dzięki czemu będziemy w stanie przechwycić i wysłać do internetu ten sam napis, który bezpiecznym połączeniem przekaże Signal.

Użyta tu funkcja sendMsg(String txt) to dowolny kod wykorzystujący treść wykradzionej wiadomości.

Zauważmy, że nie modyfikowaliśmy w żaden sposób komunikatorów Signal, jego pliki pozostają nienaruszone! Nasz (symulowany) złośliwy kod działający z uprawnieniami superużytkownika może w dowolny sposób kontrolować i modyfikować zachowanie innych programów, ale nie zmienia plików programu pobranego ze sklepu Play.

Co z dostępem do archiwalnych wiadomości?

Baza danych Signala jest szyfrowana a my moglibyśmy bez problemu przechwycić klucz, jednak zamiast tego wrzucimy do logów wszystkie odszyfrowane napisy tuż po operacji dekodowania. Odpowiada za to metoda decryptBody w klasie MasterCipher. Tym razem pozwalamy się jej wykonać zaś nasz wstrzyknięty kod ma dostęp do wyniku tej operacji.

Powyższy kod sprawia, że pochodzące z szyfrowanej bazy danych Signala napisy zostają tuż po odszyfrowaniu zapisane do logów systemowych. System operacyjny to pierwsza i ostatnia linia zabezpieczeń. Dalej nie ma już nic.

Czy powyższe działania są zbliżone do tego, co rzeczywiście robi malware?

Od strony technicznej – tak. Dowodem jest malware CopyCat opisany szczegółowo przez Check Point Software. W 2017 roku ofiarą infekcji padło 14 milionów telefonów. Na około 8 milionach owo złośliwe oprogramowanie uzyskało uprawnienia roota, infekowało zygotę i przejmowało kontrolę nad aplikacją Google Play, podmieniając lub wstrzykując fałszywy identyfikator źródła instalacji. To pozwalało autorom malware zarabiać na rzekomym promowaniu aplikacji firm trzecich.

Fragment złośliwego kodu pochodzący z malware CopyCat
źródło: Check Point Software

Ktoś mógłby powiedzieć, że to było dawno temu, ofiarą padły telefony z Androidem w wersji 5 lub starszej i w ogóle od tamtego czasu system został tak zabezpieczony, że nie sposób wyobrazić sobie zdalnego ataku podobnej klasy.

Owszem, poprzeczka cały czas się podnosi, ale ekspertom takim jak Mateusz „j00ru” Jurczyk co jakiś czas udaje się opracować zupełnie nowe ścieżki ataku. Mateusz kilka miesięcy temu opublikował pięcioczęściowy epicki opis wyrafinowanego ataku na najnowsze flagowe modele Samsunga Galaxy (wiem, za dużo przymiotników, ale chciałem podlinkować wszystkie odcinki opisu i brakowało słów). W opisanym ataku seria specjalnie spreparowanych wiadomości MMS wystarcza do tego, by doprowadzić do wykonania kodu na telefonie ofiary.

Powtórzę, aby ta informacje lepiej się przyjęła. Atakujący wysyła na waszego nowiutkiego Samsunga serię kilkudziesięciu lub kilkuset MMS-ów. Na ekranie ani w skrzynce odbiorczej ich nie widać. W ciągu kilku godzin te niewidoczne MMS-y sprawiają, że nadawca przejmuje kontrolę nad waszym telefonem. Kurtyna.

Czy da się skutecznie zabezpieczyć oprogramowanie przed opisanymi wyżej działaniami?

Nie.

Oczywiście można uczynić to zadanie bardzo trudnym – co powiecie na reverse engineering programu złożonego wyłącznie z instrukcji mov procesora? Ilustracją ogólnych trendów może być jednak antypirackie zabezpieczenie gier o nazwie Denuvo. W styczniu 2016 crackerzy byli gotowi poddać się, bo było ono nie do pokonania. W drugiej połowie 2016 łamano już Denuvo, ale zajmowało to tygodnie lub miesiące. W roku 2018 były to pojedyncze dni, a dziś większość tak zabezpieczonych tytułów jest łamana w dniu premiery lub wcześniej rutynowo, choć nie zawsze tak szybko.

Trzeba zaznaczyć, że zabezpieczenia antypirackie gier na PC często działają jako sterownik systemowy a więc z pełnymi uprawnieniami, o czym aplikacje androidowe mogą tylko pomarzyć. Regularnie widzimy też tzw. jailbreaki różnych zamkniętych platform, jak iOS, PlayStation, NintendoDS czy Switch. Nawet, gdy oprogramowanie byłoby absolutnie perfekcyjne, zawsze można liczyć na odkrycie luk i podatności w zastosowanym sprzęcie.

Czy wszystko jest stracone, tajne służby podsłuchają każdy telefon a to całe bezpieczeństwo Signala to oszustwo?

Gdy mówimy o poziomie bezpieczeństwa, musimy najpierw określić jakąś skalę, czyli tak zwany model zagrożeń. Dlaczego? Czy bezpieczeństwo nie jest tym samym dla każdego człowieka?

Otóż – nie jest. Rozważmy przykład biznesmena dużej firmy lecącego do kraju niedemokratycznego na negocjacje biznesowe. Ma on ze sobą wyłączonego laptopa z dyskiem zaszyfrowanym BitLockerem, dokumenty są dodatkowo przechowywane w kontenerze TrueCrypta. Na docelowym lotnisku biznesmen zostaje zabrany na kontrolę osobistą, na kwadrans traci z oczu teczkę z laptopem. W tym momencie laptopa można zutylizować – istnieje bowiem ryzyko, że został wzbogacony o sprzętowego backdoora.

Drugi przykład – siedziba Agencji Wywiadu, uzbrojona straż, kontrola dostępu, trzeci poziom podziemi, bezpieczny pokój z szumidłami. Taki sam laptop przeznaczony do oglądania przyniesionych prezentacji może tam działać z jednym wspólnym kontem bez żadnego hasła, bo nigdy nie zostanie podłączony do żadnej sieci i nigdy nie opuści tego pomieszczenia.

Przykład z działki mobilnej? Domowy tablet do Youtuba i Netfliksa może nie mieć żadnego PIN-u. Biznesmen ostrzeżony o zagrożeniu kradzieżą sprzętu może pogodzić się z niewygodami i stosować na telefonie 10-znakowy alfanumeryczny PIN, bez biometrii.

Gdy mówimy o bezpieczeństwie mobilnych komunikatorów, też mamy do czynienia z wieloma warstwami zabezpieczeń:

  • jeśli wyrwiemy komuś z ręki telefon z aktywnym komunikatorem – game over
  • jeśli wyrwiemy komuś telefon, wykręcimy rękę i jego kciukiem odblokujemy komunikator – game over
  • jeśli przejmiemy zablokowany telefon lecz mamy sprzęt i oprogramowanie omijające ekran blokady – być może game over, choć niekoniecznie
  • jeśli przejmiemy zablokowany telefon lecz mamy sprzęt i oprogramowanie omijające ekran blokady ORAZ znamy metodę ataku na bezpieczny magazyn kluczy (secure enclave) – game over
  • jeśli wiemy, że na telefonie ktoś korzysta z internetu i znamy podatność systemu lub aplikacji pozwalającą na zdalne wykonanie kodu – być może game over
  • jeśli wiemy gdzie jest telefon i mamy sposób na zdalne wykonanie kodu poprzez atak na mobilny modem poprzez podstawionego BTS-a – być może game over

Każdy kolejny poziom zabezpieczeń to coraz większa trudność ataku, coraz większe koszty jego przeprowadzenia i coraz trudniejsze decyzje, czy cel wart jest potencjalnego spalenia podatności typu „0-day”.

Bezpieczeństwo to nie jakaś wartość bezwzględna, lecz oszacowanie ryzyka w stosunku do spodziewanych zagrożeń.

Czy bezpieczny komunikator jest możliwy? Taki dla Jamesa Bonda?

Odpowiedź krótka nr 1 – tak. Urządzenia do bezpiecznej komunikacji istnieją i są używane zarówno przez służby specjalne (Jej Królewskiej Mości również) jak i przestępców.

Odpowiedź krótka nr 2 – nie. Wystarczająco wiele państw, służb, organizacji odnalazło wystarczająco wiele błędów typu 0-day, by żaden komunikator na żadnym systemie nie mógł być uznany za w pełni bezpieczny.

Odpowiedź dłuższa – to skomplikowane. Grupa docelowa jest zbyt mała, by realne było napisanie dedykowanego systemu operacyjnego albo konstruowanie unikalnych urządzeń. W praktyce stosuje się więc seryjne modele telefonów i wyposaża je w zmodyfikowane oprogramowanie.

Zabezpieczony telefon jest wówczas urządzeniem służącym tylko jednemu celowi – komunikacji (tekstowej lub głosowej). Nie znajdziemy tam sklepu z aplikacjami, gier czy przeglądarki internetowej. Wszystkie zbędne funkcje i usługi są wyłączone lub usunięte. Integralność systemu operacyjnego kontrolowana jest przez komponenty działające z podwyższonymi uprawnieniami. Czy to wystarczy by zagwarantować bezpieczeństwo? Niekoniecznie.

W każdym używanym współcześnie systemie operacyjnym odkrywane są luki i usterki, więc oparte na nich bezpieczne urządzenie musi być regularnie aktualizowane. W przeciwnym razie adwersarz mógłby wykorzystać owe usterki do zdalnego przejęcia kontroli – efekty widzieliśmy powyżej. Jeśli jednak owe aktualizacje będą dostarczane przez sieć, najsłabszym ogniwem staje się infrastruktura dystrybuująca paczki z oprogramowaniem.

W ten właśnie sposób zhackowano przestępców korzystających z bezpiecznych (do czasu) urządzeń Encrochat. Wszystko wskazuje na to, że to dzięki aktualizacji spreparowanej przez policję szyfrowanie end-to-end nagle straciło swoje właściwości. Zanim operator Encrochata zorientował się w sytuacji i wyłączył usługę, miesiące podsłuchu zaowocowały dowodami pozwalającymi na aresztowanie setek osób.

W magazynie Vice możemy przeczytać pełną szczegółów opowieść o kanadyjskiej firmie Phantom Secure, która świadczyła usługi bezpiecznej komunikacji w oparciu o urządzenia BlackBerry. Szef firmy odsiaduje obecnie wieloletni wyrok za świadomą współpracę z przemytnikami narkotyków.

Należy też pamiętać o podatnościach sprzętu, o wiele trudniejszych tak do wykrycia jak i załatania. Przykładem może być QualPwn czyli seria krytycznych błędów w procesorach Qualcomm Snapdragon 835/845, które – połączone – pozwalały na zdalne wykonanie kodu z najwyższym poziomem uprzywilejowania.

Możemy więc zaryzykować twierdzenie, że przygotowanie bezpiecznego systemu komunikacji jest znacznie prostsze, niż utrzymanie niezmienionego poziomu bezpieczeństwa w dłuższym okresie (szczególnie, gdy do gry wejdzie wytrwały i cierpliwy adwersarz o dużych zasobach – np. służba wywiadowcza).

Cały tekst jest o Androidzie, co z iOS?

Podobnie jak Android – iOS jest systemem operacyjnym z rodziny uniksopodobnych, z ochroną pamięci, wywłaszczaniem procesów, sandboxem i wzajemną izolacją aplikacji. Różnice dotyczą terminologii (zamiast o rootowaniu mówimy o tzw. jailbreaku) i narzędzi do analizy pracy aplikacji (zamiast Xposed – Frida).

Malware działający z podwyższonymi uprawnieniami będzie w stanie oszukać aplikację pobraną ze sklepu App Store w taki sam sposób, jak w przypadku Androida. Każde wywołanie systemowe może zostać przechwycone zaś odpowiedź – zmodyfikowana. Nie będzie też mowy o wykorzystaniu bardziej wyrafinowanych sztuczek, bo aplikacje wysyłane do App Store podlegają skrupulatnej kontroli, obejmującej m.in. zakres wywoływanych funkcji. Programiści mogą korzystać jedynie z tzw. API publicznego, wykluczającego bardziej wnikliwe próby sprawdzania integralności systemu operacyjnego.

Również w świecie Apple zdarzają się krytyczne podatności bezpieczeństwa pozwalające na zdalny atak – np. luka opisana tutaj. Do przejęcia pełnej kontroli nad systemem iOS wystarczyło zbliżyć się do telefonu ofiary na odległość kilkunastu metrów.

Zakończenie

Z niniejszego artykułu dowiedzieliśmy się, dlaczego aplikacje mobilne pobrane z Google Play lub App Store nie są w stanie wiarygodnie zweryfikować integralności systemu operacyjnego. Wiedzę teoretyczną potwierdziliśmy na przykładzie komunikatora Signal – podsłuchaliśmy wysyłane wiadomości i poznaliśmy zawartość szyfrowanej bazy danych. Z taką samą łatwością można dokonać „wkłucia” w dowolną aplikację z dowolnej kategorii.

Nie znaczy to jednak, że twórcy aplikacji robią coś źle, albo nie dokładają pełni starań by chronić użytkownika. Oznacza to jedynie, że „zwykła” aplikacja mobilna nie jest w stanie zweryfikować stanu bezpieczeństwa urządzenia, na którym pracuje. Złośliwe oprogramowanie działające z uprawnieniami superużytkownika może skutecznie ukrywać swoją obecność.



O autorze: zawodowy programista od 2003 roku, pasjonat bezpieczeństwa informatycznego. Rozwijał systemy finansowe dla NBP, tworzył i weryfikował zabezpieczenia bankowych aplikacji mobilnych, brał udział w pracach nad grą Angry Birds i wyszukiwarką internetową Microsoft Bing.

10 odpowiedzi na “Aplikacja mobilna nie wie, czy telefon jest zhackowany”

Tak, przydatność takich antywirusów jest niewielka, dlatego zazwyczaj mają w komplecie jakieś dodatkowe funkcje. To może być temat na jeden z kolejnych tekstów.

Co rozumiemy poprzez stan bezpieczeństwa urządzenia? Ostatni akapit:

1. Czy jest aktualny OS dla danego urządzenia (producent może nie udostępniać aktualizacji)?

2. Czy ma roota?

3. Czy jest podłączone do niezabezpieczonej wifi?

4. Czy korzysta z sieci 2G (aktualnie – w czasie uruchomienia aplikacji mobilnej)? (znane słabości w zabezpieczeniu sieci 2G).

5. Czy smartfon jest zabezpieczony wzorem, kodem, touch id, face id itp?

6. Czy w Androidzie włączone jest szyfrowanie? (od którejś wersji, chyba 7 albo 8? stało się domyślne).

Aplikacja mobilna nie musi wiedzieć i może nigdy nie sprawdzać w sposób wiarygodny, czy smartfon jest zainfekowany albo też zhackowany. Aplikacja mobilna za to może sprawdzić podstawowe cechy bezpieczeństwa i przekazać je w odpowiedzi na ekranie. To przynajmniej minimalizuje ryzyko ataku, ale zmniejsza całkowicie powierzchni ataku.

Podłączenie do „niezabezpieczonej” sieci Wi-Fi nie ma większego znaczenia dla poprawnie napisanych aplikacji (używających wyłącznie połączeń szyfrowanych). Z drugiej strony sam fakt połączenia do publicznej sieci zabezpieczonej WPA2-Personal daje niewiele lepszy poziom bezpieczeństwa, niż sieć otwarta. Z trzeciej nie możesz wymagać że przeciętny użytkownik postawi sieć WPA-Enterprise, która rzeczywiscie byłaby bezpieczniejsza.

SE ma to dobrze wytłumaczone: https://security.stackexchange.com/questions/137104/is-hacking-wi-fi-that-easy-just-spoof-and-its-hacked

Bardzo dobrze się to czytało, bardzo. Teraz następuje pytanie. Czy faktycznie wszelkiego rodzaju malware’y na telefony nie są trwałe i w przypadku podejrzenia infekcji restart urządzenia jest dobrym remedium?

Trwałe są trudniejsze do osiągnięcia, więc restart usunie pozostałe. Dopóki jednak widać tylko jakieś objawy, ale nie wiadomo, jaka była droga infekcji, restartowanie nie wyleczy problemu.

To nie tyle część SDK, co Google Play Services. Aplikacja może spytać Google, co Google sądzi o telefonie, przy czym odpowiedź powinna być przetwarzana gdzieś na serwerze, nie w aplikacji.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *