Merge pull request #1207 from HackTricks-wiki/research_update_src_mobile-pentesting_android-app-pentesting_android-task-hijacking_20250729_162414

Research Update Enhanced src/mobile-pentesting/android-app-p...
This commit is contained in:
SirBroccoli 2025-07-30 10:02:03 +02:00 committed by GitHub
commit d8d4cca107

View File

@ -74,14 +74,45 @@ The vulnerability reported in the **Caller ID (caller.id.phone.number.block)** a
---
### StrandHogg 2.0 (CVE-2020-0096) Reflection-based task hijack
Googles May-2020 security bulletin fixed a more advanced variant dubbed **StrandHogg 2.0**. The exploit **does not rely on `taskAffinity` at all**; instead it uses *reflection* to dynamically insert the attackers activity at the top of *every* running task, completely bypassing the “shared-UID” restriction introduced by Android 11.
Key points:
* A zero-permission malicious app can, once opened, iterate over running tasks and call hidden APIs to **re-parent** its own activity into any task.
* Because the activity is inserted after run-time, neither `launchMode` nor static manifest analysis can detect the attack in advance.
* Patched by back-porting a check into **Android 8.0/8.1/9** (May 2020 SPL). **Android 10 and later are not affected.**
Detection on pre-patched devices can be performed with `adb shell dumpsys activity activities` and watching for suspicious activities whose package name differs from the tasks *affinity*.
Mitigation for legacy devices is the same as classic Task Hijacking **plus** run-time verification (e.g. calling [`ActivityManager#getRunningTasks`](https://developer.android.com/reference/android/app/ActivityManager#getRunningTasks(int)) and validating your own package name).
---
## Detection & Exploitation checklist
1. Pull `AndroidManifest.xml` from the target APK and check that each `<activity>` (or the global `<application>` element) contains `android:taskAffinity=""` (empty) **or** a customised value.
2. If not, craft a malicious app:
- `android:taskAffinity` = victim package name.
- Provide a `MAIN/LAUNCHER` intent so the user can open it once.
- Optionally call `moveTaskToBack(true)` to hide immediately.
3. Let the victim open their legitimate application → hijack.
1. **Static review** Pull `AndroidManifest.xml` from the target APK and check that each `<activity>` (or the global `<application>` element) contains `android:taskAffinity=""` (empty) **or** a customised value. Tools such as:
```bash
# Using apkanalyzer (Android SDK)
apkanalyzer manifest print app.apk | grep -i taskaffinity
# Using AXMLPrinter2
java -jar AXMLPrinter2.jar AndroidManifest.xml | grep taskAffinity
```
2. **Dynamic review** On the device open the target app and list tasks:
```bash
adb shell dumpsys activity activities | grep -A3 "TASK" | grep -E "Root|affinity"
```
A task whose root affinity equals the victim package but whose top activity belongs to a *different* package is a red flag.
3. Craft a malicious app as described above, or use **[Drozer](https://github.com/WithSecureLabs/drozer)**:
```bash
drozer console connect
run app.activity.start --component com.victim/.MainActivity --action android.intent.action.MAIN
run app.activity.info com.victim
```
---
## Mitigation
@ -90,6 +121,14 @@ Developers should:
* Explicitly set `android:taskAffinity=""` at the `<application>` level (recommended) **or** give each activity a unique, private affinity.
* For highly sensitive screens, combine the above with `android:launchMode="singleInstance"` or modern [`setLaunchMode`](https://developer.android.com/reference/android/content/pm/ActivityInfo#launchMode) protections.
* Upgrade the apps `targetSdkVersion` and enforce **Android 11** behavioural changes where tasks are not shared across packages by default.
* Target **Android 12 (API 31) or higher** so that the mandatory `android:exported` attribute forces developers to audit every externally-reachable component.
* Consider run-time self-defence: periodically query `ActivityTaskManager` to ensure that your top activitys package matches your own.
---
## Related UI-Hijacking techniques
Task hijacking is often combined with or replaced by **tapjacking** (overlay-based UI deception). The 2025 **TapTrap** research showed that fully transparent *animation-driven* activities can bypass the overlay-touch restrictions introduced in Android 1214 and still trick users into granting dangerous permissions. While TapTrap is not strictly *task* hijacking, the end-goal (phishing clicks) is identical so modern assessments should check for both attack surfaces.
---
@ -99,5 +138,7 @@ Developers should:
- [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)
- [Promon StrandHogg 2.0 (CVE-2020-0096) technical write-up](https://promon.io/resources/downloads/strandhogg-2-0-new-serious-android-vulnerability)
- [USENIX 2025 TapTrap: Animation-Driven Tapjacking on Android](https://www.usenix.org/conference/usenixsecurity25/presentation/beer)
{{#include ../../banners/hacktricks-training.md}}