mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/mobile-pentesting/android-app-pentesting/android-applic
This commit is contained in:
parent
0f603a88c9
commit
800231fdd8
@ -7,7 +7,7 @@
|
||||
**Es gibt zwei Ebenen:**
|
||||
|
||||
- Das **Betriebssystem**, das installierte Anwendungen voneinander isoliert.
|
||||
- Die **Anwendung selbst**, die es Entwicklern ermöglicht, **bestimmte Funktionen** freizugeben und die Anwendungsfähigkeiten zu konfigurieren.
|
||||
- Die **Anwendung selbst**, die es Entwicklern ermöglicht, **bestimmte Funktionen freizugeben** und die Anwendungsfähigkeiten zu konfigurieren.
|
||||
|
||||
### UID-Trennung
|
||||
|
||||
@ -25,7 +25,7 @@ Seit Android 5.0(L) wird **SELinux** durchgesetzt. Grundsätzlich verweigerte SE
|
||||
|
||||
### Berechtigungen
|
||||
|
||||
Wenn Sie eine **App installieren und sie nach Berechtigungen fragt**, fragt die App nach den Berechtigungen, die in den **`uses-permission`**-Elementen in der **AndroidManifest.xml**-Datei konfiguriert sind. Das **uses-permission**-Element gibt den Namen der angeforderten Berechtigung im **name**-Attribut an. Es hat auch das **maxSdkVersion**-Attribut, das das Anfordern von Berechtigungen in Versionen über der angegebenen stoppt.\
|
||||
Wenn Sie eine **App installieren und sie nach Berechtigungen fragt**, fragt die App nach den Berechtigungen, die in den **`uses-permission`**-Elementen in der **AndroidManifest.xml**-Datei konfiguriert sind. Das **uses-permission**-Element gibt den Namen der angeforderten Berechtigung im **name**-Attribut an. Es hat auch das **maxSdkVersion**-Attribut, das das Anfordern von Berechtigungen in höheren Versionen als der angegebenen stoppt.\
|
||||
Beachten Sie, dass Android-Anwendungen nicht alle Berechtigungen zu Beginn anfordern müssen; sie können auch **dynamisch nach Berechtigungen fragen**, aber alle Berechtigungen müssen im **Manifest** **deklarieren**.
|
||||
|
||||
Wenn eine App Funktionen freigibt, kann sie den **Zugriff nur auf Apps beschränken, die über eine bestimmte Berechtigung verfügen**.\
|
||||
@ -37,20 +37,20 @@ Ein Berechtigungselement hat drei Attribute:
|
||||
- **Normal**: Wird verwendet, wenn es **keine bekannten Bedrohungen** für die App gibt. Der Benutzer muss **es nicht genehmigen**.
|
||||
- **Dangerous**: Gibt an, dass die Berechtigung der anfordernden Anwendung einen **erhöhten Zugriff** gewährt. **Benutzer werden gebeten, sie zu genehmigen**.
|
||||
- **Signature**: Nur **Apps, die mit demselben Zertifikat wie das, das die Komponente exportiert, signiert sind**, können die Berechtigung erhalten. Dies ist die stärkste Art des Schutzes.
|
||||
- **SignatureOrSystem**: Nur **Apps, die mit demselben Zertifikat wie das, das die Komponente exportiert, signiert sind**, oder **Apps, die mit Systemzugriffsrechten ausgeführt werden**, können Berechtigungen erhalten.
|
||||
- **SignatureOrSystem**: Nur **Apps, die mit demselben Zertifikat wie das, das die Komponente exportiert, signiert sind, oder **Apps, die mit Systemzugriff ausgeführt werden**, können Berechtigungen erhalten.
|
||||
|
||||
## Vorinstallierte Anwendungen
|
||||
|
||||
Diese Apps befinden sich normalerweise in den **`/system/app`**- oder **`/system/priv-app`**-Verzeichnissen, und einige von ihnen sind **optimiert** (Sie finden möglicherweise nicht einmal die `classes.dex`-Datei). Diese Anwendungen sind es wert, überprüft zu werden, da sie manchmal **mit zu vielen Berechtigungen** (als Root) ausgeführt werden.
|
||||
Diese Apps befinden sich normalerweise in den **`/system/app`** oder **`/system/priv-app`** Verzeichnissen, und einige von ihnen sind **optimiert** (Sie finden möglicherweise nicht einmal die `classes.dex`-Datei). Diese Anwendungen sind es wert, überprüft zu werden, da sie manchmal **mit zu vielen Berechtigungen** (als Root) **ausgeführt werden**.
|
||||
|
||||
- Die mit dem **AOSP** (Android OpenSource Project) **ROM** gelieferten
|
||||
- Vom Gerätehersteller hinzugefügt
|
||||
- Vom Mobilfunkanbieter hinzugefügt (wenn sie von ihnen gekauft wurden)
|
||||
|
||||
## Rooten
|
||||
## Rooting
|
||||
|
||||
Um Root-Zugriff auf ein physisches Android-Gerät zu erhalten, müssen Sie in der Regel 1 oder 2 **Schwachstellen** **ausnutzen**, die normalerweise **spezifisch** für das **Gerät** und die **Version** sind.\
|
||||
Sobald der Exploit funktioniert hat, wird normalerweise die Linux `su`-Binärdatei an einem im PATH-Umgebungsvariablen des Benutzers angegebenen Ort wie `/system/xbin` kopiert.
|
||||
Sobald der Exploit funktioniert hat, wird normalerweise die Linux `su`-Binärdatei an einem Ort kopiert, der in der PATH-Umgebungsvariable des Benutzers angegeben ist, wie z.B. `/system/xbin`.
|
||||
|
||||
Sobald die su-Binärdatei konfiguriert ist, wird eine andere Android-App verwendet, um mit der `su`-Binärdatei zu interagieren und **Anfragen für Root-Zugriff** wie **Superuser** und **SuperSU** (verfügbar im Google Play Store) zu verarbeiten.
|
||||
|
||||
@ -60,13 +60,13 @@ Sobald die su-Binärdatei konfiguriert ist, wird eine andere Android-App verwend
|
||||
### ROMs
|
||||
|
||||
Es ist möglich, das **Betriebssystem durch die Installation einer benutzerdefinierten Firmware zu ersetzen**. Dadurch ist es möglich, die Nützlichkeit eines alten Geräts zu erweitern, Softwarebeschränkungen zu umgehen oder Zugriff auf den neuesten Android-Code zu erhalten.\
|
||||
**OmniROM** und **LineageOS** sind zwei der beliebtesten Firmwares.
|
||||
**OmniROM** und **LineageOS** sind zwei der beliebtesten Firmwares, die verwendet werden können.
|
||||
|
||||
Beachten Sie, dass **es nicht immer notwendig ist, das Gerät zu rooten**, um eine benutzerdefinierte Firmware zu installieren. **Einige Hersteller erlauben** das Entsperren ihrer Bootloader auf eine gut dokumentierte und sichere Weise.
|
||||
|
||||
### Auswirkungen
|
||||
|
||||
Sobald ein Gerät gerootet ist, könnte jede App Zugriff als Root anfordern. Wenn eine bösartige Anwendung dies erhält, hat sie Zugriff auf fast alles und kann das Telefon beschädigen.
|
||||
Sobald ein Gerät gerootet ist, kann jede App Zugriff als Root anfordern. Wenn eine bösartige Anwendung dies erhält, hat sie Zugriff auf fast alles und kann das Telefon beschädigen.
|
||||
|
||||
## Grundlagen von Android-Anwendungen <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>
|
||||
|
||||
@ -106,8 +106,8 @@ Einfach gesagt, kann ein Intent verwendet werden:
|
||||
|
||||
- Um eine Aktivität zu starten, typischerweise um eine Benutzeroberfläche für eine App zu öffnen
|
||||
- Als Broadcasts, um das System und Apps über Änderungen zu informieren
|
||||
- Um einen Hintergrunddienst zu starten, zu stoppen und mit ihm zu kommunizieren
|
||||
- Um auf Daten über ContentProviders zuzugreifen
|
||||
- Um mit einem Hintergrunddienst zu starten, zu stoppen und zu kommunizieren
|
||||
- Um über ContentProviders auf Daten zuzugreifen
|
||||
- Als Rückrufe zur Behandlung von Ereignissen
|
||||
|
||||
Wenn sie anfällig sind, **können Intents verwendet werden, um eine Vielzahl von Angriffen durchzuführen**.
|
||||
@ -116,11 +116,11 @@ Wenn sie anfällig sind, **können Intents verwendet werden, um eine Vielzahl vo
|
||||
|
||||
**Intent-Filter** definieren, **wie eine Aktivität, ein Dienst oder ein Broadcast-Empfänger mit verschiedenen Arten von Intents interagieren kann**. Im Wesentlichen beschreiben sie die Fähigkeiten dieser Komponenten, wie z.B. welche Aktionen sie ausführen können oder welche Arten von Broadcasts sie verarbeiten können. Der primäre Ort, um diese Filter zu deklarieren, ist innerhalb der **AndroidManifest.xml-Datei**, obwohl es auch eine Option ist, sie für Broadcast-Empfänger zu codieren.
|
||||
|
||||
Intent-Filter bestehen aus Kategorien, Aktionen und Datenfiltern, mit der Möglichkeit, zusätzliche Metadaten einzuschließen. Diese Konfiguration ermöglicht es Komponenten, spezifische Intents zu verarbeiten, die den deklarierten Kriterien entsprechen.
|
||||
Intent-Filter bestehen aus Kategorien, Aktionen und Datenfiltern, mit der Möglichkeit, zusätzliche Metadaten einzuschließen. Diese Einrichtung ermöglicht es Komponenten, spezifische Intents zu verarbeiten, die den deklarierten Kriterien entsprechen.
|
||||
|
||||
Ein kritischer Aspekt von Android-Komponenten (Aktivitäten/Dienste/Inhaltsanbieter/Broadcast-Empfänger) ist ihre Sichtbarkeit oder **öffentlicher Status**. Eine Komponente wird als öffentlich betrachtet und kann mit anderen Apps interagieren, wenn sie **`exported`** mit einem Wert von **`true`** ist oder wenn ein Intent-Filter für sie im Manifest deklariert ist. Es gibt jedoch eine Möglichkeit für Entwickler, diese Komponenten ausdrücklich privat zu halten, um sicherzustellen, dass sie nicht unbeabsichtigt mit anderen Apps interagieren. Dies wird erreicht, indem das **`exported`**-Attribut in ihren Manifestdefinitionen auf **`false`** gesetzt wird.
|
||||
|
||||
Darüber hinaus haben Entwickler die Möglichkeit, den Zugriff auf diese Komponenten weiter abzusichern, indem sie spezifische Berechtigungen verlangen. Das **`permission`**-Attribut kann so eingestellt werden, dass nur Apps mit der vorgesehenen Berechtigung auf die Komponente zugreifen können, was eine zusätzliche Sicherheitsebene und Kontrolle darüber bietet, wer mit ihr interagieren kann.
|
||||
Darüber hinaus haben Entwickler die Möglichkeit, den Zugriff auf diese Komponenten weiter abzusichern, indem sie spezifische Berechtigungen verlangen. Das **`permission`**-Attribut kann so festgelegt werden, dass nur Apps mit der vorgesehenen Berechtigung auf die Komponente zugreifen können, was eine zusätzliche Sicherheitsebene und Kontrolle darüber hinzufügt, wer mit ihr interagieren kann.
|
||||
```java
|
||||
<activity android:name=".MyActivity" android:exported="false">
|
||||
<!-- Intent filters go here -->
|
||||
@ -145,7 +145,7 @@ Dieser Intent sollte im Manifest wie im folgenden Beispiel deklariert werden:
|
||||
```
|
||||
Ein intent-filter muss die **Aktion**, **Daten** und **Kategorie** übereinstimmen, um eine Nachricht zu empfangen.
|
||||
|
||||
Der Prozess der "Intent-Auflösung" bestimmt, welche App jede Nachricht empfangen soll. Dieser Prozess berücksichtigt das **Prioritätsattribut**, das in der **intent-filter-Deklaration** festgelegt werden kann, und **diejenige mit der höheren Priorität wird ausgewählt**. Diese Priorität kann zwischen -1000 und 1000 festgelegt werden, und Anwendungen können den Wert `SYSTEM_HIGH_PRIORITY` verwenden. Wenn ein **Konflikt** auftritt, erscheint ein "Wähler"-Fenster, damit der **Benutzer entscheiden kann**.
|
||||
Der Prozess der "Intent-Auflösung" bestimmt, welche App jede Nachricht empfangen soll. Dieser Prozess berücksichtigt das **Prioritätsattribut**, das in der **intent-filter-Deklaration** festgelegt werden kann, und **die mit der höheren Priorität wird ausgewählt**. Diese Priorität kann zwischen -1000 und 1000 festgelegt werden, und Anwendungen können den Wert `SYSTEM_HIGH_PRIORITY` verwenden. Wenn ein **Konflikt** auftritt, erscheint ein "Wähler"-Fenster, damit der **Benutzer entscheiden kann**.
|
||||
|
||||
### Explizite Intents
|
||||
|
||||
@ -161,7 +161,7 @@ context.startService(intent);
|
||||
```
|
||||
### Pending Intents
|
||||
|
||||
Diese ermöglichen es anderen Anwendungen, **Aktionen im Namen Ihrer Anwendung auszuführen**, unter Verwendung der Identität und Berechtigungen Ihrer App. Beim Erstellen eines Pending Intent sollte **ein Intent und die auszuführende Aktion angegeben werden**. Wenn der **deklarierte Intent nicht explizit** ist (nicht angibt, welcher Intent ihn aufrufen kann), könnte eine **bösartige Anwendung die deklarierte Aktion** im Namen der Opfer-App ausführen. Darüber hinaus, **wenn keine Aktion angegeben ist**, kann die bösartige App **jede Aktion im Namen des Opfers** durchführen.
|
||||
Diese ermöglichen es anderen Anwendungen, **Aktionen im Namen Ihrer Anwendung auszuführen**, unter Verwendung der Identität und Berechtigungen Ihrer App. Um einen Pending Intent zu erstellen, sollte **ein Intent und die auszuführende Aktion angegeben werden**. Wenn der **deklarierte Intent nicht explizit** ist (nicht angibt, welcher Intent ihn aufrufen kann), könnte eine **bösartige Anwendung die deklarierte Aktion** im Namen der Opfer-App ausführen. Darüber hinaus, **wenn keine Aktion angegeben ist**, kann die bösartige App **jede Aktion im Namen des Opfers** durchführen.
|
||||
|
||||
### Broadcast Intents
|
||||
|
||||
@ -178,7 +178,7 @@ Sie können auch die Funktion **`sendBroadcast`** von **`LocalBroadCastManager`*
|
||||
|
||||
Diese Art von Broadcasts **kann lange nach dem Senden abgerufen werden**.\
|
||||
Diese wurden in API-Stufe 21 als veraltet erklärt und es wird empfohlen, **sie nicht zu verwenden**.\
|
||||
**Sie ermöglichen es jeder Anwendung, die Daten abzuhören, aber auch zu ändern.**
|
||||
**Sie ermöglichen es jeder Anwendung, die Daten abzuhören, aber auch sie zu ändern.**
|
||||
|
||||
Wenn Sie Funktionen finden, die das Wort "sticky" enthalten, wie **`sendStickyBroadcast`** oder **`sendStickyBroadcastAsUser`**, **prüfen Sie die Auswirkungen und versuchen Sie, sie zu entfernen**.
|
||||
|
||||
@ -200,32 +200,32 @@ Das Schema muss in der **`AndroidManifest.xml`**-Datei deklariert werden:
|
||||
```
|
||||
Das Schema aus dem vorherigen Beispiel ist `examplescheme://` (beachten Sie auch die **`category BROWSABLE`**)
|
||||
|
||||
Dann können Sie im Datenfeld den **host** und den **path** angeben:
|
||||
Dann können Sie im Datenfeld den **Host** und den **Pfad** angeben:
|
||||
```xml
|
||||
<data android:scheme="examplescheme"
|
||||
android:host="example"
|
||||
/>
|
||||
```
|
||||
Um von einer Webseite darauf zuzugreifen, ist es möglich, einen Link wie folgt zu setzen:
|
||||
Um von einer Webseite darauf zuzugreifen, ist es möglich, einen Link wie folgt festzulegen:
|
||||
```xml
|
||||
<a href="examplescheme://example/something">click here</a>
|
||||
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>
|
||||
```
|
||||
Um den **Code zu finden, der in der App ausgeführt wird**, gehen Sie zur Aktivität, die durch den Deeplink aufgerufen wird, und suchen Sie die Funktion **`onNewIntent`**.
|
||||
Um den **Code zu finden, der in der App ausgeführt wird**, gehen Sie zu der Aktivität, die durch den Deeplink aufgerufen wird, und suchen Sie die Funktion **`onNewIntent`**.
|
||||
|
||||
Erfahren Sie, wie Sie [Deep Links ohne Verwendung von HTML-Seiten aufrufen](#exploiting-schemes-deep-links).
|
||||
|
||||
## AIDL - Android Interface Definition Language
|
||||
|
||||
Die **Android Interface Definition Language (AIDL)** wurde entwickelt, um die Kommunikation zwischen Client und Dienst in Android-Anwendungen durch **Interprozesskommunikation** (IPC) zu erleichtern. Da der direkte Zugriff auf den Speicher eines anderen Prozesses auf Android nicht erlaubt ist, vereinfacht AIDL den Prozess, indem Objekte in ein vom Betriebssystem verstandenes Format umgewandelt werden, wodurch die Kommunikation zwischen verschiedenen Prozessen erleichtert wird.
|
||||
Die **Android Interface Definition Language (AIDL)** wurde entwickelt, um die Kommunikation zwischen Client und Dienst in Android-Anwendungen durch **interprozessuale Kommunikation** (IPC) zu erleichtern. Da der direkte Zugriff auf den Speicher eines anderen Prozesses auf Android nicht gestattet ist, vereinfacht AIDL den Prozess, indem Objekte in ein vom Betriebssystem verstandenes Format umgewandelt werden, wodurch die Kommunikation zwischen verschiedenen Prozessen erleichtert wird.
|
||||
|
||||
### Schlüsselkonzepte
|
||||
|
||||
- **Gebundene Dienste**: Diese Dienste nutzen AIDL für IPC, wodurch Aktivitäten oder Komponenten an einen Dienst binden, Anfragen stellen und Antworten erhalten können. Die `onBind`-Methode in der Dienstklasse ist entscheidend für den Beginn der Interaktion und stellt einen wichtigen Bereich für die Sicherheitsüberprüfung auf Schwachstellen dar.
|
||||
- **Gebundene Dienste**: Diese Dienste nutzen AIDL für IPC, wodurch Aktivitäten oder Komponenten an einen Dienst binden, Anfragen stellen und Antworten erhalten können. Die Methode `onBind` in der Dienstklasse ist entscheidend für den Beginn der Interaktion und stellt einen wichtigen Bereich für die Sicherheitsüberprüfung auf Schwachstellen dar.
|
||||
|
||||
- **Messenger**: Als gebundener Dienst fungiert der Messenger als Vermittler für IPC mit dem Fokus auf die Verarbeitung von Daten über die `onBind`-Methode. Es ist wichtig, diese Methode genau auf unsichere Datenverarbeitung oder die Ausführung sensibler Funktionen zu überprüfen.
|
||||
- **Messenger**: Als gebundener Dienst ermöglicht der Messenger IPC mit dem Fokus auf die Verarbeitung von Daten über die Methode `onBind`. Es ist wichtig, diese Methode genau auf unsichere Datenverarbeitung oder die Ausführung sensibler Funktionen zu überprüfen.
|
||||
|
||||
- **Binder**: Obwohl die direkte Verwendung der Binder-Klasse aufgrund der Abstraktion durch AIDL weniger verbreitet ist, ist es vorteilhaft zu verstehen, dass der Binder als Kernel-Treiber fungiert, der den Datentransfer zwischen den Speicherbereichen verschiedener Prozesse ermöglicht. Für ein besseres Verständnis steht eine Ressource zur Verfügung unter [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8).
|
||||
- **Binder**: Obwohl die direkte Verwendung der Binder-Klasse aufgrund der Abstraktion durch AIDL weniger verbreitet ist, ist es vorteilhaft zu verstehen, dass der Binder als Kernel-Treiber fungiert, der den Datentransfer zwischen den Speicherbereichen verschiedener Prozesse erleichtert. Für ein besseres Verständnis steht eine Ressource zur Verfügung unter [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8).
|
||||
|
||||
## Komponenten
|
||||
|
||||
@ -254,9 +254,9 @@ Allerdings ist der Zugriff auf eine Aktivität von einer anderen App nicht immer
|
||||
|
||||
Der Lebenszyklus einer Aktivität **beginnt mit der onCreate-Methode**, die die Benutzeroberfläche einrichtet und die Aktivität auf die Interaktion mit dem Benutzer vorbereitet.
|
||||
|
||||
### Anwendung Unterklasse
|
||||
### Anwendungssubklasse
|
||||
|
||||
In der Android-Entwicklung hat eine App die Möglichkeit, eine **Unterklasse** der [Application](https://developer.android.com/reference/android/app/Application) Klasse zu erstellen, obwohl dies nicht obligatorisch ist. Wenn eine solche Unterklasse definiert ist, wird sie zur ersten Klasse, die innerhalb der App instanziiert wird. Die **`attachBaseContext`** Methode, wenn sie in dieser Unterklasse implementiert ist, wird vor der **`onCreate`** Methode ausgeführt. Diese Einrichtung ermöglicht eine frühe Initialisierung, bevor der Rest der Anwendung startet.
|
||||
In der Android-Entwicklung hat eine App die Möglichkeit, eine **Subklasse** der [Application](https://developer.android.com/reference/android/app/Application)-Klasse zu erstellen, obwohl dies nicht obligatorisch ist. Wenn eine solche Subklasse definiert ist, wird sie zur ersten Klasse, die innerhalb der App instanziiert wird. Die **`attachBaseContext`**-Methode, wenn sie in dieser Subklasse implementiert ist, wird vor der **`onCreate`**-Methode ausgeführt. Diese Einrichtung ermöglicht eine frühe Initialisierung, bevor der Rest der Anwendung startet.
|
||||
```java
|
||||
public class MyApp extends Application {
|
||||
@Override
|
||||
@ -274,11 +274,11 @@ super.onCreate();
|
||||
```
|
||||
### Dienste
|
||||
|
||||
[Dienste](https://developer.android.com/guide/components/services) sind **Hintergrundoperationen**, die in der Lage sind, Aufgaben ohne Benutzeroberfläche auszuführen. Diese Aufgaben können weiterhin ausgeführt werden, selbst wenn Benutzer zu anderen Anwendungen wechseln, was Dienste entscheidend für **langandauernde Operationen** macht.
|
||||
[Dienste](https://developer.android.com/guide/components/services) sind **Hintergrundoperationen**, die in der Lage sind, Aufgaben ohne Benutzeroberfläche auszuführen. Diese Aufgaben können weiterhin ausgeführt werden, selbst wenn Benutzer zu anderen Anwendungen wechseln, was Dienste für **langandauernde Operationen** entscheidend macht.
|
||||
|
||||
Dienste sind vielseitig; sie können auf verschiedene Weise gestartet werden, wobei **Intents** die primäre Methode zum Starten als Einstiegspunkt einer Anwendung sind. Sobald ein Dienst mit der Methode `startService` gestartet wird, wird die Methode `onStart` aktiviert und läuft weiter, bis die Methode `stopService` ausdrücklich aufgerufen wird. Alternativ, wenn die Rolle eines Dienstes von einer aktiven Clientverbindung abhängt, wird die Methode `bindService` verwendet, um den Client mit dem Dienst zu verbinden, wobei die Methode `onBind` für den Datenaustausch aktiviert wird.
|
||||
|
||||
Eine interessante Anwendung von Diensten umfasst die Wiedergabe von Hintergrundmusik oder das Abrufen von Netzwerkdaten, ohne die Interaktion des Benutzers mit einer App zu behindern. Darüber hinaus können Dienste für andere Prozesse auf demselben Gerät durch **Exportieren** zugänglich gemacht werden. Dies ist nicht das Standardverhalten und erfordert eine explizite Konfiguration in der Android Manifest-Datei:
|
||||
Eine interessante Anwendung von Diensten umfasst die Wiedergabe von Hintergrundmusik oder das Abrufen von Netzwerkdaten, ohne die Interaktion des Benutzers mit einer App zu beeinträchtigen. Darüber hinaus können Dienste für andere Prozesse auf demselben Gerät durch **Exportieren** zugänglich gemacht werden. Dies ist nicht das Standardverhalten und erfordert eine ausdrückliche Konfiguration in der Android-Manifestdatei:
|
||||
```xml
|
||||
<service android:name=".ExampleExportedService" android:exported="true"/>
|
||||
```
|
||||
@ -290,11 +290,11 @@ Eine interessante Anwendung von Diensten umfasst die Wiedergabe von Hintergrundm
|
||||
|
||||
Broadcasts können entweder **asynchron** sein, wobei alle Empfänger ohne Reihenfolge erreicht werden, oder **synchron**, wobei Empfänger den Broadcast basierend auf festgelegten Prioritäten erhalten. Es ist jedoch wichtig, das potenzielle Sicherheitsrisiko zu beachten, da jede App sich selbst priorisieren kann, um einen Broadcast abzufangen.
|
||||
|
||||
Um die Funktionalität eines Empfängers zu verstehen, suchen Sie nach der Methode **`onReceive`** innerhalb seiner Klasse. Der Code dieser Methode kann den empfangenen Intent manipulieren, was die Notwendigkeit der Datenvalidierung durch Empfänger hervorhebt, insbesondere bei **geordneten Broadcasts**, die den Intent modifizieren oder verwerfen können.
|
||||
Um die Funktionalität eines Empfängers zu verstehen, suchen Sie nach der Methode **`onReceive`** innerhalb seiner Klasse. Der Code dieser Methode kann das empfangene Intent manipulieren, was die Notwendigkeit der Datenvalidierung durch Empfänger hervorhebt, insbesondere bei **geordneten Broadcasts**, die das Intent modifizieren oder verwerfen können.
|
||||
|
||||
### Content Provider
|
||||
|
||||
**Content Provider** sind entscheidend für das **Teilen strukturierter Daten** zwischen Apps und betonen die Bedeutung der Implementierung von **Berechtigungen**, um die Datensicherheit zu gewährleisten. Sie ermöglichen es Apps, auf Daten aus verschiedenen Quellen zuzugreifen, einschließlich Datenbanken, Dateisystemen oder dem Web. Spezifische Berechtigungen wie **`readPermission`** und **`writePermission`** sind entscheidend für die Kontrolle des Zugriffs. Darüber hinaus kann temporärer Zugriff über **`grantUriPermission`**-Einstellungen im Manifest der App gewährt werden, wobei Attribute wie `path`, `pathPrefix` und `pathPattern` für eine detaillierte Zugriffskontrolle genutzt werden.
|
||||
**Content Provider** sind entscheidend für das **Teilen strukturierter Daten** zwischen Apps und betonen die Bedeutung der Implementierung von **Berechtigungen**, um die Datensicherheit zu gewährleisten. Sie ermöglichen es Apps, auf Daten aus verschiedenen Quellen zuzugreifen, einschließlich Datenbanken, Dateisystemen oder dem Web. Spezifische Berechtigungen wie **`readPermission`** und **`writePermission`** sind entscheidend für die Kontrolle des Zugriffs. Darüber hinaus kann temporärer Zugriff über die Einstellungen **`grantUriPermission`** im Manifest der App gewährt werden, wobei Attribute wie `path`, `pathPrefix` und `pathPattern` für eine detaillierte Zugriffskontrolle verwendet werden.
|
||||
|
||||
Die Eingangsvalidierung ist von größter Bedeutung, um Schwachstellen wie SQL-Injection zu verhindern. Content Provider unterstützen grundlegende Operationen: `insert()`, `update()`, `delete()` und `query()`, die die Datenmanipulation und das Teilen zwischen Anwendungen erleichtern.
|
||||
|
||||
@ -310,7 +310,7 @@ android:exported="false">
|
||||
android:resource="@xml/filepaths" />
|
||||
</provider>
|
||||
```
|
||||
Und ein Beispiel für die Angabe von freigegebenen Ordnern in `filepaths.xml`:
|
||||
Und ein Beispiel für die Angabe von gemeinsamen Ordnern in `filepaths.xml`:
|
||||
```xml
|
||||
<paths>
|
||||
<files-path path="images/" name="myimages" />
|
||||
@ -323,7 +323,7 @@ Für weitere Informationen siehe:
|
||||
|
||||
## WebViews
|
||||
|
||||
WebViews sind wie **Mini-Webbrowser** in Android-Apps, die Inhalte entweder aus dem Web oder von lokalen Dateien abrufen. Sie sind ähnlichen Risiken wie reguläre Browser ausgesetzt, jedoch gibt es Möglichkeiten, diese **Risiken zu reduzieren** durch spezifische **Einstellungen**.
|
||||
WebViews sind wie **Mini-Webbrowser** innerhalb von Android-Apps, die Inhalte entweder aus dem Web oder von lokalen Dateien abrufen. Sie sind ähnlichen Risiken wie reguläre Browser ausgesetzt, jedoch gibt es Möglichkeiten, diese **Risiken zu reduzieren** durch spezifische **Einstellungen**.
|
||||
|
||||
Android bietet zwei Haupttypen von WebViews:
|
||||
|
||||
@ -332,21 +332,21 @@ Android bietet zwei Haupttypen von WebViews:
|
||||
|
||||
Ein wichtiger Punkt ist, dass WebView-Browser **keine Cookies** mit dem Hauptbrowser des Geräts teilen.
|
||||
|
||||
Für das Laden von Inhalten stehen Methoden wie `loadUrl`, `loadData` und `loadDataWithBaseURL` zur Verfügung. Es ist entscheidend sicherzustellen, dass diese URLs oder Dateien **sicher zu verwenden** sind. Sicherheitseinstellungen können über die Klasse `WebSettings` verwaltet werden. Beispielsweise kann das Deaktivieren von JavaScript mit `setJavaScriptEnabled(false)` XSS-Angriffe verhindern.
|
||||
Für das Laden von Inhalten stehen Methoden wie `loadUrl`, `loadData` und `loadDataWithBaseURL` zur Verfügung. Es ist entscheidend sicherzustellen, dass diese URLs oder Dateien **sicher zu verwenden** sind. Sicherheitseinstellungen können über die `WebSettings`-Klasse verwaltet werden. Beispielsweise kann das Deaktivieren von JavaScript mit `setJavaScriptEnabled(false)` XSS-Angriffe verhindern.
|
||||
|
||||
Die JavaScript "Bridge" ermöglicht es Java-Objekten, mit JavaScript zu interagieren, wobei Methoden ab Android 4.2 mit `@JavascriptInterface` für die Sicherheit markiert werden müssen.
|
||||
Die JavaScript "Bridge" ermöglicht es Java-Objekten, mit JavaScript zu interagieren, wobei Methoden ab Android 4.2 mit `@JavascriptInterface` für die Sicherheit gekennzeichnet werden müssen.
|
||||
|
||||
Das Zulassen des Zugriffs auf Inhalte (`setAllowContentAccess(true)`) ermöglicht es WebViews, auf Content Providers zuzugreifen, was ein Risiko darstellen könnte, es sei denn, die Inhalts-URLs werden als sicher verifiziert.
|
||||
|
||||
Um den Datei-Zugriff zu steuern:
|
||||
Um den Dateizugriff zu steuern:
|
||||
|
||||
- Das Deaktivieren des Datei-Zugriffs (`setAllowFileAccess(false)`) beschränkt den Zugriff auf das Dateisystem, mit Ausnahmen für bestimmte Assets, um sicherzustellen, dass sie nur für nicht sensible Inhalte verwendet werden.
|
||||
- Das Deaktivieren des Dateizugriffs (`setAllowFileAccess(false)`) beschränkt den Zugriff auf das Dateisystem, mit Ausnahmen für bestimmte Assets, um sicherzustellen, dass sie nur für nicht sensible Inhalte verwendet werden.
|
||||
|
||||
## Andere App-Komponenten und Mobile Device Management
|
||||
|
||||
### **Digitale Signatur von Anwendungen**
|
||||
|
||||
- **Digitale Signaturen** sind ein Muss für Android-Apps, um sicherzustellen, dass sie **authentisch erstellt** wurden, bevor sie installiert werden. Dieser Prozess verwendet ein Zertifikat zur Identifizierung der App und muss vom Paketmanager des Geräts bei der Installation überprüft werden. Apps können **selbstsigniert oder von einer externen CA zertifiziert** sein, um unbefugten Zugriff zu verhindern und sicherzustellen, dass die App während der Lieferung an das Gerät unverändert bleibt.
|
||||
- **Digitale Signaturen** sind für Android-Apps unerlässlich, um sicherzustellen, dass sie **authentisch erstellt** wurden, bevor sie installiert werden. Dieser Prozess verwendet ein Zertifikat zur Identifizierung der App und muss vom Paketmanager des Geräts bei der Installation überprüft werden. Apps können **selbstsigniert oder von einer externen CA zertifiziert** sein, um unbefugten Zugriff zu verhindern und sicherzustellen, dass die App während der Lieferung an das Gerät unverändert bleibt.
|
||||
|
||||
### **App-Verifizierung für erhöhte Sicherheit**
|
||||
|
||||
@ -365,4 +365,104 @@ if (dpm.isAdminActive(adminComponent)) {
|
||||
dpm.setPasswordMinimumLength(adminComponent, 8);
|
||||
}
|
||||
```
|
||||
## Auflisten und Ausnutzen von AIDL / Binder-Diensten
|
||||
|
||||
Android *Binder* IPC bietet viele **System- und vom Anbieter bereitgestellte Dienste**. Diese Dienste werden zu einer **Angriffsfläche**, wenn sie ohne eine ordnungsgemäße Berechtigungsprüfung exportiert werden (die AIDL-Schicht selbst führt *keine* Zugriffskontrolle durch).
|
||||
|
||||
### 1. Laufende Dienste entdecken
|
||||
```bash
|
||||
# from an adb shell (USB or wireless)
|
||||
service list # simple one-liner
|
||||
am list services # identical output, ActivityManager wrapper
|
||||
```
|
||||
1. Überschrift 1
|
||||
2. Überschrift 2
|
||||
3. Überschrift 3
|
||||
4. Überschrift 4
|
||||
5. Überschrift 5
|
||||
```
|
||||
145 mtkconnmetrics: [com.mediatek.net.connectivity.IMtkIpConnectivityMetrics]
|
||||
146 wifi : [android.net.wifi.IWifiManager]
|
||||
```
|
||||
* Der **Index** (erste Spalte) wird zur Laufzeit zugewiesen – verlassen Sie sich ***nicht*** darauf, dass er über Neustarts hinweg bestehen bleibt.
|
||||
* Der **Binder-Name** (z.B. `mtkconnmetrics`) ist das, was an `service call` übergeben wird.
|
||||
* Der Wert in den Klammern ist die vollqualifizierte **AIDL-Schnittstelle**, von der der Stub generiert wurde.
|
||||
|
||||
### 2. Erhalten Sie den Schnittstellen-Descriptor (PING)
|
||||
Jeder Binder-Stub implementiert automatisch **Transaktionscode `0x5f4e5446`** (`1598968902` dezimal, ASCII "_NTF").
|
||||
```bash
|
||||
# "ping" the service
|
||||
service call mtkconnmetrics 1 # 1 == decimal 1598968902 mod 2^32
|
||||
```
|
||||
Eine gültige Antwort gibt den Schnittstellennamen als UTF-16-Zeichenfolge innerhalb eines `Parcel` zurück.
|
||||
|
||||
### 3. Einen Transaktionsaufruf tätigen
|
||||
Syntax: `service call <name> <code> [type value ...]`
|
||||
|
||||
Häufige Argumentbezeichner:
|
||||
* `i32 <int>` – signierter 32-Bit-Wert
|
||||
* `i64 <long>` – signierter 64-Bit-Wert
|
||||
* `s16 <string>` – UTF-16-Zeichenfolge (Android 13+ verwendet `utf16`)
|
||||
|
||||
Beispiel – Netzwerküberwachung mit uid **1** auf einem MediaTek-Gerät starten:
|
||||
```bash
|
||||
service call mtkconnmetrics 8 i32 1
|
||||
```
|
||||
### 4. Brute-Forcing Unbekannte Methoden
|
||||
Wenn Header-Dateien nicht verfügbar sind, können Sie **den Code iterieren**, bis sich der Fehler ändert von:
|
||||
```
|
||||
Result: Parcel(00000000 00000000) # "Not a data message"
|
||||
```
|
||||
zu einer normalen `Parcel`-Antwort oder `SecurityException`.
|
||||
```bash
|
||||
for i in $(seq 1 50); do
|
||||
printf "[+] %2d -> " $i
|
||||
service call mtkconnmetrics $i 2>/dev/null | head -1
|
||||
done
|
||||
```
|
||||
Wenn der Dienst **mit ProGuard** kompiliert wurde, muss die Zuordnung erraten werden – siehe nächsten Schritt.
|
||||
|
||||
### 5. Zuordnung von Codes ↔ Methoden über onTransact()
|
||||
Dekompiliere die jar/odex, die das Interface implementiert (für AOSP-Stubs siehe `/system/framework`; OEMs verwenden oft `/system_ext` oder `/vendor`).
|
||||
Suche nach `Stub.onTransact()` – es enthält ein riesiges `switch(transactionCode)`:
|
||||
```java
|
||||
case TRANSACTION_updateCtaAppStatus: // 5
|
||||
data.enforceInterface(DESCRIPTOR);
|
||||
int appId = data.readInt();
|
||||
boolean ok = data.readInt() != 0;
|
||||
updateCtaAppStatus(appId, ok);
|
||||
reply.writeNoException();
|
||||
return true;
|
||||
```
|
||||
Jetzt sind der Prototyp und die **Parameterarten** kristallklar.
|
||||
|
||||
### 6. Fehlende Berechtigungsprüfungen erkennen
|
||||
Die Implementierung (oft eine innere `Impl`-Klasse) ist verantwortlich für die Autorisierung:
|
||||
```java
|
||||
private void updateCtaAppStatus(int uid, boolean status) {
|
||||
if (!isPermissionAllowed()) {
|
||||
throw new SecurityException("uid " + uid + " rejected");
|
||||
}
|
||||
/* privileged code */
|
||||
}
|
||||
```
|
||||
Das Fehlen einer solchen Logik oder einer Whitelist privilegierter UIDs (z.B. `uid == 1000 /*system*/`) ist ein **Anzeichen für eine Schwachstelle**.
|
||||
|
||||
Fallstudie – *MediaTek* `startMonitorProcessWithUid()` (Transaktion **8**) führt eine Netlink-Nachricht **ohne** jegliche Berechtigungsprüfung vollständig aus, was es einer unprivilegierten App ermöglicht, mit dem Netfilter-Modul des Kernels zu interagieren und das Systemprotokoll zu spammen.
|
||||
|
||||
### 7. Automatisierung der Bewertung
|
||||
Tools / Skripte, die die Binder-Recherche beschleunigen:
|
||||
* [binderfs](https://android.googlesource.com/platform/frameworks/native/+/master/cmds/binderfs/) – stellt `/dev/binderfs` mit dienstspezifischen Knoten zur Verfügung
|
||||
* [`binder-scanner.py`](https://github.com/adenflare/binder-scanner) – durchläuft die Binder-Tabelle und druckt ACLs
|
||||
* Frida-Shortcut: `Java.perform(()=>console.log(android.os.ServiceManager.listServices().toArray()))`
|
||||
|
||||
---
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [Android Services 101 – Pentest Partners](https://www.pentestpartners.com/security-blog/android-services-101/)
|
||||
- [Android Developer Docs – AIDL](https://developer.android.com/guide/components/aidl)
|
||||
- [Android Developer Docs – IBinder](https://developer.android.com/reference/android/os/IBinder)
|
||||
- [Understanding Binder, Talk @ Google](https://www.youtube.com/watch?v=O-UHvFjxwZ8)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user