mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
android
This commit is contained in:
parent
15eda77173
commit
b585b2d3c6
@ -30,14 +30,20 @@ The `launchMode` attribute directs the handling of activity instances within tas
|
||||
1. **Malicious App Installation**: The victim installs the attacker's app on their device.
|
||||
2. **Initial Activation**: The victim first opens the malicious app, setting up the device for the attack.
|
||||
3. **Target App Launch Attempt**: The victim attempts to open the target app.
|
||||
4. **Hijack Execution**: Due to the matching task affinity, the malicious app is launched in place of the target app.
|
||||
4. **Hijack Execution**: At some point the app tries to open the **singleTask** view. Due to the matching task affinity, the malicious app is launched in place of the target app.
|
||||
5. **Deception**: The malicious app presents a fake login screen resembling the target app, tricking the user into entering sensitive information.
|
||||
|
||||
> [!TIP]
|
||||
> Note that for this attack to work the vulnerable view **doesn't need to have exported to true** nor it needs to be the Main activity.
|
||||
|
||||
For a practical implementation of this attack, refer to the Task Hijacking Strandhogg repository on GitHub: [Task Hijacking Strandhogg](https://github.com/az0mb13/Task_Hijacking_Strandhogg).
|
||||
|
||||
### Prevention Measures
|
||||
|
||||
To prevent such attacks, developers can set `taskAffinity` to an empty string and opt for the `singleInstance` launch mode, ensuring their app's isolation from others. Customizing the `onBackPressed()` function offers additional protection against task hijacking.
|
||||
To prevent such attacks, developers can:
|
||||
- Set **`**taskAffinity`** of the **singleTask** view to an empty string (`android:taskAffinity=""`)
|
||||
- Opt for the **`singleInstance`** launch mode, ensuring their app's isolation from others.
|
||||
- Customize the **`onBackPressed()`** function offers additional protection against task hijacking.
|
||||
|
||||
## **References**
|
||||
|
||||
|
@ -10,19 +10,27 @@ To confirm if the application was built on the React Native framework, follow th
|
||||
|
||||
3. Use the command `find . -print | grep -i ".bundle$"` to search for the JavaScript file.
|
||||
|
||||
To further analyze the JavaScript code, create a file named `index.html` in the same directory with the following code:
|
||||
## Javascript Code
|
||||
|
||||
If checking the contents of the `index.android.bundle` you find the JavaScript code of the application (even if minified), you can **analyze it to find sensitive information and vulnerabilities**.
|
||||
|
||||
As the bundle contains actually all the JS code of the application it's possible to **divide it in different files** (potentially making easier its reverse engineering) using the **tool [react-native-decompiler](https://github.com/numandev1/react-native-decompiler)**.
|
||||
|
||||
### Webpack
|
||||
|
||||
To further analyze the JavaScript code, you can upload the file to [https://spaceraccoon.github.io/webpack-exploder/](https://spaceraccoon.github.io/webpack-exploder/) or follow these steps:
|
||||
|
||||
1. Create a file named `index.html` in the same directory with the following code:
|
||||
|
||||
```html
|
||||
<script src="./index.android.bundle"></script>
|
||||
```
|
||||
|
||||
You can upload the file to [https://spaceraccoon.github.io/webpack-exploder/](https://spaceraccoon.github.io/webpack-exploder/) or follow these steps:
|
||||
2. Open the `index.html` file in Google Chrome.
|
||||
|
||||
1. Open the `index.html` file in Google Chrome.
|
||||
3. Open the Developer Toolbar by pressing **Command+Option+J for OS X** or **Control+Shift+J for Windows**.
|
||||
|
||||
2. Open the Developer Toolbar by pressing **Command+Option+J for OS X** or **Control+Shift+J for Windows**.
|
||||
|
||||
3. Click on "Sources" in the Developer Toolbar. You should see a JavaScript file that is split into folders and files, making up the main bundle.
|
||||
4. Click on "Sources" in the Developer Toolbar. You should see a JavaScript file that is split into folders and files, making up the main bundle.
|
||||
|
||||
If you find a file called `index.android.bundle.map`, you will be able to analyze the source code in an unminified format. Map files contain source mapping, which allows you to map minified identifiers.
|
||||
|
||||
@ -34,9 +42,53 @@ To search for sensitive credentials and endpoints, follow these steps:
|
||||
|
||||
3. It was fortunate that sensitive hard-coded credentials were found in the JavaScript code during the recon process.
|
||||
|
||||
### Change JS code and rebuild
|
||||
|
||||
In this case changing the code is easy. You just need to rename the app to use the extension `.zip` and extract it. Then you can **modify the JS code inside this bundle and rebuild the app**. This should be enough to allow you to **inject code** in the app for testing purpses.
|
||||
|
||||
|
||||
## Hermes bytecode
|
||||
|
||||
If the bundle contains **Hermes bytecode**, you **won't be able to access the Javascript code** of the app (not even to the minified version).
|
||||
|
||||
You can check if the bundle contains Hermes bytecode by running the following command:
|
||||
|
||||
```bash
|
||||
file index.android.bundle
|
||||
index.android.bundle: Hermes JavaScript bytecode, version 96
|
||||
```
|
||||
|
||||
However, you can use the tools **[hbctool](https://github.com/bongtrop/hbctool)**, **[hermes-dec](https://github.com/P1sec/hermes-dec)** or **[hermes_rs](https://github.com/Pilfer/hermes_rs)** to **disassemble the bytecode** and also to **decompile it to some pseudo JS code**. To do this, for example these commands:
|
||||
|
||||
```bash
|
||||
hbc-disassembler ./index.android.bundle /tmp/my_output_file.hasm
|
||||
hbc-decompiler ./index.android.bundle /tmp/my_output_file.js
|
||||
```
|
||||
|
||||
### Change code and rebuild
|
||||
|
||||
Ideally you should be able to modify the dissasembled code (changing a comparison, or a value or whatever you need to modify) and then **rebuild the bytecode** and then rebuild the app.
|
||||
|
||||
The tool **[hbctool](https://github.com/bongtrop/hbctool)** supports dissasembling the bundle and building it back after the changes have been performed, however it **only supports old versions** of Hermes bytecode.
|
||||
|
||||
The tool **[hermes-dec](https://github.com/P1sec/hermes-dec)** doesn't support rebuilding the bytecode.
|
||||
|
||||
The tool **[hermes_rs](https://github.com/Pilfer/hermes_rs)** supports rebuilding the bytecode, but it's actually a library and nto a CLI tool.
|
||||
|
||||
## Dyanmic Analysis
|
||||
|
||||
You could try to dynamically analyze the app would be to use Frida to enable the developer mode of the React app and use **`react-native-debugger`** to attach to it. However, for this you need the source code of the app apparently. You can find more info about this in [https://newsroom.bedefended.com/hooking-react-native-applications-with-frida/](https://newsroom.bedefended.com/hooking-react-native-applications-with-frida/).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## References
|
||||
|
||||
- [https://medium.com/bugbountywriteup/lets-know-how-i-have-explored-the-buried-secrets-in-react-native-application-6236728198f7](https://medium.com/bugbountywriteup/lets-know-how-i-have-explored-the-buried-secrets-in-react-native-application-6236728198f7)
|
||||
- [https://www.assetnote.io/resources/research/expanding-the-attack-surface-react-native-android-applications](https://www.assetnote.io/resources/research/expanding-the-attack-surface-react-native-android-applications)
|
||||
- [https://payatu.com/wp-content/uploads/2023/02/Mastering-React-Native-Application-Pentesting-A-Practical-Guide-2.pdf](https://payatu.com/wp-content/uploads/2023/02/Mastering-React-Native-Application-Pentesting-A-Practical-Guide-2.pdf)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
@ -12,6 +12,8 @@ In effect, it is **blinding the user from knowing they are actually performing a
|
||||
|
||||
In order to detect apps vulnerable to this attacked you should search for **exported activities** in the android manifest (note that an activity with an intent-filter is automatically exported by default). Once you have found the exported activities, **check if they require any permission**. This is because the **malicious application will need that permission also**.
|
||||
|
||||
You can also check the minimum SDK version of the app, checking the value of **`android:minSdkVersion`** in the **`AndroidManifest.xml`** file. If the value is **lower than 30**, the app is vulnerable to Tapjacking.
|
||||
|
||||
### Protection
|
||||
|
||||
#### Android 12 (API 31,32) and higher
|
||||
|
Loading…
x
Reference in New Issue
Block a user