Translated ['src/mobile-pentesting/android-app-pentesting/android-task-h

This commit is contained in:
Translator 2025-07-30 08:12:56 +00:00
parent 12cefd433e
commit b49c9d5f32

View File

@ -2,16 +2,16 @@
{{#include ../../banners/hacktricks-training.md}}
## Attività, Back Stack e Attività in Primo Piano
## 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 un **back stack**. Questo stack ordina le attività in base a quando sono state aperte, con l'attività più recente visualizzata in cima come **attività in primo piano**. In qualsiasi momento, solo questa attività è visibile sullo schermo, rendendola parte del **task in primo piano**.
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à:
- **Attività 1** inizia come l'unica attività in primo piano.
- L'apertura di **Attività 2** spinge **Attività 1** nel back stack, portando **Attività 2** in primo piano.
- L'avvio di **Attività 3** sposta **Attività 1** e **Attività 2** ulteriormente indietro nello stack, con **Attività 3** ora davanti.
- La chiusura di **Attività 3** riporta **Attività 2** in primo piano, mostrando il meccanismo di navigazione dei task semplificato di Android.
- **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>)
@ -19,11 +19,11 @@ Ecco una rapida panoramica delle transizioni delle attività:
## 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**.
`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 hijacking del task su versioni di Android precedenti alla 11.
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"
@ -67,29 +67,68 @@ android:taskAffinity="com.caller.id.phone.number.block" >
</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 rimane 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.
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 l'applicazione reale Caller ID viene avviata, 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.
> 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 senza 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. Estrai `AndroidManifest.xml` dall'APK target e controlla che ogni `<activity>` (o l'elemento globale `<application>`) contenga `android:taskAffinity=""` (vuoto) **o** un valore personalizzato.
2. Se non lo è, crea un'app malevola:
- `android:taskAffinity` = nome del pacchetto della vittima.
- Fornisci un'intento `MAIN/LAUNCHER` in modo che l'utente possa aprirla una volta.
- Facoltativamente chiama `moveTaskToBack(true)` per nascondere immediatamente.
3. Lascia che la vittima apra la propria applicazione legittima → hijack.
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.
* Impostare esplicitamente `android:taskAffinity=""` a livello di `<application>` (raccomandato) **o** dare a ogni 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à *completamente trasparenti* guidate da animazione possono bypassare le restrizioni sul tocco dell'overlay introdotte in Android 1214 e ingannare ancora gli utenti nel concedere permessi pericolosi. Sebbene TapTrap non sia strettamente *task* hijacking, l'obiettivo finale (clic di phishing) è identico quindi le valutazioni moderne dovrebbero controllare entrambe le superfici di attacco.
---
@ -99,5 +138,7 @@ Gli sviluppatori dovrebbero:
- [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}}