-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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-0098] Add App Virtualization Environment Detection Not Implemented #2853
base: master
Are you sure you want to change the base?
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -2,17 +2,43 @@ | |||||
title: App Virtualization Environment Detection Not Implemented | ||||||
id: MASWE-0098 | ||||||
alias: app-virtualization-detection | ||||||
platform: [android, ios] | ||||||
platform: [android] | ||||||
profiles: [R] | ||||||
mappings: | ||||||
masvs-v2: [MASVS-RESILIENCE-1] | ||||||
|
||||||
draft: | ||||||
description: runs as a so-called "clone app" | ||||||
topics: | ||||||
- detection in place | ||||||
- Effectiveness Assessment (e.g. bypassing the detection) | ||||||
masvs-v1: [MSTG-RESILIENCE-3, MSTG-RESILIENCE-4, MSTG-RESILIENCE-5, MSTG-RESILIENCE-6] | ||||||
TheDauntless marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are there examples of app virtualization being used to dynamically analyse an application? It's possible, I guess, but why would you go this route vs just repackaging the app in the first place and add a debugger / frida / custom smali? If not, we should remove resilience-4 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's an alternative way. Many application protection solutions provide root detection, anti-repackaging, and dynamic instrumentation (Frida, LSPosed, etc.) detection guards but they can't effectively detect virtualization environments. Virtualization doesn't require root, most virtualizers don't tamper APK integrity in any way - two fewer checks to worry about for the attacker. Of course, it's not as efficient as using Frida on a rooted device but virtualization software provides a lot of its benefits as a trade-off. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Technically I can't immediately see how the virtualizers don't tamper with APK integrity. For cloning, the signature is definitely changed; for anything that wraps an APK, the signature is also changed (but calls to system APIs are hooked to return original signature, which is similar to hooking those things with Frida/xposed or smali patching). It's ok if we keep this, but it would be nice to have an actual example of this technique being used for dynamic analysis. Maybe gameguardian could be enough (dynamically creating cheats or disabling ssl pinning or intercepting requests?) but I have limited experience with gameguardian. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It really depends on virtualization software. Some tamper, some don't. I think everything comes down to writing actual MASTG tests and adding demos here. I was planning to do that in the next iterations. |
||||||
status: draft | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
--- | ||||||
|
||||||
## Overview | ||||||
|
||||||
Android app virtualization software is a potential vector for dynamic analysis and application tampering. Such software can partially or fully virtualize the Android system, enabling target applications to run in a controlled environment. It bypasses the Android security model by creating a more permissive environment that other threat tools can exploit, often without requiring the device to be rooted. | ||||||
|
||||||
Malware can exploit Android virtualization software by encapsulating legitimate applications within a virtualized environment, creating seemingly identical user experience. This kind of virtualization allows malicious actors to inject code that bypasses security measures, such as anti-tampering protections, enabling malware to execute fraudulent activities. | ||||||
|
||||||
Dynamic instrumentation tools, like [GameGuardian](https://gameguardian.net/forum/topic/20322-gameguardian-work-without-root/), can leverage Android virtualization software to operate on non-rooted devices. | ||||||
|
||||||
## Impact | ||||||
|
||||||
Maliciously used Android virtualization software can lead to a variety of security issues, including but not limited to: | ||||||
|
||||||
- **Unauthorized reading of application private data**: Malware utilizing Android virtualization software to virtualize a target application can access its private data. This can lead to exposure of sensitive user information, such as login credentials, financial data, and personal messages, compromising user privacy and security. | ||||||
- **Unauthorized alteration of application private data**: By injecting malicious code through virtualization, malware can modify private data within an application. This alteration can result in unauthorized transactions, changes to user settings, or tampering with the application's functionality, potentially causing financial loss or operational disruptions. | ||||||
- **Unauthorized escalation of privileges or identity theft**: Virtualization software can create a more permissive environment, enabling the execution of other malicious tools that would normally require root permissions. | ||||||
- **Circumventing security mechanisms**: Virtualizers can dynamically tamper with the application's memory without altering the application's integrity. This allows malicious code to bypass certain anti-tampering security measures. | ||||||
|
||||||
## Modes of Introduction | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This section seems to extend and overlap with the description of the weakness. It should focus on the ways in which an application can introduce this weakness. For example, the use of certain libraries or APIs, the declaration (or lack thereof) of certain attributes or permissions, etc. Anything that indicates that the app can be run inside a virtualization environment, or "on-device container" as Android calls it. Specific example: not opting out of on-device Android container apps via the REQUIRE_SECURE_ENV manifest flag. We'll use this information later to define the tests. |
||||||
|
||||||
Virtualization software introduces an additional layer between an application and its underlying operating environment, fundamentally altering how applications interact with system resources. This extra layer creates a more permissive environment, which can have significant implications for both legitimate use and potential threats. | ||||||
|
||||||
In a virtualized environment, the software effectively isolates the application from the actual operating system and hardware, allowing for a controlled and often more flexible interaction between the application and the system. This permissive environment can bypass standard security measures by providing enhanced privileges and capabilities that would not be available in a non-virtualized setting. | ||||||
aegis-dev marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
||||||
For example, by emulating or partially recreating the Android system within an application sandbox, virtualization software can enable behavior that might otherwise be restricted or monitored. This allows applications to execute in a way that sidesteps traditional security constraints, making it easier to analyze, manipulate, or modify their behavior. | ||||||
aegis-dev marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
||||||
## Mitigations | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we link to available resiliency tests, to make this more specific? And are there virtualization-specific tests that we can add to the MASTG? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. MASTG tests and links to existing tests are on my TODO list. I was planing to do that in following iterations. |
||||||
|
||||||
To mitigate the risks associated with Android virtualization software, developers should: | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Add something like "Opt out of on-device Android container apps via the REQUIRE_SECURE_ENV manifest flag" |
||||||
|
||||||
- **Verify platform integrity**: Some Android virtualization software either emulates the entire Android operating system or partially recreates it within an application sandbox. Checking for anomalies in the application process sandbox can help detect the presence of such virtualization software. | ||||||
- **Verify application integrity**: Certain types of Android virtualization software load the target application into their own process. Verifying application and process metadata can help detect both the presence of virtualization software and any potential tampering. | ||||||
- **Check the presence of malicious tools**: Android virtualization software is often used to run malicious tools on a device without root access. For example, [VirtualXposed](https://github.com/android-hacker/VirtualXposed) utilizes the [Xposed](https://github.com/rovo89/Xposed) based hooking framework. Monitoring for such tools can provide indirect indications of virtualization software, especially in the absence of root access. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's ensure we got everything from here, either for the weakness or for the underlying tests (things for the tests can be captured in the modes of introduction for now)
#2801
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, Android seems to refer to this as "On-device Android Containers" and provides these related articles we should refer to and link: