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

This commit is contained in:
Translator 2025-07-23 06:11:22 +00:00
parent 2783d9dbae
commit d9ae54a9fa

View File

@ -15,39 +15,89 @@ Ecco una rapida panoramica delle transizioni delle attività:
![https://developer.android.com/images/fundamentals/diagram_backstack.png](<../../images/image (698).png>)
## Attacco di Affinità del Task
---
### Panoramica dell'Affinità del Task e delle Modalità di Lancio
## Attacchi di affinità del task
Nelle applicazioni Android, l'**affinità del task** specifica il task preferito di un'attività, allineandosi tipicamente con il nome del pacchetto dell'app. Questa configurazione è fondamentale per creare un'app di prova di concetto (PoC) per dimostrare l'attacco.
`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**.
### Modalità di Lancio
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.
L'attributo `launchMode` dirige la gestione delle istanze delle attività all'interno dei task. La modalità **singleTask** è fondamentale per questo attacco, dettando tre scenari basati sulle istanze di attività esistenti e sulle corrispondenze di affinità del task. L'exploit si basa sulla capacità dell'app dell'attaccante di imitare l'affinità del task dell'app target, ingannando il sistema Android nel lanciare l'app dell'attaccante invece dell'obiettivo previsto.
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.
### Passaggi Dettagliati dell'Attacco
### Scenario classico "singleTask / StrandHogg"
1. **Installazione dell'App Maligna**: La vittima installa l'app dell'attaccante sul proprio dispositivo.
2. **Attivazione Iniziale**: La vittima apre per prima l'app maligna, preparando il dispositivo per l'attacco.
3. **Tentativo di Lancio dell'App Target**: La vittima tenta di aprire l'app target.
4. **Esecuzione dell'Hijack**: A un certo punto, l'app cerca di aprire la vista **singleTask**. A causa della corrispondenza dell'affinità del task, l'app maligna viene lanciata al posto dell'app target.
5. **Inganno**: L'app maligna presenta una schermata di accesso falsa che somiglia all'app target, ingannando l'utente a inserire informazioni sensibili.
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.
> [!TIP]
> Nota che per questo attacco funzionare la vista vulnerabile **non deve avere esportato a true** né deve essere l'attività principale.
### Variante DefaultAffinity (senza `singleTask`) Studio di caso Caller ID
Per un'implementazione pratica di questo attacco, fai riferimento al repository Task Hijacking Strandhogg su GitHub: [Task Hijacking Strandhogg](https://github.com/az0mb13/Task_Hijacking_Strandhogg).
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:
### Misure di Prevenzione
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 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 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.
Per prevenire tali attacchi, gli sviluppatori possono:
- Impostare **`**taskAffinity`** della vista **singleTask** su una stringa vuota (`android:taskAffinity=""`)
- Optare per la modalità di lancio **`singleInstance`**, garantendo l'isolamento della loro app da altre.
- Personalizzare la funzione **`onBackPressed()`** offre ulteriore protezione contro l'hijacking del task.
> 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.
## **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)
## 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.
## 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.
---
## 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)
{{#include ../../banners/hacktricks-training.md}}