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

src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md

@@ -11,7 +11,7 @@ Aqui está um resumo rápido das transições de atividades:
 - **Atividade 1** começa como a única atividade em primeiro plano.
 - Lançar **Atividade 2** empurra **Atividade 1** para a pilha de atividades, trazendo **Atividade 2** para o primeiro plano.
 - Iniciar **Atividade 3** move **Atividade 1** e **Atividade 2** mais para trás na pilha, com **Atividade 3** agora na frente.
-- Fechar **Atividade 3** traz **Atividade 2** de volta ao primeiro plano, demonstrando o mecanismo de navegação de tarefas simplificado do Android.
+- Fechar **Atividade 3** traz **Atividade 2** de volta ao primeiro plano, mostrando o mecanismo de navegação de tarefas simplificado do Android.
 
 ![https://developer.android.com/images/fundamentals/diagram_backstack.png](<../../images/image (698).png>)
 
@@ -40,7 +40,7 @@ android:launchMode="singleTask" >
 </activity>
 ```
 2. O aplicativo malicioso é iniciado uma vez para que a tarefa (com a afinidade falsificada) exista nas tarefas recentes.
-3. Quando o usuário abre o aplicativo real mais tarde, o Android encontra que já existe uma tarefa cuja **afinidade raiz corresponde ao pacote** e simplesmente traz essa tarefa para o primeiro plano.
+3. Quando o usuário abre o aplicativo real mais tarde, o Android encontra uma tarefa cuja **afinidade raiz corresponde ao pacote** e simplesmente traz essa tarefa para o primeiro plano.
 4. A interface do atacante é exibida primeiro.
 
 ### Variante Default–Affinity (sem `singleTask`) – Estudo de caso de Caller ID
@@ -68,20 +68,51 @@ android:taskAffinity="com.caller.id.phone.number.block" >
 </activity>
 ```
 3. Assim que o usuário instala e abre o aplicativo malicioso **uma vez**, uma tarefa cuja afinidade é igual ao pacote da vítima existe (mas fica em segundo plano).
-4. Quando o aplicativo real de Caller ID é lançado, o Android reutiliza essa tarefa e traz `HackActivity` para o primeiro plano → janela de phishing/abuso de permissões.
+4. Quando o aplicativo real de Caller ID é lançado, o Android reutiliza essa tarefa e traz `HackActivity` para o primeiro plano → janela de phishing/abuso de permissão.
 
 > NOTA: A partir do **Android 11 (API 30)**, o sistema *não* coloca dois pacotes que não fazem parte do mesmo UID na mesma tarefa por padrão, mitigando essa variante específica. Versões mais antigas permanecem vulneráveis.
 
 ---
 
+### StrandHogg 2.0 (CVE-2020-0096) – Sequestro de tarefa baseado em reflexão
+
+O boletim de segurança de maio de 2020 do Google corrigiu uma variante mais avançada chamada **StrandHogg 2.0**. O exploit **não depende de `taskAffinity` de forma alguma**; em vez disso, usa *reflexão* para inserir dinamicamente a atividade do atacante no topo de *todas* as tarefas em execução, contornando completamente a restrição de “UID compartilhado” introduzida pelo Android 11.
+
+Pontos-chave:
+
+* Um aplicativo malicioso sem permissões pode, uma vez aberto, iterar sobre tarefas em execução e chamar APIs ocultas para **reparentar** sua própria atividade em qualquer tarefa.
+* Como a atividade é inserida após o tempo de execução, nem `launchMode` nem análise estática do manifesto podem detectar o ataque com antecedência.
+* Corrigido por meio de um back-port de uma verificação no **Android 8.0/8.1/9** (SPL de maio de 2020). **Android 10 e versões posteriores não são afetados.**
+
+A detecção em dispositivos pré-corrigidos pode ser realizada com `adb shell dumpsys activity activities` e observando atividades suspeitas cujo nome de pacote difere da *afinidade* da tarefa.
+
+A mitigação para dispositivos legados é a mesma do sequestro de tarefas clássico **mais** verificação em tempo de execução (por exemplo, chamando [`ActivityManager#getRunningTasks`](https://developer.android.com/reference/android/app/ActivityManager#getRunningTasks(int)) e validando seu próprio nome de pacote).
+
+---
+
 ## Lista de verificação de Detecção & Exploração
 
-1. Extraia `AndroidManifest.xml` do APK alvo e verifique se cada `<activity>` (ou o elemento global `<application>`) contém `android:taskAffinity=""` (vazio) **ou** um valor personalizado.
-2. Se não, crie um aplicativo malicioso:
-- `android:taskAffinity` = nome do pacote da vítima.
-- Forneça um intento `MAIN/LAUNCHER` para que o usuário possa abri-lo uma vez.
-- Opcionalmente, chame `moveTaskToBack(true)` para ocultar imediatamente.
-3. Deixe a vítima abrir seu aplicativo legítimo → sequestro.
+1. **Revisão estática** – Extraia `AndroidManifest.xml` do APK alvo e verifique se cada `<activity>` (ou o elemento global `<application>`) contém `android:taskAffinity=""` (vazio) **ou** um valor personalizado. Ferramentas como:
+```bash
+# Usando apkanalyzer (Android SDK)
+apkanalyzer manifest print app.apk | grep -i taskaffinity
+
+# Usando AXMLPrinter2
+java -jar AXMLPrinter2.jar AndroidManifest.xml | grep taskAffinity
+```
+2. **Revisão dinâmica** – No dispositivo, abra o aplicativo alvo e liste as tarefas:
+```bash
+adb shell dumpsys activity activities | grep -A3 "TASK" | grep -E "Root|affinity"
+```
+Uma tarefa cuja afinidade raiz é igual ao pacote da vítima, mas cuja atividade superior pertence a um *pacote diferente* é um sinal de alerta.
+3. Crie um aplicativo malicioso conforme descrito acima, ou use **[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
+```
+
+---
 
 ## Mitigação
 
@@ -90,6 +121,14 @@ Os desenvolvedores devem:
 * Definir explicitamente `android:taskAffinity=""` no nível `<application>` (recomendado) **ou** dar a cada atividade uma afinidade única e privada.
 * Para telas altamente sensíveis, combine o acima com `android:launchMode="singleInstance"` ou proteções modernas [`setLaunchMode`](https://developer.android.com/reference/android/content/pm/ActivityInfo#launchMode).
 * Atualizar a `targetSdkVersion` do aplicativo e impor mudanças comportamentais do **Android 11** onde as tarefas não são compartilhadas entre pacotes por padrão.
+* Almejar **Android 12 (API 31) ou superior** para que o atributo obrigatório `android:exported` force os desenvolvedores a auditar cada componente acessível externamente.
+* Considerar autodefesa em tempo de execução: consultar periodicamente `ActivityTaskManager` para garantir que o pacote da sua atividade superior corresponda ao seu próprio.
+
+---
+
+## Técnicas relacionadas de UI-Hijacking
+
+O sequestro de tarefas é frequentemente combinado ou substituído por **tapjacking** (decepção de UI baseada em sobreposição). A pesquisa de 2025 **TapTrap** mostrou que atividades *transparentes e impulsionadas por animação* podem contornar as restrições de toque de sobreposição introduzidas no Android 12–14 e ainda enganar os usuários para conceder permissões perigosas. Embora TapTrap não seja estritamente *sequestro* de tarefas, o objetivo final (cliques de phishing) é idêntico – portanto, avaliações modernas devem verificar ambas as superfícies de ataque.
 
 ---
 
@@ -99,5 +138,7 @@ Os desenvolvedores devem:
 - [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}}