Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MASWE-0103] - RASP Techniques Not Implemented #3074

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
---
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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This demo seems to focus on demonstrating how to implement a specific RASP solution, rather than a demo to achieve the test. If I am a developer who has a RASP solution for my application and I am testing it, I think I would need a demo that focuses on how I can demonstrate/confirm that RASP is implemented for my app. For this reason, I think this demo does not relate well to the Test.

It is also not typical for the OWASP demos to endorse tools (exceptions of course and preference for open-source utilities that are helpful in performing a given test).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"This demo seems to focus on demonstrating how to implement a specific RASP solution, rather than a demo to achieve the test."
I think the test can be used to assess majority of mobile app RASPs. At the same time the test tries to avoid duplicating other resiliency MASWEs (root detection, integrity verification, etc. are separated issues). I like that the demo is a minimal example utilizing the RASP that is free to use and has a public docs - easier to maintain in the future. It would be great to add more other RASPs in the future if possible. Do you have an experience with other RASPs that could be added?

"If I am a developer who has a RASP solution for my application and I am testing it, I think I would need a demo that focuses on how I can demonstrate/confirm that RASP is implemented for my app. For this reason, I think this demo does not relate well to the Test."
This is inherently dependent on the RASP product itself and the individual configuration / expected features / reaction etc. I think this works well as an example / guideline that could be extended in the future.

"It is also not typical for the OWASP demos to endorse tools (exceptions of course and preference for open-source utilities that are helpful in performing a given test)."
In this case we could make an exception for obvious reasons.


{{ MastgTest.kt }}

### Steps

Check failure on line 15 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md

View workflow job for this annotation

GitHub Actions / markdown-lint-check

Headings should be surrounded by blank lines

demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md:15 MD022/blanks-around-headings Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "### Steps"] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md022.md
Start the device, in this case, the Android emulator:
```bash

Check failure on line 17 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md

View workflow job for this annotation

GitHub Actions / markdown-lint-check

Fenced code blocks should be surrounded by blank lines

demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md:17 MD031/blanks-around-fences Fenced code blocks should be surrounded by blank lines [Context: "```bash"] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md031.md
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”.


Check failure on line 25 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md

View workflow job for this annotation

GitHub Actions / markdown-lint-check

Multiple consecutive blank lines

demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md:25 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md012.md
### Observation

Check failure on line 26 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md

View workflow job for this annotation

GitHub Actions / markdown-lint-check

Headings should be surrounded by blank lines

demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md:26 MD022/blanks-around-headings Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "### Observation"] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md022.md
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.


Check failure on line 29 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md

View workflow job for this annotation

GitHub Actions / markdown-lint-check

Multiple consecutive blank lines

demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md:29 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md012.md
### Evaluation

Check failure on line 30 in demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md

View workflow job for this annotation

GitHub Actions / markdown-lint-check

Headings should be surrounded by blank lines

demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MASTG-DEMO-0021.md:30 MD022/blanks-around-headings Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "### Evaluation"] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md022.md
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.
91 changes: 91 additions & 0 deletions demos/android/MASVS-RESILIENCE/MASTG-DEMO-0021/MastgTest.kt
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This demo seems to focus on demonstrating how to implement a specific RASP solution, rather than a demo to achieve the test. If I am a developer who has a RASP solution for my application and I am testing it, I think I would need a demo that focuses on how I can demonstrate/confirm that RASP is implemented for my app. For this reason, I think this demo does not relate well to the Test.

It is also not typical for the OWASP demos to endorse tools (exceptions of course and preference for open-source utilities that are helpful in performing a given test).

Original file line number Diff line number Diff line change
@@ -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")
}
}
43 changes: 43 additions & 0 deletions tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
---
title: Detection of RASP presence in mobile application
platform: android
id: MASTG-TEST-0228
type: [static, dynamic]
available_since: 24
weakness: MASWE-0103
mitigations:
prerequisities:

Check failure on line 9 in tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md

View workflow job for this annotation

GitHub Actions / codespell

prerequisities ==> prerequisites
---

## Overview

Check failure on line 12 in tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md

View workflow job for this annotation

GitHub Actions / markdown-lint-check

Headings should be surrounded by blank lines

tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md:12 MD022/blanks-around-headings Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Overview"] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md022.md
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

Check failure on line 17 in tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md

View workflow job for this annotation

GitHub Actions / markdown-lint-check

Headings should be surrounded by blank lines

tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md:17 MD022/blanks-around-headings Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Steps"] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md022.md
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:

Check failure on line 18 in tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md

View workflow job for this annotation

GitHub Actions / markdown-lint-check

Trailing spaces

tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md:18:298 MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 1] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md009.md

Check failure on line 18 in tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md

View workflow job for this annotation

GitHub Actions / markdown-lint-check

Lists should be surrounded by blank lines

tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0228.md:18 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "1. Ensure that all security ch..."] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md032.md
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would advocate for requiring an up-front test step that requires the determination of "in scope" RASP checks, I don't know if it needs to be captured as a written policy per se. Could simply be a statement of, prior to evaluating RASP checks ensure the test scope is defined based on your organizations required, or designed/implemented RASP checks, as the RASP configuration strategy may differ from organization-to-organization.

Alternatively, you could always rely on testing for all RASP checks related to the weakness, and failing the test, and leaving it to the organization to annotate why a failed test is acceptable based on their desired RASP configuration approach.

- 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.
47 changes: 47 additions & 0 deletions weaknesses/MASVS-RESILIENCE/MASWE-0103.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -16,3 +20,46 @@ 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).

Loading