Android Task Hijacking

Reading time: 8 minutes

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.

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:

<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:

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:

<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 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:

# 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:

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:

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.
• 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.takemyhand.xyz/2021/02/android-task-hijacking-with.html
• Android Manifest Misconfiguration Leading to Task Hijacking in Caller ID app
• 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
• USENIX 2025 – TapTrap: Animation-Driven Tapjacking on Android