Jak Android umożliwia atak typu „Man-in-the-Disk”?

Przeczytaj także: Android: luki w zabezpieczeniach źródłem dużych problemów

Do ataku „Man-in-the-Disk” może dojść wówczas, gdy aplikacje nie dość ostrożnie korzystają ze współużytkowanej pamięci masowej, która nie wykorzystuje ochrony środowiska piaskownicy w systemie Android i nie chroni się poprzez własne środki bezpieczeństwa. Na czym dokładnie polega problem? Oto wyjaśnienia specjalistów Check Point Software Technologies.

Czym jest pamięć zewnętrzna?

Żeby zrozumieć na czym polegają niedociągnięcia projektu piaskownicy systemu Android, należy przede wszystkim zdać sobie sprawę, czym właściwie są zasoby pamięci masowej w urządzeniu pracującym w oparciu o ten system.

W systemie operacyjnym Android istnieją dwa rodzaje pamięci masowej: pamięć wewnętrzna, z której każda aplikacja korzysta osobno i która jest segregowana przez system Android Sandbox oraz pamięć zewnętrzna, często w postaci karty SD lub partycji logicznej w pamięci urządzenia, która jest współużytkowana przez wszystkie aplikacje. Pamięć zewnętrzna jest tak naprawdę używana przede wszystkim do udostępniania plików pomiędzy aplikacjami. Na przykład, aby aplikacja komunikatora mogła wysyłać zdjęcia od jednej osoby do drugiej, musi ona mieć dostęp do plików multimedialnych przechowywanych w pamięci zewnętrznej.

Istnieją jednak inne powody, dla których twórca aplikacji zdecydowałby się użyć pamięci zewnętrznej zamiast wewnętrznej pamięci z funkcją piaskownicy. Są to: brak wystarczającej pojemności pamięci wewnętrznej, względy kompatybilności wstecznej ze starszymi urządzeniami, chęć, aby nie wyglądało na to, że aplikacja zajmuje zbyt dużo miejsca, albo po prostu lenistwo programisty.

Niezależnie od przyczyny podczas korzystania z pamięci zewnętrznej niezbędne są określone środki ostrożności.
Zgodnie z dokumentacją systemu Android firmy Google programiści są poinstruowani, w jaki sposób powinni używać pamięci zewnętrznej w aplikacjach. Niektóre z tych wytycznych są następujące:

1. „Wykonaj sprawdzanie danych wejściowych w przypadku przetwarzania danych z pamięci zewnętrznej”
2. „Nie przechowuj plików wykonywalnych ani plików klas w pamięci zewnętrznej”
3. „Pliki pamięci zewnętrznej powinny być podpisane i zweryfikowane kryptograficznie przed ładowaniem dynamicznym”

Check Point był jednak świadkiem kilku przykładów, w których Google i inni dostawcy systemu Android nie stosują się do tych wytycznych. I tu właśnie istnieje pole do ataków typu „Man-in-the-Disk”, umożliwiające zaatakowanie dowolnej aplikacji, która nieostrożnie przechowuje dane w pamięci zewnętrznej.

Atak typu „Man-in-the-Disk”

Chociaż niekoniecznie jest to normą, byliśmy świadkami kilku przypadków, w których aplikacja została pobrana, zaktualizowana lub odebrana z serwera dostawcy aplikacji, przeszła przez pamięć zewnętrzną i dopiero wtedy została wysłana do samej aplikacji.

Tak naprawdę aplikacje te często mogły funkcjonować tylko dzięki danym przechowywanym w pamięci zewnętrznej – mimo że wytyczne Google dla programistów wskazują, by tak nie postępować.

Nowe pole do ataku wykryte przez analityków Check Point pozwala atakującemu wejść i ingerować w dane przechowywane w pamięci zewnętrznej. Korzystając z niewinnie wyglądającej aplikacji pobranej przez użytkownika, osoba atakująca może monitorować dane przesyłane między dowolną inną aplikacją i pamięcią zewnętrzną oraz zastępować je własnymi danymi w odpowiednim czasie, co prowadzi do niepożądanego zachowania zaatakowanej aplikacji.

Po pobraniu „niewinnie wyglądającej” aplikacji atakującego użytkownik zostanie poproszony o zezwolenie aplikacji na dostęp do pamięci zewnętrznej, co jest całkowicie normalną procedurą, której wymagają aplikacje i raczej nie wzbudza to podejrzeń u użytkownika. Szkodliwy kod atakującego rozpocznie wtedy monitorowanie pamięci zewnętrznej i wszystkich przechowywanych w niej danych.

W ten sposób atakujący ma swojego „człowieka na dysku” („Man-in-the-Disk”), szukającego sposobów, w jaki może przechwytywać ruch i informacje wymagane przez inne istniejące aplikacje użytkownika, aby manipulować nimi lub powodować ich awarię.

Skutki ataków mogą się różnić w zależności od zamiarów i umiejętności atakującego. Badania Check Pointa wykazały możliwość zainstalowania niepożądanej aplikacji w tle, bez zgody użytkownika. Udowodniliśmy również możliwość spowodowania awarii zaatakowanej aplikacji, powodującej u niej odmowę usługi. Po awarii i po wyłączeniu mechanizmów obronnych aplikacji osoba atakująca może potencjalnie dokonać wstrzyknięcia kodu w celu przejęcia uprawnień przyznanych atakowanej aplikacji i eskalacji własnych uprawnień w celu uzyskania dostępu do innych elementów urządzenia użytkownika, takich jak kamera, mikrofon, listy kontaktów i tak dalej.

Aplikacje, w których mieszka „Man-in-the-Disk”

Wśród aplikacji przetestowanych pod kątem nowej powierzchni ataku były: Tłumacz Google, Tłumacz Yandex, Wprowadzanie głosowe Google, LG Application Manager, LG World, Przetwarzanie tekstu na mowę Google oraz przeglądarka Xiaomi. Po zapoznaniu się z poradami podanymi w wytycznych Google zespół Check Pointa przystąpił do ich porównania z tym, co faktycznie ma miejsce.

W przypadku Tłumacza Google, Tłumacza Yandex i Wprowadzania głosowego Google programiści zignorowali pierwszą z wymienionych powyżej wskazówek, co oznacza, że niektóre pliki wymagane przez aplikacje mogły być narażone na atak, powodując awarię aplikacji. LG Application Manager i LG World nie spełniały drugiej z podanych powyżej wytycznych, co sprawiło, że były podatne na działania atakującego, potencjalnie pobierającego alternatywne, niepotrzebne aplikacje zainstalowane za ich pośrednictwem. I wreszcie w Przetwarzaniu tekstu na mowę Google oraz przeglądarce Xiaomi nie zastosowano trzeciej wytycznej podanej powyżej, w związku z czym pozwolono, aby atak typu „Man-in-the-Disk” przejął katalog źródłowy tych aplikacji i spowodował zastąpienie ich plików APK.

Oczywiście należy zauważyć, że im większa liczba uprawnień, do których aplikacja ma dostęp, tym więcej atakujący ma do zyskania. Rzeczywiście wstrzyknięcie kodu do uprzywilejowanej aplikacji powoduje uzyskanie dostępu do wszystkich jej uprawnień. Martwić może fakt, że część aplikacji, w przypadku których stwierdziliśmy podatność na atak typu „Man-in-the-Disk”, jest już zainstalowana fabrycznie przez producentów, wraz ze wstępnie przyznanymi uprawnieniami, na które użytkownik nawet nie wyraził aktywnie zgody, przez co stanowią sposobność dla atakującego na każdym urządzeniu tego producenta

Schemat przyczynowo-skutkowy

Ponieważ szczegóły tego ataku mogą wydawać się skomplikowane, podsumujmy ogólny zarys i konsekwencje ostatnich niedociągnięć systemu Android:

1. Zewnętrzna pamięć masowa urządzenia z systemem Android to obszar publiczny, który może być obserwowany lub modyfikowany przez (szkodliwą) aplikację zewnętrzną.
2. System Android nie posiada wbudowanych zabezpieczeń dla danych przechowywanych w pamięci zewnętrznej, a jedynie proponuje programistom wytyczne dotyczące właściwego korzystania z tego zasobu.
3. Różni programiści nie zawsze orientują się w potrzebach związanych z bezpieczeństwem i potencjalnych zagrożeniach, nie zawsze też stosują się do wytycznych.
4. Wiele zainstalowanych fabrycznie i popularnych aplikacji ignoruje wytyczne dla systemu Android i przechowuje poufne dane w niezabezpieczonej pamięci zewnętrznej.
5. Może to doprowadzić do ataku typu „Man-in-the-Disk”, który może skutkować manipulacją i/lub niewłaściwym wykorzystaniem niezabezpieczonych wrażliwych danych.
6. Modyfikacja danych może prowadzić do niepożądanych rezultatów w urządzeniu użytkownika.

Ochrona przed atakiem typu „Man-in-the-Disk”

O ile jest jasne, że tego rodzaju niedociągnięcia programistyczne sprawiają, że użytkownicy systemu Android są potencjalnie narażeni na zagrożenia cybernetyczne, to już mniej oczywiste jest to, kto naprawdę jest winny i na kim spoczywa odpowiedzialność za ich naprawienie. Z jednej strony, chociaż programiści systemu Android stworzyli wytyczne dla twórców aplikacji, dotyczącego tego, w jaki sposób należy zapewnić bezpieczeństwo aplikacji, muszą mieć również świadomość, że dla programistów bezpieczeństwo nie jest kwestią priorytetową przy tworzeniu aplikacji. Z drugiej strony, mając tego świadomość, możemy zastanowić się, czy Android może zrobić więcej, by chronić swój system operacyjny i urządzenia, które go używają?

Można porównać to, co widzimy w świecie mobilnych systemów operacyjnych, do nieskomplikowanego projektu starych systemów operacyjnych, który pozwalał na przepełnienie bufora, skutkując utratą kontroli. Dopiero gdy luki związane z przepełnieniem bufora były generowane na całym świecie przez nieostrożnych programistów, producenci systemów komputerowych i procesorów zajęli się tym problemem, wprowadzając zabezpieczenia DEP i ASLR i sprawiając, że problem został zażegnany. Dzięki temu przekonaliśmy się, że programistom nie zawsze można ufać w kwestii przestrzegania wytycznych dotyczących bezpieczeństwa.

Z doświadczenia tego wynika, że zwykłe wytyczne nie wystarczą, aby dostawcy systemów operacyjnych mogli uciec od wszelkiej odpowiedzialności za to, co zaprojektowali programiści aplikacji. Zamiast tego zabezpieczenie bazowego systemu operacyjnego jest jedynym długoterminowym rozwiązaniem, które ochroni przed nowymi możliwościami ataku, wykrytymi w naszych badaniach.