GitBook: [master] 3 pages and one asset modified

SUMMARY.md

@@ -120,6 +120,7 @@
 * [Android APK Checklist](mobile-apps-pentesting/android-checklist.md)
 * [Android Applications Pentesting](mobile-apps-pentesting/android-app-pentesting/README.md)
   * [Android Applications Basics](mobile-apps-pentesting/android-app-pentesting/android-applications-basics.md)
+  * [Android Task Hijacking](mobile-apps-pentesting/android-app-pentesting/android-task-hijacking.md)
   * [ADB Commands](mobile-apps-pentesting/android-app-pentesting/adb-commands.md)
   * [APK decompilers](mobile-apps-pentesting/android-app-pentesting/apk-decompilers.md)
   * [AVD - Android Virtual Device](mobile-apps-pentesting/android-app-pentesting/avd-android-virtual-device.md)

mobile-apps-pentesting/android-app-pentesting/README.md

@@ -95,6 +95,10 @@ The mitigation is relatively simple as the developer may choose not to receive t
 >
 > To enable touch filtering, call [`setFilterTouchesWhenObscured(boolean)`](https://developer.android.com/reference/android/view/View#setFilterTouchesWhenObscured%28boolean%29) or set the android:filterTouchesWhenObscured layout attribute to true. When enabled, the framework will discard touches that are received whenever the view's window is obscured by another visible window. As a result, the view will not receive touches whenever a toast, dialog or other window appears above the view's window.
 
+### Task Hijacking
+
+{% page-ref page="android-task-hijacking.md" %}
+
 ### Insecure data storage
 
 #### Internal Storage

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

@@ -0,0 +1,57 @@
+# Android Task Hijacking
+
+## Task, Back Stack and Foreground Activities
+
+A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack—the _**back stack**_\)—in the order in which each activity is opened.
+
+The activity that is **displayed** on the screen is called a **foreground** **activity** and its **task** is called the **foreground** **task**. At a time, only **one foreground task is visible on the screen**.
+
+This is some simple activity flow:
+
+* There's only Activity 1 in the foreground.
+* Activity 2 is started which pushes Activity 1 to the Back Stack. Now Activity 2 is in the foreground.
+* Activity 3 is started which pushes both Activity 1 and 2 to the Back Stack.
+* Now when Activity 3 is closed. The previous activity i.e., 2 is brought automatically to the foreground. This is how task navigation works in Android.
+
+![](../../.gitbook/assets/image%20%28550%29.png)
+
+## Task affinity and Launch Modes
+
+**Task affinity** is an attribute that is defined in each `<activity>` tag in the `AndroidManifest.xml` file. It describes which Task an Activity prefers to join.  
+By default, every activity has the same affinity as the **package** name.
+
+We'll be using this when creating our PoC app.
+
+```markup
+<activity android:taskAffinity=""/>
+```
+
+**Launch modes** allow you to define how a new instance of an activity is associated with the current task. The [`launchMode`](https://developer.android.com/guide/topics/manifest/activity-element#lmode) attribute specifies an instruction on how the activity should be launched into a task.  
+There are four different **Launch Modes**:
+
+1. standard \(Default\)
+2. singleTop
+3. **singleTask**
+4. singleInstance
+
+When the launchMode is set to `singleTask`, the Android system evaluates three possibilities and one of them is the reason why our attack is possible. Here they are -
+
+* **If the Activity instance already exists**: Android resumes the existing instance instead of creating a new one. It means that there is at most one activity instance in the system under this mode.
+* **If creating a new activity instance is necessary**: The Activity Manager Service \(AMS\) selects a task to host the newly created instance by finding a “**matching**” one in all existing tasks. **An activity “matches” a task if they have the same task affinity**. This is the reason why we can **specify the same task affinity as the vulnerable app in our malware/attacker's app so it launches in their task instead of creating it's own**.
+* **Without finding a “matching” task**: The AMS creates a new task and makes the new activity instance the root activity of the newly created task.
+
+## Attack
+
+The victim needs to have the **malicious** **app** **installed** in his device. Then, he needs to **open** **it** **before** opening the **vulnerable** **application**. Then, when the **vulnerable** application is **opened**, the **malicious** **application** will be **opened** **instead**. If this malicious application presents the **same** **login** as the vulnerable application the **user won't have any means to know that he is putting his credentials in a malicious application**.
+
+**You can find an attack implemented here:** [**https://github.com/az0mb13/Task\_Hijacking\_Strandhogg**](https://github.com/az0mb13/Task_Hijacking_Strandhogg)\*\*\*\*
+
+## Preventing task hijacking
+
+Setting taskAffinity="" can be a quick fix for this issue. The launch mode can also be set to **singleInstance** if the app does not want other activities to join tasks belonging to it. A custom **onBackPressed\(\)** function can also be added, to override the default behaviour.
+
+## **References**
+
+* \*\*\*\*[**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)\*\*\*\*
+