diff --git a/demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md b/demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md new file mode 100644 index 0000000000..e162feb114 --- /dev/null +++ b/demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md @@ -0,0 +1,33 @@ +--- +title: Demonstration of RASP Presence in a Mobile Application +platform: android +code:  [kotlin] +id: MASTG-DEMO-0021 +test: MASTG-TEST-0228 +--- + +### Sample + +The following code snippet demonstrates the implementation of the freeRASP security library SDK. freeRASP periodically scans the device for threats, monitors its state, and gathers data to generate detailed threat reports. Threats are detected and communicated to the app via listeners. In this example, the root detection scenario is simulated. + +{{ MastgTest.kt }} + +### Steps + +Start the device, in this case, the Android emulator: + +```bash +emulator -avd Pixel_3a_API_33_arm64-v8a -writable-system +``` + +**Note:** The snippet implements a simulated test for the freeRASP security library's root detection feature. The MastgTest class, which implements the ThreatDetected interface, includes various threat detection methods such as root detection, debugger detection, and emulator detection. The test specifically focuses on mocking the root detection functionality by invoking the onRootDetected() method, which logs the detection event and simulates app termination using the closeApp() method. + +Launch the app from Android Studio and check the log. The snippet will log the “freeRASP Threat: onRootDetected”. + +### Observation + +The RASP policy is only configured for root detection, other threats are not evaluated. The threat was detected immediately after app start. Sample includes commented-out code to forcefully terminate the app. + +### Evaluation + +The app didn’t utilise all the available security checks. It would be possible to bypass freeRASP API with Frida script or disable the termination method. diff --git a/demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MastgTest.kt b/demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MastgTest.kt new file mode 100644 index 0000000000..22cad77b14 --- /dev/null +++ b/demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MastgTest.kt @@ -0,0 +1,91 @@ +package org.owasp.mastestapp + + +import android.content.Context +import android.util.Log + + +// mock: freeRASP ThreatDetected interface +interface ThreatDetected { + fun onRootDetected() + fun onDebuggerDetected() + fun onEmulatorDetected() + fun onTamperDetected() + fun onUntrustedInstallationSourceDetected() + fun onHookDetected() + fun onDeviceBindingDetected() + fun onObfuscationIssuesDetected() +} + + +// MastgTest class implementing ThreatDetected +class MastgTest(private val context: Context) : ThreatDetected { + + + companion object { + const val FREERASP_THREAT_TAG = "freeRASP Threat: " + } + + + fun mastgTest(): String { + return simulateThreatDetection() + } + + + // Simulate a test by calling onRootDetected + fun simulateThreatDetection() : String { + onRootDetected() // mock root was detected by freeRASP + + + return "freeRASP Threat: onRootDetected" + } + + + fun closeApp() { + // finishAffinity() // Closes all screens of the app + // System.exit(0) // Completely exits the app process + } + + + + + override fun onRootDetected() { + Log.d(FREERASP_THREAT_TAG, "onRootDetected") + closeApp() // Standard method to forcefully terminate the app + } + + + override fun onDebuggerDetected() { + Log.d(FREERASP_THREAT_TAG, "onDebuggerDetected") + } + + + override fun onEmulatorDetected() { + Log.d(FREERASP_THREAT_TAG, "onEmulatorDetected") + } + + + override fun onTamperDetected() { + Log.d(FREERASP_THREAT_TAG, "onTamperDetected") + } + + + override fun onUntrustedInstallationSourceDetected() { + Log.d(FREERASP_THREAT_TAG, "onUntrustedInstallationSourceDetected") + } + + + override fun onHookDetected() { + Log.d(FREERASP_THREAT_TAG, "onHookDetected") + } + + + override fun onDeviceBindingDetected() { + Log.d(FREERASP_THREAT_TAG, "onDeviceBindingDetected") + } + + + override fun onObfuscationIssuesDetected() { + Log.d(FREERASP_THREAT_TAG, "onObfuscationIssuesDetected") + } +} diff --git a/tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md b/tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md new file mode 100644 index 0000000000..057878747a --- /dev/null +++ b/tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md @@ -0,0 +1,50 @@ +--- +title: Detection of RASP presence in mobile application +platform: android +id: MASTG-TEST-0228 +type: [static, dynamic] +available_since: 24 +weakness: MASWE-0103 +mitigations: +prerequisites: +--- + +## Overview + +RASP (Runtime Application Self-Protection) is designed to monitor and protect the application during runtime by detecting and responding to threats in real-time. The test verifies if the application can identify and react to unauthorised modifications, such as code tampering, root or jailbreak environment, and attempts to bypass security mechanisms. It also checks if the application has the ability to protect sensitive data and prevent unauthorised access to critical operations or features. + +By conducting this test, we ensure that the app is capable of defending against runtime attacks and maintaining its integrity even in compromised environments. If RASP techniques are not implemented or are improperly configured, the app may be vulnerable to various security threats, including data breaches, unauthorised access, and malicious modifications. + +## Steps + +1. Ensure that all security checks and protection mechanisms expected from RASP are present and enabled with the application. To test the RASP policy that the app enforces, a written copy of the policy must be provided. The policy should define available checks and their enforcement. For example: + - Root detection. + - Screen lock enforcement. + - Code integrity checks. + - Detection of dynamic analysis. + +2. Based on the previous step, attempt to simulate threats to test if the application reacts as expected. This can involve various scenarios such as: + - Launching the mobile application on a rooted device. + - Launching the mobile application on a device without a screen lock enabled. + - Attempting to repackage the application and launching it. + - Launching the application in an emulator. + +3. Verify that the application properly detects and responds to potential threats. There are various scenarios in which a mobile application can respond to these threats, such as: + - Killing the app. + - Warning the user about the detected threat. + - Logging information about potential risks to a database or SIEM. + +*** + +## Observation + +The output depends on the specific reactions set up for the mobile application. The results should demonstrate the app’s behaviour when a threat is detected or triggered, for example: +- Application is terminated. +- Application displays a warning message. +- Application sends information to a database or SIEM. Testers should ensure that the collected threat intelligence data are rich enough. + +*** + +## Evaluation + +The test case fails if the mobile application does not react as expected to the detected threats. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0103.md b/weaknesses/MASVS-RESILIENCE/MASWE-0103.md index 754b21baab..7e1f0d6386 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0103.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0103.md @@ -7,7 +7,11 @@ profiles: [R] mappings: masvs-v1: [MSTG-RESILIENCE-8] masvs-v2: [MASVS-RESILIENCE-4] + cwe: [250, 829, 749] +observed_examples: +- https://nvd.nist.gov/vuln/detail/CVE-2022-33317 + draft: description: e.g. Runtime Application Self-Protection, detection triggering different responses @@ -16,3 +20,61 @@ draft: status: draft --- + +## Overview + +RASP (Runtime Application Self-Protection) encompasses techniques such as root or jailbreak detection, unauthorised code or code execution, malware detection, system state, data logging and data flow. It provides a systematic, organised management approach to securing mobile applications in real time from potential threats. + +**These techniques:** + +- Ensure that the application flow remains secure and untampered at all times. +- Enable applications to detect and trigger responses to threats, such as: + - Warning the user. + - Killing the app. + - Locking access to certain features. + +*** + +Without RASP implementation, applications remain vulnerable to attacks during runtime. RASP techniques assure that the app continuously monitors both its own state and the device environment to detect threats like malware, root, or integrity issues. + + +**Additional benefits of implementing these techniques might include:** + +- Independent decoupled protection updates. +- Remote configuration of security rules. +- Threat intelligence gathering. +- Fast security incident remediation. +- Providing data for security analysis. + +*** + +Speed and timing of checks is also important and crucial for response times and ensuring no gaps in detection rounds, with control timing checking sensitive steps in the app. Incorporating RASP into an app ensures continuous protection from threats, ultimately minimising risk and improving overall security. + +## Modes of Introduction + +Mobile app security and user security can be disrupted in various scenarios, including: +- The application does not comprehensively process information and fails to account for system weaknesses or its own vulnerabilities, potentially leading to breached environment integrity. +- Direct reactions to detected threads are not properly executed or integrated into the application’s business logic. +- Security rules cannot be effectively defined based on discovered weaknesses, as this approach lacks the broader perspective needed to address all potential threats and ensure comprehensive protection. + +*** + +## Impact + +- **Loss of Control and Monitoring:** One of the key advantages of RASP is the ability to continuously control and monitor the mobile app’s state and the device environment in real-time. Without these features, the application may fail to detect or respond to unauthorised modifications, malware presence, or tampering attempts. +- **Missed Threat Intelligence:** Without continuous monitoring, security checks, and data logging, we lose a critical overview of potential threats, making it harder to identify emerging attack patterns and respond to malicious activities effectively. +- **Loss of Manageability and Updateability of Detection Techniques:** Without RASP, applications lose the ability to update security rulesets, reset policies/settings, and adjust risk scoring in older or already released apps. + +*** + + +## Mitigation + +- To enhance the security of your mobile application, implement detection mechanisms that continuously monitor the app's state and device environment. +- Implement response actions for detected threats to mitigate potential risks, such as: + Killing the app, + - Warning the user, + - Logging information about potential risks to the database. +- Use third-party solutions, which specialise in threat detection and real-time security monitoring (e.g. freeRASP). + +***