You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Android applications, **task affinity** specifies an activity's preferred task, aligning typically with the app's package name. This setup is instrumental in crafting a proof-of-concept (PoC) app for demonstrating the attack.
23
-
24
-
### Launch Modes
25
-
26
-
The `launchMode` attribute directs the handling of activity instances within tasks. The **singleTask** mode is pivotal for this attack, dictating three scenarios based on the existing activity instances and task affinity matches. The exploit hinges on the ability of an attacker's app to mimic the target app's task affinity, misleading the Android system into launching the attacker's app instead of the intended target.
27
-
28
-
### Detailed Attack Steps
29
-
30
-
1.**Malicious App Installation**: The victim installs the attacker's app on their device.
31
-
2.**Initial Activation**: The victim first opens the malicious app, setting up the device for the attack.
32
-
3.**Target App Launch Attempt**: The victim attempts to open the target app.
33
-
4.**Hijack Execution**: At some point the app tries to open the **singleTask** view. Due to the matching task affinity, the malicious app is launched in place of the target app.
34
-
5.**Deception**: The malicious app presents a fake login screen resembling the target app, tricking the user into entering sensitive information.
35
-
36
-
> [!TIP]
37
-
> Note that for this attack to work the vulnerable view **doesn't need to have exported to true** nor it needs to be the Main activity.
38
-
39
-
For a practical implementation of this attack, refer to the Task Hijacking Strandhogg repository on GitHub: [Task Hijacking Strandhogg](https://github.com/az0mb13/Task_Hijacking_Strandhogg).
40
-
41
-
### Prevention Measures
42
-
43
-
To prevent such attacks, developers can:
44
-
- Set **`**taskAffinity`** of the **singleTask** view to an empty string (`android:taskAffinity=""`)
45
-
- Opt for the **`singleInstance`** launch mode, ensuring their app's isolation from others.
46
-
- Customize the **`onBackPressed()`** function offers additional protection against task hijacking.
`taskAffinity` tells Android which task an `Activity` would *prefer* to belong to. When two activities share the same affinity **Android is allowed to merge them inside the same back-stack even if they come from different APKs**.
23
+
24
+
If an attacker can place a malicious activity at the **root** of that stack, every time the victim opens the legitimate application the malicious UI will be the first thing the user sees – perfect for phishing or abusive permission requests.
25
+
26
+
The attack surface is wider than many developers think because **every activity automatically inherits an affinity equal to the application package name** (unless the developer sets `android:taskAffinity=""`). Therefore *doing nothing* already leaves the app open to task hijacking on Android versions prior to 11.
2. The malicious app is started once so that the task (with the spoofed affinity) exists in recent tasks.
43
+
3. When the user later opens the real application, Android finds there is already a task whose **root affinity matches the package** and just brings that task to the foreground.
44
+
4. The attacker’s UI is shown first.
45
+
46
+
### Default–Affinity (no `singleTask`) variant – Caller ID case study
47
+
48
+
The vulnerability reported in the **Caller ID (caller.id.phone.number.block)** application shows that the attack *also* works against the default `standard` launch mode:
49
+
50
+
1. Attacker application creates a fake root activity and immediately hides itself:
51
+
```kotlin
52
+
classHackActivity : AppCompatActivity() {
53
+
overridefunonCreate(savedInstanceState:Bundle?) {
54
+
super.onCreate(savedInstanceState)
55
+
moveTaskToBack(true) // keep the task in recents but out of sight
56
+
}
57
+
}
58
+
```
59
+
2. The manifest only needs to copy the victim package into `taskAffinity`:
3. As soon as the user installs and opens the malicious app **once**, a task whose affinity equals the victim package exists (but sits in the background).
71
+
4. When the real Caller ID application is launched, Android re-uses that task and brings `HackActivity` to the foreground → phishing window/permission abuse.
72
+
73
+
> NOTE: Starting with **Android 11 (API 30)** the system does *not* place two packages that are not part of the same UID into the same task by default, mitigating this particular variant. Older versions remain vulnerable.
74
+
75
+
---
76
+
77
+
## Detection & Exploitation checklist
78
+
79
+
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.
80
+
2. If not, craft a malicious app:
81
+
-`android:taskAffinity` = victim package name.
82
+
- Provide a `MAIN/LAUNCHER` intent so the user can open it once.
83
+
- Optionally call `moveTaskToBack(true)` to hide immediately.
84
+
3. Let the victim open their legitimate application → hijack.
85
+
86
+
## Mitigation
87
+
88
+
Developers should:
89
+
90
+
* Explicitly set `android:taskAffinity=""` at the `<application>` level (recommended) **or** give each activity a unique, private affinity.
91
+
* 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.
92
+
* Upgrade the app’s `targetSdkVersion` and enforce **Android 11** behavioural changes where tasks are not shared across packages by default.
-[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)
0 commit comments