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

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

@@ -4,12 +4,12 @@
 
 ## Task, Back Stack and Foreground Activities
 
-안드로이드에서 **task**는 사용자가 특정 작업을 완료하기 위해 상호작용하는 활동의 집합으로, **back stack** 내에 조직됩니다. 이 스택은 활동이 열린 순서에 따라 정렬되며, 가장 최근의 활동이 **foreground activity**로 화면 상단에 표시됩니다. 언제든지 이 활동만 화면에 보이므로 **foreground task**의 일부가 됩니다.
+안드로이드에서 **task**는 사용자가 특정 작업을 완료하기 위해 상호작용하는 활동의 집합으로, **back stack** 내에 조직됩니다. 이 스택은 활동이 열렸던 순서에 따라 정렬되며, 가장 최근의 활동이 가장 위에 표시되어 **foreground activity**가 됩니다. 언제든지 이 활동만 화면에 표시되어 **foreground task**의 일부가 됩니다.
 
 활동 전환에 대한 간단한 요약은 다음과 같습니다:
 
 - **Activity 1**은 foreground에서 유일한 활동으로 시작됩니다.
-- **Activity 2**를 시작하면 **Activity 1**이 back stack으로 밀려나고, **Activity 2**가 foreground로 올라옵니다.
+- **Activity 2**를 시작하면 **Activity 1**이 back stack으로 밀려나고, **Activity 2**가 foreground로 옵니다.
 - **Activity 3**을 시작하면 **Activity 1**과 **Activity 2**가 스택에서 더 뒤로 밀리고, **Activity 3**이 이제 앞에 위치합니다.
 - **Activity 3**을 닫으면 **Activity 2**가 다시 foreground로 돌아와 안드로이드의 간소화된 작업 탐색 메커니즘을 보여줍니다.
 
@@ -19,11 +19,11 @@
 
 ## Task affinity attacks
 
-`taskAffinity`는 안드로이드에 `Activity`가 *선호하는* 작업을 알려줍니다. 두 활동이 동일한 affinity를 공유할 경우 **안드로이드는 서로 다른 APK에서 온 경우에도 동일한 back-stack 내에서 이를 병합할 수 있습니다**.
+`taskAffinity`는 안드로이드에 `Activity`가 *선호*하는 작업을 알려줍니다. 두 활동이 동일한 affinity를 공유할 때 **안드로이드는 서로 다른 APK에서 온 경우에도 동일한 back-stack 내에서 이를 병합할 수 있습니다**.
 
 공격자가 그 스택의 **root**에 악성 활동을 배치할 수 있다면, 피해자가 합법적인 애플리케이션을 열 때마다 악성 UI가 사용자가 가장 먼저 보는 것이 됩니다 – 피싱이나 악용 권한 요청에 완벽합니다.
 
-공격 표면은 많은 개발자들이 생각하는 것보다 넓습니다. 왜냐하면 **모든 활동은 자동으로 애플리케이션 패키지 이름과 동일한 affinity를 상속받기 때문입니다** (개발자가 `android:taskAffinity=""`를 설정하지 않는 한). 따라서 *아무것도 하지 않는 것*만으로도 안드로이드 11 이전 버전에서 작업 하이재킹에 노출됩니다.
+공격 표면은 많은 개발자들이 생각하는 것보다 넓습니다. **모든 활동은 자동으로 애플리케이션 패키지 이름과 동일한 affinity를 상속받기 때문입니다** (개발자가 `android:taskAffinity=""`를 설정하지 않는 한). 따라서 *아무것도 하지 않는 것*만으로도 안드로이드 11 이전 버전에서 작업 탈취에 노출됩니다.
 
 ### Classic "singleTask / StrandHogg" scenario
 
@@ -39,20 +39,20 @@ android:launchMode="singleTask" >
 </intent-filter>
 </activity>
 ```
-2. 악성 앱이 한 번 시작되어 (스푸핑된 affinity를 가진) 작업이 최근 작업에 존재하게 됩니다.
-3. 사용자가 나중에 실제 애플리케이션을 열면, 안드로이드는 이미 **root affinity가 패키지와 일치하는 작업**이 있음을 찾아 그 작업을 foreground로 가져옵니다.
+2. 악성 앱이 한 번 시작되어 작업(스푸핑된 affinity가 있는)이 최근 작업에 존재하게 됩니다.
+3. 사용자가 나중에 실제 애플리케이션을 열면 안드로이드는 이미 **root affinity가 패키지와 일치하는** 작업이 있음을 찾아 그 작업을 foreground로 가져옵니다.
 4. 공격자의 UI가 먼저 표시됩니다.
 
 ### Default–Affinity (no `singleTask`) variant  – Caller ID case study
 
 **Caller ID (caller.id.phone.number.block)** 애플리케이션에서 보고된 취약점은 공격이 *기본 `standard` 실행 모드에 대해서도* 작동함을 보여줍니다:
 
-1. 공격자 애플리케이션이 가짜 루트 활동을 생성하고 즉시 자신을 숨깁니다:
+1. 공격자 애플리케이션은 가짜 루트 활동을 생성하고 즉시 자신을 숨깁니다:
 ```kotlin
 class HackActivity : AppCompatActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
-moveTaskToBack(true)   // 작업을 최근 목록에 유지하되 시야에서 벗어나게 함
+moveTaskToBack(true)   // 작업을 최근 목록에 유지하되 시야에서 벗어남
 }
 }
 ```
@@ -67,29 +67,68 @@ android:taskAffinity="com.caller.id.phone.number.block" >
 </intent-filter>
 </activity>
 ```
-3. 사용자가 악성 앱을 **한 번** 설치하고 열면, 피해자 패키지와 동일한 affinity를 가진 작업이 존재하게 됩니다 (하지만 백그라운드에 위치).
-4. 실제 Caller ID 애플리케이션이 실행되면, 안드로이드는 그 작업을 재사용하고 `HackActivity`를 foreground로 가져옵니다 → 피싱 창/권한 남용.
+3. 사용자가 악성 앱을 **한 번** 설치하고 열면 피해자 패키지와 동일한 affinity를 가진 작업이 존재하게 됩니다(하지만 백그라운드에 위치).
+4. 실제 Caller ID 애플리케이션이 실행되면 안드로이드는 그 작업을 재사용하고 `HackActivity`를 foreground로 가져옵니다 → 피싱 창/권한 남용.
 
-> NOTE: **Android 11 (API 30)**부터 시스템은 기본적으로 동일한 UID에 속하지 않는 두 패키지를 동일한 작업에 배치하지 않으므로, 이 특정 변형을 완화합니다. 이전 버전은 여전히 취약합니다.
+> NOTE: **Android 11 (API 30)**부터 시스템은 기본적으로 동일한 UID의 일부가 아닌 두 패키지를 동일한 작업에 배치하지 않으므로 이 특정 변형을 완화합니다. 이전 버전은 여전히 취약합니다.
+
+---
+
+### StrandHogg 2.0 (CVE-2020-0096) – Reflection-based task hijack
+
+구글의 2020년 5월 보안 공지는 **StrandHogg 2.0**이라는 더 고급 변형을 수정했습니다. 이 익스플로잇은 **전혀 `taskAffinity`에 의존하지 않으며**; 대신 *reflection*을 사용하여 공격자의 활동을 *모든* 실행 중인 작업의 맨 위에 동적으로 삽입하여 안드로이드 11에서 도입된 “shared-UID” 제한을 완전히 우회합니다.
+
+주요 사항:
+
+* 제로 권한 악성 앱은 한 번 열리면 실행 중인 작업을 반복하고 숨겨진 API를 호출하여 자신의 활동을 어떤 작업으로든 **재부모화**할 수 있습니다.
+* 활동이 런타임 후에 삽입되기 때문에 `launchMode`나 정적 매니페스트 분석으로는 공격을 사전에 감지할 수 없습니다.
+* **Android 8.0/8.1/9**에 체크를 백포트하여 패치되었습니다 (2020년 5월 SPL). **Android 10 및 이후 버전은 영향을 받지 않습니다.**
+
+패치되지 않은 장치에서의 탐지는 `adb shell dumpsys activity activities`를 사용하여 수행할 수 있으며, 작업의 *affinity*와 패키지 이름이 다른 의심스러운 활동을 감시합니다.
+
+구형 장치에 대한 완화는 고전적인 작업 탈취와 동일하며 **+** 런타임 검증(예: [`ActivityManager#getRunningTasks`](https://developer.android.com/reference/android/app/ActivityManager#getRunningTasks(int)) 호출 및 자신의 패키지 이름 검증)을 포함합니다.
 
 ---
 
 ## Detection & Exploitation checklist
 
-1. 대상 APK에서 `AndroidManifest.xml`을 가져와 각 `<activity>` (또는 전역 `<application>` 요소)가 `android:taskAffinity=""` (비어 있음) **또는** 사용자 정의 값을 포함하는지 확인합니다.
-2. 그렇지 않은 경우, 악성 앱을 제작합니다:
-- `android:taskAffinity` = 피해자 패키지 이름.
-- 사용자가 한 번 열 수 있도록 `MAIN/LAUNCHER` 인텐트를 제공합니다.
-- 선택적으로 즉시 숨기기 위해 `moveTaskToBack(true)`를 호출합니다.
-3. 피해자가 합법적인 애플리케이션을 열도록 합니다 → 하이재킹.
+1. **Static review** – 대상 APK에서 `AndroidManifest.xml`를 가져와 각 `<activity>` (또는 전역 `<application>` 요소)가 `android:taskAffinity=""` (비어 있음) **또는** 사용자 정의 값을 포함하는지 확인합니다. 도구 예시:
+```bash
+# apkanalyzer (Android SDK) 사용
+apkanalyzer manifest print app.apk | grep -i taskaffinity
+
+# AXMLPrinter2 사용
+java -jar AXMLPrinter2.jar AndroidManifest.xml | grep taskAffinity
+```
+2. **Dynamic review** – 장치에서 대상 앱을 열고 작업 목록을 나열합니다:
+```bash
+adb shell dumpsys activity activities | grep -A3 "TASK" | grep -E "Root|affinity"
+```
+루트 affinity가 피해자 패키지와 같지만 최상위 활동이 *다른* 패키지에 속하는 작업은 경고 신호입니다.
+3. 위에서 설명한 대로 악성 앱을 제작하거나 **[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
+```
+
+---
 
 ## Mitigation
 
 개발자는 다음을 수행해야 합니다:
 
-* `<application>` 수준에서 `android:taskAffinity=""`를 명시적으로 설정합니다 (권장) **또는** 각 활동에 고유하고 개인적인 affinity를 부여합니다.
-* 매우 민감한 화면의 경우, 위의 내용을 `android:launchMode="singleInstance"` 또는 현대적인 [`setLaunchMode`](https://developer.android.com/reference/android/content/pm/ActivityInfo#launchMode) 보호와 결합합니다.
-* 앱의 `targetSdkVersion`을 업그레이드하고 기본적으로 패키지 간에 작업이 공유되지 않는 **Android 11** 동작 변경 사항을 적용합니다.
+* `<application>` 수준에서 `android:taskAffinity=""`를 명시적으로 설정하는 것이 좋습니다 **또는** 각 활동에 고유하고 개인적인 affinity를 부여합니다.
+* 매우 민감한 화면의 경우 위의 방법과 `android:launchMode="singleInstance"` 또는 현대적인 [`setLaunchMode`](https://developer.android.com/reference/android/content/pm/ActivityInfo#launchMode) 보호를 결합합니다.
+* 앱의 `targetSdkVersion`을 업그레이드하고 기본적으로 패키지 간에 작업이 공유되지 않는 **Android 11**의 동작 변경 사항을 시행합니다.
+* **Android 12 (API 31) 이상**을 목표로 하여 필수 `android:exported` 속성이 개발자가 모든 외부 접근 가능한 구성 요소를 감사하도록 강제합니다.
+* 런타임 자기 방어를 고려합니다: 주기적으로 `ActivityTaskManager`를 쿼리하여 최상위 활동의 패키지가 자신의 것과 일치하는지 확인합니다.
+
+---
+
+## Related UI-Hijacking techniques
+
+작업 탈취는 종종 **tapjacking** (오버레이 기반 UI 속임수)와 결합되거나 대체됩니다. 2025년 **TapTrap** 연구는 완전히 투명한 *애니메이션 기반* 활동이 안드로이드 12–14에서 도입된 오버레이 터치 제한을 우회하고 여전히 사용자가 위험한 권한을 부여하도록 속일 수 있음을 보여주었습니다. TapTrap은 엄밀히 말하면 *작업* 탈취는 아니지만, 최종 목표(피싱 클릭)는 동일하므로 현대적인 평가에서는 두 공격 표면을 모두 확인해야 합니다.
 
 ---
 
@@ -99,5 +138,7 @@ android:taskAffinity="com.caller.id.phone.number.block" >
 - [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}}