diff --git a/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md b/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md index ae130236fae..f4f3daeb554 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md +++ b/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md @@ -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 + +Google’s 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 attacker’s 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 task’s *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 `` (or the global `` 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 `` (or the global `` 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 `` 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 app’s `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 activity’s 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 12–14 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}}