[MASWE-0098] Add App Virtualization Environment Detection Not Implemented #2853
Conversation
|
Thanks a lot @aegis-dev! If you intend to continue working on this initial draft we can convert the PR to draft and once you're ready you can set it to "Ready for review". Should we do that? |
I did everything I planned to do. Everything depends on the review, so I think we should mark it as "Ready for review". |
cpholguera
changed the title
There was a problem hiding this comment.
First of all, thanks for your submission!
I started a review, but I think I actually need some more background information first. I also see that the original issue has very limited information, so I understand why you took this approach.
I only know app virtualization in the context of apps that allow you to 'install' other apps inside of them, for example to have multiple versions of the same Facebook app. The 'installation' then consists of extracting everything from the APK file, patching local system APIs (or app code directly) so that they are direct to the virtualization app rather than the system directly. This (supposedly) helps them create private environments for the different applications, even though they are effectively all running as the same user.
Do you have other examples of virtualization being used?
The examples of impact are also very similar to what a normal repackage would be. The app virtualization is kind of irrelevant in that case. Do we know cases of malware actually using virtualization techniques to repackage an app? I would think that the attack is always very app-specific and thus custom code modification is always needed.
On the other hand, end-users installing their financial application inside of one of these virtualization apps is definitely a risk, which is the main goal of this weakness. So to me it's more about protecting the end user in a normal flow, rather than the currently listed attacks.
But again, my experience with these kinds of apps is limited, so if you can share some resources of the different threats that you listed, I'd love to read them.
| - detection in place | ||
| - Effectiveness Assessment (e.g. bypassing the detection) | ||
| masvs-v1: [MSTG-RESILIENCE-3, MSTG-RESILIENCE-4, MSTG-RESILIENCE-5, MSTG-RESILIENCE-6] | ||
| masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] |
There was a problem hiding this comment.
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.
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.
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.
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.
|
Hi @TheDauntless! Thank you for taking the time to review this submission! The following link is a blog post that goes through the types of virtualization software I've encountered. It should answer most of your questions about virtualization types. Of course, I've never seen any security experts discussing or categorizing virtualization software at the time of blog post writing, so I am open to a discussion.
Malware that uses virtualization as a platform is a new concept. Here is the link to the first one that got investigated by Promon:
That is correct, however, I think it's only a fraction of all virtualization software families.
Yes, indeed. It's always about protecting the end-user. I think malware based on virtualization software will be (already is?) one of the biggest threats. Also, I would not exclude cheating in games. The GameGuardian is very popular and virtualization software is the main platform for distributing and using it on devices without root access. Dynamic analysis is definitely not the biggest focus of this weakness, however, I didn't want to exclude it either. Dynamic analysis in virtualized environment is actually a really clever technique that bypasses some of anti-tampering techniques like root detection, signature verification, code checksum verification, etc. Here is a link to my talk at the Droidcon 2023. I am showing small demo recordings of virtualization software being used in "malicious" way. Maybe that will give you some more context too. I hope I answered all your questions. I am open for discussions. Please, let me know if I can help with anything. 🙇 |
| - detection in place | ||
| - Effectiveness Assessment (e.g. bypassing the detection) | ||
| masvs-v1: [MSTG-RESILIENCE-3, MSTG-RESILIENCE-4, MSTG-RESILIENCE-5, MSTG-RESILIENCE-6] | ||
| masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] |
There was a problem hiding this comment.
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.
|
|
||
| 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. | ||
|
|
||
| ## Mitigations |
There was a problem hiding this comment.
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.
MASTG tests and links to existing tests are on my TODO list. I was planing to do that in following iterations.
Committing TheDauntless suggestion Co-authored-by: Jeroen Beckers <[email protected]>
Committing TheDauntless suggestion Co-authored-by: Jeroen Beckers <[email protected]>
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Also, Android seems to refer to this as "On-device Android Containers" and provides these related articles we should refer to and link:
| - detection in place | ||
| - Effectiveness Assessment (e.g. bypassing the detection) | ||
| masvs-v1: [MSTG-RESILIENCE-3, MSTG-RESILIENCE-4, MSTG-RESILIENCE-5, MSTG-RESILIENCE-6] | ||
| masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] | ||
| status: draft |
There was a problem hiding this comment.
| status: draft | |
| status: new |
| - **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.
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.
|
|
||
| ## Mitigations | ||
|
|
||
| To mitigate the risks associated with Android virtualization software, developers should: |
There was a problem hiding this comment.
Add something like "Opt out of on-device Android container apps via the REQUIRE_SECURE_ENV manifest flag"
|
@aegis-dev any updates on this? Thanks! |
|
@cpholguera I am too busy with my work right now. I can't address these comments immediately |
Thank you for submitting a Pull Request to the OWASP MASTG. Please make sure that:
If your PR is related to an issue. Please end your PR test with the following line:
This PR closes #2768.