mirror of
https://github.com/carlospolop/hacktricks
synced 2025-02-16 22:18:27 +00:00
Translated ['mobile-pentesting/android-app-pentesting/android-applicatio
This commit is contained in:
Translator
parent
08f51fa3a2
commit
74b0491469
1 changed files with 23 additions and 23 deletions
|
|
@ -10,7 +10,7 @@ Ucz się i ćwicz Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-
|
|||
|
||||
* Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
|
||||
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Podziel się trikami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów na GitHubie.
|
||||
* **Podziel się trikami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.
|
||||
|
||||
</details>
|
||||
{% endhint %}
|
||||
|
|
@ -39,17 +39,17 @@ Od Androida 5.0(L) **SELinux** jest egzekwowany. Zasadniczo, SELinux odmawia wsz
|
|||
### Uprawnienia
|
||||
|
||||
Kiedy instalujesz **aplikację i prosi o uprawnienia**, aplikacja prosi o uprawnienia skonfigurowane w elementach **`uses-permission`** w pliku **AndroidManifest.xml**. Element **uses-permission** wskazuje nazwę żądanego uprawnienia w **atrybucie name**. Ma również atrybut **maxSdkVersion**, który przestaje prosić o uprawnienia w wersjach wyższych niż ta określona.\
|
||||
Zauważ, że aplikacje na Androida nie muszą prosić o wszystkie uprawnienia na początku, mogą również **prosić o uprawnienia dynamicznie**, ale wszystkie uprawnienia muszą być **zadeklarowane** w **manifeście**.
|
||||
Zauważ, że aplikacje androidowe nie muszą prosić o wszystkie uprawnienia na początku, mogą również **prosić o uprawnienia dynamicznie**, ale wszystkie uprawnienia muszą być **zadeklarowane** w **manifeście**.
|
||||
|
||||
Kiedy aplikacja ujawnia funkcjonalność, może ograniczyć **dostęp tylko do aplikacji, które mają określone uprawnienie**.\
|
||||
Element uprawnienia ma trzy atrybuty:
|
||||
|
||||
* **nazwa** uprawnienia
|
||||
* atrybut **permission-group**, który pozwala na grupowanie powiązanych uprawnień.
|
||||
* **poziom ochrony**, który wskazuje, jak przyznawane są uprawnienia. Istnieją cztery typy:
|
||||
* **protection-level**, który wskazuje, jak przyznawane są uprawnienia. Istnieją cztery typy:
|
||||
* **Normalne**: Używane, gdy **nie ma znanych zagrożeń** dla aplikacji. Użytkownik **nie musi ich zatwierdzać**.
|
||||
* **Niebezpieczne**: Wskazuje, że uprawnienie przyznaje żądającej aplikacji pewien **podwyższony dostęp**. **Użytkownicy są proszeni o ich zatwierdzenie**.
|
||||
* **Podpis**: Tylko **aplikacje podpisane tym samym certyfikatem, co ten** eksportujący komponent, mogą otrzymać uprawnienie. To najsilniejszy typ ochrony.
|
||||
* **Podpisane**: Tylko **aplikacje podpisane tym samym certyfikatem, co ten** eksportujący komponent, mogą otrzymać uprawnienia. To najsilniejszy typ ochrony.
|
||||
* **SignatureOrSystem**: Tylko **aplikacje podpisane tym samym certyfikatem, co ten** eksportujący komponent lub **aplikacje działające z dostępem na poziomie systemu** mogą otrzymać uprawnienia.
|
||||
|
||||
## Aplikacje wstępnie zainstalowane
|
||||
|
|
@ -82,9 +82,9 @@ Zauważ, że **nie zawsze jest konieczne rootowanie urządzenia**, aby zainstalo
|
|||
|
||||
Gdy urządzenie jest zrootowane, każda aplikacja może żądać dostępu jako root. Jeśli złośliwa aplikacja go uzyska, będzie miała dostęp do prawie wszystkiego i będzie mogła uszkodzić telefon.
|
||||
|
||||
## Podstawy aplikacji na Androida <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>
|
||||
## Podstawy aplikacji Android <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>
|
||||
|
||||
- Format aplikacji na Androida określany jest jako _format pliku APK_. Jest to zasadniczo **plik ZIP** (zmieniając rozszerzenie pliku na .zip, zawartość można wyodrębnić i przeglądać).
|
||||
- Format aplikacji Android określany jest jako _format pliku APK_. Jest to zasadniczo **plik ZIP** (zmieniając rozszerzenie pliku na .zip, zawartość można wyodrębnić i przeglądać).
|
||||
- Zawartość APK (nie wyczerpująca)
|
||||
- **AndroidManifest.xml**
|
||||
- resources.arsc/strings.xml
|
||||
|
|
@ -109,13 +109,13 @@ Gdy urządzenie jest zrootowane, każda aplikacja może żądać dostępu jako r
|
|||
|
||||
W rozwoju Androida, **Java lub Kotlin** jest używane do tworzenia aplikacji. Zamiast używać JVM jak w aplikacjach desktopowych, Android kompiluje ten kod do **bajtkodu Dalvik Executable (DEX)**. Wcześniej, maszyna wirtualna Dalvik obsługiwała ten bajtkod, ale teraz, w nowszych wersjach Androida, przejmuje go Android Runtime (ART).
|
||||
|
||||
W inżynierii odwrotnej, **Smali** staje się kluczowy. To czytelna dla człowieka wersja bajtkodu DEX, działająca jak język asemblera, tłumacząc kod źródłowy na instrukcje bajtkodu. Smali i baksmali odnoszą się do narzędzi asemblera i deasemblacji w tym kontekście.
|
||||
W inżynierii odwrotnej, **Smali** staje się kluczowe. To czytelna dla człowieka wersja bajtkodu DEX, działająca jak język asemblera, tłumacząc kod źródłowy na instrukcje bajtkodu. Smali i baksmali odnoszą się do narzędzi asemblera i deasemblacji w tym kontekście.
|
||||
|
||||
## Intencje
|
||||
|
||||
Intencje są podstawowym sposobem, w jaki aplikacje Android komunikują się między swoimi komponentami lub z innymi aplikacjami. Te obiekty wiadomości mogą również przenosić dane między aplikacjami lub komponentami, podobnie jak żądania GET/POST są używane w komunikacji HTTP.
|
||||
Intencje są głównym sposobem, w jaki aplikacje Android komunikują się między swoimi komponentami lub z innymi aplikacjami. Te obiekty wiadomości mogą również przenosić dane między aplikacjami lub komponentami, podobnie jak żądania GET/POST są używane w komunikacji HTTP.
|
||||
|
||||
Intencja to zasadniczo **wiadomość, która jest przekazywana między komponentami**. Intencje **mogą być kierowane** do konkretnych komponentów lub aplikacji, **lub mogą być wysyłane bez konkretnego odbiorcy**.\
|
||||
Tak więc intencja to zasadniczo **wiadomość, która jest przekazywana między komponentami**. Intencje **mogą być kierowane** do konkretnych komponentów lub aplikacji, **lub mogą być wysyłane bez konkretnego odbiorcy**.\
|
||||
Aby uprościć, intencja może być używana:
|
||||
|
||||
* Do uruchamiania aktywności, zazwyczaj otwierając interfejs użytkownika dla aplikacji
|
||||
|
|
@ -132,7 +132,7 @@ Jeśli są podatne, **intencje mogą być używane do przeprowadzania różnych
|
|||
|
||||
Filtry intencji składają się z kategorii, akcji i filtrów danych, z możliwością dodania dodatkowych metadanych. Ta konfiguracja pozwala komponentom obsługiwać konkretne intencje, które pasują do zadeklarowanych kryteriów.
|
||||
|
||||
Krytycznym aspektem komponentów Androida (aktywności/usługi/dostawcy treści/odbiorniki transmisji) jest ich widoczność lub **status publiczny**. Komponent jest uważany za publiczny i może interagować z innymi aplikacjami, jeśli jest **`exported`** z wartością **`true`** lub jeśli dla niego w manifeście zadeklarowano filtr intencji. Istnieje jednak sposób, aby deweloperzy wyraźnie zachowali te komponenty prywatne, zapewniając, że nie będą interagować z innymi aplikacjami niezamierzenie. Osiąga się to poprzez ustawienie atrybutu **`exported`** na **`false`** w ich definicjach manifestu.
|
||||
Krytycznym aspektem komponentów Androida (aktywności/usługi/dostawcy treści/odbiorniki transmisji) jest ich widoczność lub **status publiczny**. Komponent jest uważany za publiczny i może interagować z innymi aplikacjami, jeśli jest **`exported`** z wartością **`true`** lub jeśli dla niego w manifeście zadeklarowano filtr intencji. Istnieje jednak sposób, aby deweloperzy wyraźnie zachowali te komponenty jako prywatne, zapewniając, że nie będą interagować z innymi aplikacjami niezamierzenie. Osiąga się to poprzez ustawienie atrybutu **`exported`** na **`false`** w ich definicjach manifestu.
|
||||
|
||||
Ponadto, deweloperzy mają możliwość dalszego zabezpieczenia dostępu do tych komponentów, wymagając określonych uprawnień. Atrybut **`permission`** może być ustawiony, aby wymusić, że tylko aplikacje z wyznaczonym uprawnieniem mogą uzyskać dostęp do komponentu, dodając dodatkową warstwę bezpieczeństwa i kontroli nad tym, kto może z nim interagować.
|
||||
```java
|
||||
|
|
@ -146,7 +146,7 @@ Intencje są programowo tworzone za pomocą konstruktora Intent:
|
|||
```java
|
||||
Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));
|
||||
```
|
||||
The **Action** of the previously declared intent is **ACTION\_SEND** and the **Extra** is a mailto **Uri** (the Extra if the extra information the intent is expecting).
|
||||
The **Action** wcześniej zadeklarowanego zamiaru to **ACTION\_SEND**, a **Extra** to mailto **Uri** (Extra to dodatkowe informacje, których oczekuje zamiar).
|
||||
|
||||
Ten zamiar powinien być zadeklarowany w manifeście, jak w następującym przykładzie:
|
||||
```xml
|
||||
|
|
@ -179,18 +179,18 @@ Te pozwalają innym aplikacjom **podejmować działania w imieniu twojej aplikac
|
|||
|
||||
### Broadcast Intents
|
||||
|
||||
W przeciwieństwie do poprzednich intencji, które są odbierane tylko przez jedną aplikację, intencje rozgłoszeniowe **mogą być odbierane przez wiele aplikacji**. Jednak od wersji API 14, **możliwe jest określenie aplikacji, która powinna otrzymać** wiadomość, używając Intent.setPackage.
|
||||
W przeciwieństwie do poprzednich intencji, które są odbierane tylko przez jedną aplikację, intencje broadcast **mogą być odbierane przez wiele aplikacji**. Jednak od wersji API 14, **możliwe jest określenie aplikacji, która powinna otrzymać** wiadomość, używając Intent.setPackage.
|
||||
|
||||
Alternatywnie, możliwe jest również **określenie uprawnienia podczas wysyłania rozgłoszenia**. Aplikacja odbierająca będzie musiała mieć to uprawnienie.
|
||||
Alternatywnie, możliwe jest również **określenie uprawnienia podczas wysyłania broadcastu**. Aplikacja odbierająca będzie musiała mieć to uprawnienie.
|
||||
|
||||
Istnieją **dwa typy** rozgłoszeń: **Normalne** (asynchroniczne) i **Zamówione** (synchronizowane). **Kolejność** opiera się na **skonfigurowanym priorytecie w elemencie odbiorcy**. **Każda aplikacja może przetwarzać, przekazywać lub odrzucać rozgłoszenie.**
|
||||
Istnieją **dwa typy** broadcastów: **Normalne** (asynchroniczne) i **Zamówione** (synchronizowane). **Kolejność** opiera się na **skonfigurowanym priorytecie w elemencie odbiorcy**. **Każda aplikacja może przetwarzać, przekazywać lub odrzucać broadcast.**
|
||||
|
||||
Możliwe jest **wysłanie** **rozgłoszenia** za pomocą funkcji `sendBroadcast(intent, receiverPermission)` z klasy `Context`.\
|
||||
Możliwe jest **wysłanie** **broadcastu** za pomocą funkcji `sendBroadcast(intent, receiverPermission)` z klasy `Context`.\
|
||||
Możesz również użyć funkcji **`sendBroadcast`** z **`LocalBroadCastManager`**, która zapewnia, że **wiadomość nigdy nie opuszcza aplikacji**. Używając tego, nie będziesz nawet musiał eksportować komponentu odbiorcy.
|
||||
|
||||
### Sticky Broadcasts
|
||||
|
||||
Ten rodzaj rozgłoszeń **może być dostępny długo po ich wysłaniu**.\
|
||||
Ten rodzaj broadcastów **może być dostępny długo po ich wysłaniu**.\
|
||||
Zostały one wycofane w poziomie API 21 i zaleca się **nie używać ich**.\
|
||||
**Pozwalają każdej aplikacji na podsłuchiwanie danych, ale także na ich modyfikację.**
|
||||
|
||||
|
|
@ -212,7 +212,7 @@ Schemat musi być zadeklarowany w pliku **`AndroidManifest.xml`**:
|
|||
</intent-filter>
|
||||
[...]
|
||||
```
|
||||
Schemat z poprzedniego przykładu to `exampleapp://` (zauważ również **`category BROWSABLE`**)
|
||||
Schemat z poprzedniego przykładu to `examplescheme://` (zauważ również **`kategoria BROWSABLE`**)
|
||||
|
||||
Następnie, w polu danych, możesz określić **host** i **path**:
|
||||
```xml
|
||||
|
|
@ -231,7 +231,7 @@ Dowiedz się, jak [wywoływać deep linki bez użycia stron HTML](./#exploiting-
|
|||
|
||||
## AIDL - Android Interface Definition Language
|
||||
|
||||
**Android Interface Definition Language (AIDL)** jest zaprojektowany w celu ułatwienia komunikacji między klientem a usługą w aplikacjach Android poprzez **komunikację międzyprocesową** (IPC). Ponieważ bezpośredni dostęp do pamięci innego procesu nie jest dozwolony w Androidzie, AIDL upraszcza ten proces, marshalling obiektów do formatu zrozumiałego dla systemu operacyjnego, co ułatwia komunikację między różnymi procesami.
|
||||
**Android Interface Definition Language (AIDL)** jest zaprojektowany w celu ułatwienia komunikacji między klientem a usługą w aplikacjach Android poprzez **interprocess communication** (IPC). Ponieważ bezpośredni dostęp do pamięci innego procesu nie jest dozwolony w Androidzie, AIDL upraszcza ten proces, marshalling obiektów do formatu zrozumiałego dla systemu operacyjnego, co ułatwia komunikację między różnymi procesami.
|
||||
|
||||
### Kluczowe pojęcia
|
||||
|
||||
|
|
@ -243,7 +243,7 @@ Dowiedz się, jak [wywoływać deep linki bez użycia stron HTML](./#exploiting-
|
|||
|
||||
## Komponenty
|
||||
|
||||
Należą do nich: **Aktywności, Usługi, Odbiorniki Rozgłoszeniowe i Dostawcy.**
|
||||
Obejmują: **Aktywności, Usługi, Odbiorniki Rozgłoszeniowe i Dostawcy.**
|
||||
|
||||
### Aktywność uruchamiająca i inne aktywności
|
||||
|
||||
|
|
@ -260,7 +260,7 @@ W aplikacjach Android **aktywności** są jak ekrany, pokazujące różne częś
|
|||
```
|
||||
Nie wszystkie aplikacje potrzebują aktywności uruchamiającej, szczególnie te bez interfejsu użytkownika, takie jak usługi w tle.
|
||||
|
||||
Aktywności mogą być udostępniane innym aplikacjom lub procesom, oznaczając je jako "exported" w manifeście. To ustawienie pozwala innym aplikacjom na uruchomienie tej aktywności:
|
||||
Aktywności mogą być udostępniane innym aplikacjom lub procesom poprzez oznaczenie ich jako "exported" w manifeście. To ustawienie pozwala innym aplikacjom na uruchomienie tej aktywności:
|
||||
```markdown
|
||||
<service android:name=".ExampleExportedService" android:exported="true"/>
|
||||
```
|
||||
|
|
@ -290,7 +290,7 @@ super.onCreate();
|
|||
|
||||
[Usługi](https://developer.android.com/guide/components/services) to **operacje w tle**, które mogą wykonywać zadania bez interfejsu użytkownika. Te zadania mogą kontynuować działanie nawet wtedy, gdy użytkownicy przełączają się na różne aplikacje, co sprawia, że usługi są kluczowe dla **długoterminowych operacji**.
|
||||
|
||||
Usługi są wszechstronne; mogą być inicjowane na różne sposoby, przy czym **Intents** są główną metodą ich uruchamiania jako punktu wejścia aplikacji. Gdy usługa jest uruchamiana za pomocą metody `startService`, jej metoda `onStart` zaczyna działać i działa aż do momentu, gdy metoda `stopService` zostanie wywołana. Alternatywnie, jeśli rola usługi zależy od aktywnego połączenia z klientem, używana jest metoda `bindService` do powiązania klienta z usługą, angażując metodę `onBind` do przesyłania danych.
|
||||
Usługi są wszechstronne; mogą być inicjowane na różne sposoby, przy czym **Intents** są główną metodą ich uruchamiania jako punkt wejścia aplikacji. Gdy usługa jest uruchamiana za pomocą metody `startService`, jej metoda `onStart` zaczyna działać i działa aż do momentu, gdy metoda `stopService` zostanie wywołana. Alternatywnie, jeśli rola usługi zależy od aktywnego połączenia z klientem, używana jest metoda `bindService` do powiązania klienta z usługą, angażując metodę `onBind` do przesyłania danych.
|
||||
|
||||
Ciekawym zastosowaniem usług jest odtwarzanie muzyki w tle lub pobieranie danych z sieci bez zakłócania interakcji użytkownika z aplikacją. Ponadto, usługi mogą być udostępniane innym procesom na tym samym urządzeniu poprzez **eksportowanie**. Nie jest to domyślne zachowanie i wymaga wyraźnej konfiguracji w pliku manifestu Androida:
|
||||
```xml
|
||||
|
|
@ -308,7 +308,7 @@ Aby zrozumieć funkcjonalność odbiornika, należy poszukać metody **`onReceiv
|
|||
|
||||
### Content Provider
|
||||
|
||||
**Content Providers** są niezbędne do **dzielenia się danymi strukturalnymi** między aplikacjami, podkreślając znaczenie wdrażania **uprawnień** w celu zapewnienia bezpieczeństwa danych. Umożliwiają aplikacjom dostęp do danych z różnych źródeł, w tym baz danych, systemów plików lub internetu. Specyficzne uprawnienia, takie jak **`readPermission`** i **`writePermission`**, są kluczowe dla kontrolowania dostępu. Dodatkowo, tymczasowy dostęp może być przyznany za pomocą ustawień **`grantUriPermission`** w manifeście aplikacji, wykorzystując atrybuty takie jak `path`, `pathPrefix` i `pathPattern` do szczegółowej kontroli dostępu.
|
||||
**Content Providers** są niezbędne do **dzielenia się danymi strukturalnymi** między aplikacjami, podkreślając znaczenie wdrażania **uprawnień** w celu zapewnienia bezpieczeństwa danych. Umożliwiają aplikacjom dostęp do danych z różnych źródeł, w tym baz danych, systemów plików lub internetu. Specyficzne uprawnienia, takie jak **`readPermission`** i **`writePermission`**, są kluczowe dla kontrolowania dostępu. Dodatkowo, tymczasowy dostęp może być przyznany poprzez ustawienia **`grantUriPermission`** w manifeście aplikacji, wykorzystując atrybuty takie jak `path`, `pathPrefix` i `pathPattern` do szczegółowej kontroli dostępu.
|
||||
|
||||
Walidacja danych jest kluczowa, aby zapobiec lukom w zabezpieczeniach, takim jak SQL injection. Content Providers wspierają podstawowe operacje: `insert()`, `update()`, `delete()`, i `query()`, ułatwiając manipulację danymi i ich udostępnianie między aplikacjami.
|
||||
|
||||
|
|
@ -366,7 +366,7 @@ Aby kontrolować dostęp do plików:
|
|||
|
||||
### **Mobile Device Management (MDM)**
|
||||
|
||||
- **Rozwiązania MDM** zapewniają **nadzór i bezpieczeństwo** dla urządzeń mobilnych poprzez **API administracji urządzeniami**. Wymagają one zainstalowania aplikacji Android, aby skutecznie zarządzać i zabezpieczać urządzenia mobilne. Kluczowe funkcje obejmują **egzekwowanie polityk haseł**, **wymuszanie szyfrowania pamięci** oraz **zezwalanie na zdalne usuwanie danych**, zapewniając kompleksową kontrolę i bezpieczeństwo nad urządzeniami mobilnymi.
|
||||
- **Rozwiązania MDM** zapewniają **nadzór i bezpieczeństwo** dla urządzeń mobilnych poprzez **API administracji urządzeniami**. Wymagają one zainstalowania aplikacji Android do skutecznego zarządzania i zabezpieczania urządzeń mobilnych. Kluczowe funkcje obejmują **egzekwowanie polityk haseł**, **wymuszanie szyfrowania pamięci** oraz **zezwalanie na zdalne usuwanie danych**, zapewniając kompleksową kontrolę i bezpieczeństwo nad urządzeniami mobilnymi.
|
||||
```java
|
||||
// Example of enforcing a password policy with MDM
|
||||
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue