search

OWASP / owasp-mastg

The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS).
https://mas.owasp.org/
Creative Commons Attribution Share Alike 4.0 International
11.66k stars 2.31k forks source link

Android Oreo change: Install from unknown sources #954

Open commjoen opened 6 years ago

commjoen commented 6 years ago

You can now test whether the user is allowed to install unknown sources. This can help in checking the security posture of the device. It is a good idea to raise awareness with android developers to check whether there are fake apps in the appstore which should represent theirs and we should for L2 apps make the dev check whether unknown sources are allowed and if so, warned he user about this https://developer.android.com/about/versions/oreo/android-8.0-changes .

TheDauntless commented 6 years ago

Does it make sense to suggest the "unknown sources check" in the MSTG without support from MASVS? I also don't immediately see where it would fit in the MASVS.

I do like the suggestion for raising awareness for fake apps. Maybe we can add that to V1 of masvs? https://github.com/OWASP/owasp-masvs/blob/master/Document/0x06-V1-Architecture_design_and_threat_modelling_requireme.md

commjoen commented 6 years ago

It is actually part of a very long requirement: | **2.12** | The app educates the user about the types of personally identifiable information processed, as well as security best practices the user should follow in using the app. | | ✓ |

commjoen commented 6 years ago

We have been in a position at the masvs where we did a lot of user education controls and then we tried to shorten them again to one... which is this one... a best security practice is not to install apps from unknown sources for instance

TheDauntless commented 5 years ago

I'm probably missing something, but how exactly can you test this as a developer?

I can only end up at DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY, but that only tells you if the global policy is true / false. If it's "true", it could still either be checked or unchecked, it's just not enforced by a device policy.

commjoen commented 5 years ago

True, you're right about that. So, what happens if we combine it with https://stackoverflow.com/questions/10809438/how-to-know-an-application-is-installed-from-google-play-or-side-load ? Then you can see whether the current app came from the appstore or not and check what the global settings are... (or we focus on where the app is coming from only,..)

TheDauntless commented 5 years ago

Then I think that's a check that would belong in the app hardening section, since the thing you're detecting is a (potentially) fake copy being installed from a non-trusted source.

commjoen commented 5 years ago

Makes sense to me :)

cpholguera commented 5 years ago

It was hard to map this to the MASVS current requirements. First I thought we'd need to have an additional MSTG‑RESILIENCE one, something like:

| **8.?** | MSTG‑RESILIENCE‑? | The app detects, and responds to, being sideloaded and/or to being repackaged.  | ✓ |

But then I remembered seen already something about "Code integrity checks", that is in 0x5j "Testing File Integrity Checks (MSTG-RESILIENCE-3)". It says:

"There are two topics related to file integrity: Code integrity checks and file storage integrity checks"

For Code integrity checks: Integrity checks often calculate a checksum or hash over selected files

But MSTG-RESILIENCE-3 only mentions "tampering [...] within its own sandbox". It sounds, or can be understood as talking about "file storage integrity checks" only.

Solution Proposal

What about enhancing MSTG-RESILIENCE-3 instead of adding a new one?

From:

| **8.3** | MSTG‑RESILIENCE‑3 | The app detects, and responds to, tampering with executable files and critical data within its own sandbox. | ✓ |

to:

| **8.3** | MSTG‑RESILIENCE‑3 | The app detects, and responds to, tampering with its original executable files (e.g. being repackaged), runtime modifications of critical data within its own sandbox and/or being sideloaded. | ✓ |

And in the MSTG:

  1. rename "Testing File Integrity Checks (MSTG-RESILIENCE-3)" to "Testing App Integrity Checks (MSTG-RESILIENCE-3)"
  2. add the corresponding checks , e.g. how to
    • check if an app was sideloaded: "is PackageManager.getInstallerPackageName() != com.android.vending (or a given white/blacklist)?"
    • check if it was repackaged: "verify original signature?"

Of course, the bypass is obvious but as we already say in the MASVS:

Note that software protections must never be used as a replacement for security controls. The controls listed in MASVR-R are intended to add threat-specific, additional protective controls to apps that also fulfil the MASVS security requirements.

If you agree I'd gladly open a PR in MASVS with this change and another in the MSTG for the new title and checks :)

sushi2k commented 5 years ago

Hey Carlos, I like your suggestion and it definitely fit's best into the RE domain.

First I thought it's redundant to 8.6 or 8.4, but it they all touch different aspects (8.4 is checking if RE tools are present on the OS and 8.6 is about memory, not the files in the sandbox). So +1 for your suggestion.

commjoen commented 5 years ago

Hi there, i am fine to extend MSTG-RESILIENCE-3 in that direction. Please create a PR and then we can have this one in as a pr for the mstg as well.

TheDauntless commented 5 years ago

| 8.3 | MSTG‑RESILIENCE‑3 | The app detects, and responds to, tampering with its original executable files (e.g. being repackaged), runtime modifications of critical data within its own sandbox and/or being sideloaded. | ✓ |

That's a lot in one requirement. This check is mostly aimed at apps like games that need to prevent cheating (or other apps with heavy client-side controls). Modifications can also happen while the app is not running (e.g. modify a .dll or .so in /data/app/package/lib).

Finally, modifying assets may also be sensitive ("see-through walls") and I don't know if that's clear in the current description.

commjoen commented 5 years ago

As agreed: let's not put sideloading in the requirement, as it is used as part of android for work/ apple for enterprise. Sideloading should only be an indicator of a possible tampering if the sideloading source is different than the one recommended.

commjoen commented 5 years ago

So for now: let's keep the requirement as it is (technology achnostic) and focus on the ticket at hand: if we combine the global setting detection (DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY) with https://stackoverflow.com/questions/10809438/how-to-know-an-application-is-installed-from-google-play-or-side-load then we can at least have another indicator of whether the app has been tampered.

commjoen commented 5 years ago

and we can start explaining the user on how to get the app if there is a different installer used then required by the developer

cpholguera commented 4 years ago

On Android 8+, NFC beaming of APKs between devices bypasses the “install unknown application” security control. A rogue device like a payment terminal can use this vulnerability to infect devices with malware.

Fixed in the October 2019 security bulletin.

https://android-developers.googleblog.com/2017/08/making-it-safer-to-get-apps-on-android-o.html

https://wwws.nightwatchcybersecurity.com/2019/10/24/nfc-beaming-bypasses-security-controls-in-android-cve-2019-2114/

commjoen commented 4 years ago

We will discuss this next week

commjoen commented 4 years ago

Meeting notes: the focus of this issue should be to educate the user that the app should come from the right source where updates are allowed. So

  1. check whther the app comes from the designated app store
  2. check if 1 is not the case, then check if there are permissions set which explain why this was wrongly installed
  3. make a remark about that there are various threats on how unknwon apps can be installed (see https://github.com/OWASP/owasp-mstg/issues/954#issuecomment-546625594)