Struktura aplikacji Android

Aplikacja na Androida jest dostarczana jako APK (Android Package). W rzeczywistości jest to archiwum ZIP zawierające skompilowany kod, zasoby i metadane.

Ponieważ jest to plik ZIP, można go po prostu rozpakować i przejrzeć zawartość, co stanowi pierwszy krok w testach penetracyjnych aplikacji mobilnych.

Rozpakowany plik APK zawiera:

• AndroidManifest.xml: konfigurację aplikacji.
• classes.dex: skompilowany kod bajtowy.
• res/ i resources.arsc: zasoby.
• lib/: biblioteki natywne.
• META-INF/: informacje o podpisie.

Plik AndroidManifest.xml deklaruje komponenty, uprawnienia i konfigurację aplikacji. W pliku APK ma postać binarnego XML, który można zdekodować za pomocą odpowiednich narzędzi.

Jest to najważniejszy pojedynczy plik pozwalający zrozumieć powierzchnię ataku aplikacji.

Źródła w językach Java/Kotlin są kompilowane do kodu bajtowego DEX (Dalvik Executable) w pliku classes.dex. Współczesny Android uruchamia go za pośrednictwem ART (Android Runtime).

DEX można przekształcić z powrotem w kierunku czytelnego kodu, co wykorzystuje się w analizie statycznej plików APK.

Aplikacje na Androida są zbudowane z czterech typów komponentów:

• Activities: ekrany i interfejs użytkownika.
• Services: zadania wykonywane w tle.
• Broadcast Receivers: reagują na zdarzenia systemowe.
• Content Providers: udostępniają dane między aplikacjami.

Komponent oznaczony jako android:exported="true" może być wywoływany przez inne aplikacje. Jeśli taki komponent wykonuje wrażliwe działania bez kontroli, stanowi powierzchnię ataku.

Testerzy penetracyjni wyszukują eksportowane aktywności, usługi i dostawców treści, które ujawniają dane lub wykonują uprzywilejowane działania.

Aplikacje żądają uprawnień w manifeście (na przykład INTERNET, READ_SMS, ACCESS_FINE_LOCATION).

Zbyt szerokie uprawnienia mogą wskazywać na ryzykowne zachowanie lub nadmierny dostęp do danych. Niestandardowe uprawnienia również mogą być błędnie skonfigurowane i umożliwiać nieuprawniony dostęp.

Android izoluje każdą aplikację we własnej piaskownicy z unikatowym identyfikatorem UID systemu Linux. Domyślnie aplikacje nie mogą odczytywać danych należących do siebie nawzajem.

Podatności powstają, gdy aplikacje osłabiają tę granicę, na przykład udostępniając pliki do odczytu dla wszystkich lub ujawniając dostawców treści.

Zainstalowana aplikacja przechowuje prywatne dane w katalogu /data/data/<package>/: bazy danych, preferencje współdzielone i pliki.

Na zrootowanym urządzeniu lub za pośrednictwem kopii zapasowych tester penetracyjny sprawdza ten katalog pod kątem niebezpiecznie przechowywanych sekretów, co omawia późniejsza lekcja.

Każdy plik APK jest cyfrowo podpisany; podpis znajduje się w katalogu META-INF/. Android weryfikuje go podczas instalacji i aktualizacji.

Po zmodyfikowaniu i ponownym spakowaniu aplikacji trzeba podpisać ją ponownie, dlatego deweloperzy polegają na podpisach przy wykrywaniu manipulacji.

Logika wymagająca wysokiej wydajności lub zaciemniona może znajdować się w bibliotekach natywnych (plikach .so) w katalogu lib/, skompilowanych z języka C/C++.

Nie znajdują się one w DEX, dlatego wymagają osobnej analizy za pomocą natywnych dezasemblerów. Deweloperzy czasem ukrywają tu sekrety, błędnie zakładając, że kod natywny jest trudniejszy do zbadania.

Proszę przypomnieć sobie, który atrybut manifestu udostępnia komponent innym aplikacjom.

Znają już Państwo strukturę aplikacji na Androida:

• APK to plik ZIP zawierający AndroidManifest.xml, classes.dex, zasoby i dane dotyczące podpisu.
• Aplikacje korzystają z czterech komponentów; eksportowane komponenty stanowią powierzchnię ataku.
• Uprawnienia i osobna dla każdej aplikacji piaskownica określają zasady dostępu; prywatne dane znajdują się w /data/data/.
• Pliki APK są podpisywane w celu wykrywania manipulacji.

W następnej części przeprowadzą Państwo dekompilację pliku APK w ramach analizy statycznej.