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-0098] Add App Virtualization Environment Detection Not Implemented #2853

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from 2 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
44 changes: 35 additions & 9 deletions weaknesses/MASVS-RESILIENCE/MASWE-0098.md
Copy link
Collaborator

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

Copy link
Collaborator

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:

Original file line number Diff line number Diff line change
Expand Up @@ -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]
Copy link
Collaborator

Choose a reason for hiding this comment

The 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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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.

Copy link
Collaborator

Choose a reason for hiding this comment

The 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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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 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
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
status: draft
status: new


---

## 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
Copy link
Collaborator

Choose a reason for hiding this comment

The 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
Copy link
Collaborator

Choose a reason for hiding this comment

The 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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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:
Copy link
Collaborator

Choose a reason for hiding this comment

The 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.