mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/mobile-pentesting/android-app-pentesting/android-task-h
This commit is contained in:
parent
12cefd433e
commit
b49c9d5f32
@ -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.
|
||||
|
||||
.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 12–14 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}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user