Security implication if android app can be installed on emulator

Question

I am working on ensuring security of my company's product. We have a mobile version of the product. This question is for the Android version

Background - Our product is a SaaS-based product and the app is meant to be used by different salespeople of tenant organisation. We have implemented different layers of control for ensuring secure (or more like safe) environment for our app -

• We check for root detection - (OS level check)
• Implemented SSL pinning - (Transport layer level check)
• Storing secrets in Android key chain
• Minimal local data storage. Encrypt local data (that needs to be stored)

and the list goes on. In short, right from the device to the communication layer to the server layer we are in the process of covering every corner.

The problem is we got one issue reported by one of the security researchers that says that as our app can be downloaded from the Android play store thus it can run on an emulator, and on an emulator, it is possible to bypass root detection. So it adds a huge threat and should be fixed immediately.

I searched, but I cannot find security implication that could be possible if app can be installed on the emulator. Also I checked if I might have to fix it, what could be the possible solution. There are checks like looking if the running environment is an SDK, check if features like camera or sensors are working, but all those checks can be bypassed in emulator also.

It is kind of critical for me because if I accept this issue our client will see it in report and insist on getting it fix. I'm coming up blank for the implication that I would have to explain to Management and developers (if I accept) and fix (that might be required later)

Update -

1. I want to clarify one thing that we never advocate root detection or any other client side security controls as a plus point of our app because we believe all client side protection can be bypassed at one point or the other
2. We keep on trying to build more secure architecture at the server level. But since client side also forms the part of eco-system so we cannot leave it unguarded.
3. We even try to implement controls at the communication layer (other than TLS) to ensure just by tapping in you cannot get everything

Whole idea is if we cannot control certain things we can at least make it difficult for malicious parties. Our primary focus is to secure our users data and controls are in place and in progress.

Also update from Pentester - After discussion with him, he said that he didn't understand the application security requirement. As per him all app should have root detection. We explained him that those things means secondary to us but if any client specific data is lying in plain sight or can be compromised because of misconfiguration in app or any vulnerability in app (like hard coded secrets) then that it is primary.

Based on input provided you guys I was able to make this distinction clear and help in closing down the issue. Earlier it was all noise because of this issue. Thanks to all

Answer 1

It is unclear what kind of security requirements you have in the first place and thus it is unclear if your security measures are sufficient or not.

Fully protecting against a malicious user using your application is not possible as long as you are not able to fully control the device of the user. This risk includes running the application on emulators but also includes running it on rooted or otherwise tampered device - and not all of this will be detected by whatever root detection method you use.

Instead you need to design your application so that a malicious user cannot do any harm to you or to other users but only to himself. This for example means having user specific secrets in the application and not using global secrets. This also means that you should not trust anything the application reports but instead verify if this make sense (i.e. not trust any self-reported high score in games or similar).

Answer 2

Whose security are you concerned for here, and what are you trying to protect? Are you trying to protect the users from having other people access their data, or are you trying to protect the company from reverse engineers attempting to look at how the app works because your API is insecure?

If you are purely attempting to protect the users' security, then there is no issue at all with having the app run in a VM unless you think users will run the app in a poorly secured VM and have their data stolen, which is both very unlikely and is their problem, not yours.

If you are attempting to prevent people from reverse engineering the app, then you are fighting a difficult battle because root checkers are easily bypassed. This is also almost always a pointless effort since the app should have nothing useful for an attacker if it was designed securely.

Also, keep in mind that sometimes security testing people will sometimes just make up non-issues if they fail to find any real issues since a blank report makes it hard to justify the money spent. If possible, challenge them on this statement and ask them to give a real world example of how this is actually an issue.

Answer 3

The classic and correct answer to your client is NOTANISSUE.

No client side software * * should ever be considered to be designed as secure, in the sense your question asks. They can't be. The client side software - be it web or app - is totally under the clients control, as is its environment, as is the total ability to rewrite/mod the software, or run it on an undetectably insecure or modified environment. That isn't a bug. That's inherent in the model * *.

The purpose of your various checks is to reduce the risks and raise the bar, as so often with security. It is not done to make the client secure or ensure client side security, and your client is incorrect in assuming that aim.

• * * With perhaps the sole exclusion of client side software where the entire client side software and its environment is designed and controlled with the purpose of creating a highly tamper-resistant and verifiable environment, such as Trusted Execution, or the firmware of some YubiKeys (that can't easily at all be downloaded or modified once flashed), or when the client is a remote system with its own security in place, such as well-secured failover servers syncing to each other over SSH.
  
  Even then, perhaps the specific module may be considered secure (for a certain threat model) but that still doesn't mean that anything else, such as a local app checking the dongle's response, is in any way secured.

Answer 4

I'm readign between the lines here, but I think I see where the researcher is coming from.

Your app has no business storing (or using) any secrets that could expose the data of other customers.

design your backend so that the secrets given to the frontend only give compartmented access to the backend services. then if a user roots their device they can only hack their own account.

Answer 5

I feel the need to advocate for the poor maligned pen-tester here.

What was this tester hired to do and with what scope?

If the app developer provided a white paper or security strategy etc. that claims root detection is part of their security strategy, then it is absolutely appropriate to point out root detection is a fiction for publicly available apks. It is not generally the tester's problem to figure out if the overall architecture is actually vulnerable on the client side and should only be run on controlled devices, or management just wanted the biggest possible list of "security features." He or she just reports it failed against the claims provided (that root detection is improving security.)

The "fix" is stop making claims that client side environment checks does anything for security so that you can have a bigger list of "security features".

The wording that implies this person said "being on playstore is a vulnerability" is OP's not theirs. (having had things I said restated incorrectly in a way that makes it wrong enough times in my own career...!)

Answer 6

I would not consider any of client-side or web applications as sufficiently safe stand-alone, i.e. without securing the solution server-side independently on the OS.

All security layers, validations and checks implemented inside the client-side application should be at least repeated with corresponding or stronger validations within your application server-side components.

What is more, using emulator to run the application means the emulator own vulnerabilities can harm the user's security, for example some vulnerabilities allowed attackers to perform remote code execution, information disclosure, steal backups and data, as well as gain access to emulator's inter-process communication functions*.

*Source: https://www.bleepingcomputer.com/news/security/bluestacks-flaw-lets-attackers-remotely-control-android-emulator/

Answer 7

There is little difference in between a JVM running on a hardware device or an emulator. Of course one could see if the OS build string has "generic" (which only the emulator has) and then exit the application, when it is a release build - but this provides zero improvement of the overall security (since the bytecode can easily be decompiled - and only the code-signing prevents changes to functionality to some degree). Besides, release builds are not configured as debuggable.

The point is, that when it cannot run on a rooted device - then it will not run on an (rooted) emulator.

Answer 8

Reliable root detection is impossible, due to obvious logical pen testing holes.

If the user has access to the apk, the user can also just analyze the apk and then call your server api's directly quite easily and bypass the application entirely or port the application to a different system. You need to rethink your overall approach to security if it's part of the strategy to protect your systems to detect if it's being ran on a rooted device - since you cannot even reliably know what is being ran.

The user can if they want decompile your application and just strip all the detection parts out of the application in the first place. The process would be just same as "cracking" software would be.

What you can do with the root detection is to just let an user know that you think their phone is rooted, as a security caution to the user - maybe the phone is rooted without the user knowing it? but even in such case you cannot rely on it. you can't know if it's actual hardware or not that you're running on. You cannot know if it's running on some system like knox where you can pay samsung to gain essentially root powers in the system(through the enterprise functionality - and yes it basically can grant you almost root like powers to mess with other applications and other applications components - the phone will appear as knox secure even then and unrooted).

Root detection and such usually end up in an application to deter hacking, but it's 100% the wrong approach to combating the problem. Sorry, but what you need is a cultural thinking change in the organization in regards of the security: you can't trust software that runs elsewhere to be what you think it is so pentesting for that is pointless.

edit: If you need some way to explain it to your superiors, you could try this: "If we could do this then that bit of code would be worth more than the entire company is ever going to be worth" - and that quote would still apply to your company even if you worked for Google.

Answer 9

The security researcher warning is right, but you must put this warning on the context of your application to know if it is relevant.

You listed the "root detection" as an important security feature of your app.

Being a security expert myself, I would point out that root detection can be easily bypassed. Not only on virtual machines: but in physical devices as well. Many frameworks that claim to do root detection do not detect many rooted devices and detect some normal ones as rooted. Even if was the case, the client-side of any application can be easily reverse-engineered. A motivated attacker will be able to access your back-end interface bypassing the client-side app altogether. This means that any checks on the client-side can be bypassed and any calculation messed with. No client-side check or calculation can be trusted.

It is possible to create a trusted client, but it requires proprietary hardware, proprietary operating system and software. Game consoles and cable networks do that, but still suffers a lot with piracy which should count as a good example of how difficult is to tamper-proof a device. This strategy is theoretically possible, but fails on practice because it is too expensive, steal and prevent investments on the product functionality that becomes weak and obsolete in front of its competition.

How secure does it need to be?

There is no such thing as a secure/safe app. Security is about understanding the risks, the likelihood and size of the losses it can cause and identify contingencies and mitigation strategies to keep a healthy profit margin. The questions you should be asking are:

• what happens when the "root detection" fails?
• what kinds of attacks the "root detection" is supposed to protect against?
• what is the likelihood of that to happen?
• what kinds of losses can a "root detection" fail cause?
• are there other protections against that?
• is it possible to detect those kinds of violations fast?
• is it possible to trigger contingencies that reduce or eliminate the losses?
• will the company still be profitable with those losses?

All important logic must be server-side

You seem bothered with the possibility of an attacker being able to install your app in a virtual environment. I suspect that many of the security checks and important calculations are on the client-side. If it is the case, you really need to redesign your app to move all controls to the server-side:

• The back-end interface APIs exposed to the user networks must require authentication of the user.

• The back-end interface APIs must limit what the user can see and do. The access limits should be imposed by the server-side, never by the client-side. With the exception, of course, of services that do not include sensitive information and commands;

• The back-end interface APIs must account for the possibility of brute-force attacks. An attacker can download huge portions of your database and guess weak passwords and confirmation codes by attempting them all.

• The internal APIs - those used by the back-end and not exposed to the user networks - compose an inner service layer that should use service users or client certificates to authentication. The information of the real user should be propagated to those services for logging purposes.

I know that this is very disappointing. With those restrictions, the back-end interface APIs must be very specific to the app workflows and therefore less reusable. Unfortunately, only internal APIs can be reusable. This also means the back-end developers will need to understand very well the user experience, the designed workflows and work closely with the front-end teams which are things most developers do not like or are prepared to do.

Even with all the important logic on the server, it is necessary to design the workflows to account for other risks

If the app follows the guidelines mentioned above, it does not matter if the client-side app is tampered with on an attacker's device. He or she will not be able to do anything other than what the user credentials they have would allow them to do via the official client-side app.

But if a real user device is rooted, malware will be able to:

• bypass rooted device detection;
• capture user credentials;
• redirect the user to a false page;
• redirect the user to a false app;
• remote control the device;

Those attacks are not very common. Those are difficult because usually require the user to do complicated procedures. But if the product is expensive or the information is too sensitive, those attacks must be taken seriously.

If your concern is because your "salespeople" deal with expensive products in which losses are large and not easily recoverable, you must consider secondary barriers such as:

• supervisor validation on larger operations;
• validate the delivery address with several external databases;
• improve tracking of the deliveries;
• impose time constraints on deliveries according to the risk.

If this still not enough, you may choose to provide a company-owned device that is locked to prevent external app installation and have the USB locked only to charge. I know a few people that walk around with three corporate phones of different companies all the time: it is still a thing.

Develop good logs and monitor them

Monitoring is also a good strategy to avoid many losses. Backtracking the losses on the logs allows better understanding on how they happen and what have failed, propose changes to the products or at least monitor that situations to get early warnings of similar situations on the future.

If the logs are detailed enough, there are techniques of behavior biometry that are easy to implement and can detect many kinds of intrusions and some kinds of operational mistakes early enough to prevent losses.

You have a desktop version?

When you said "We have a mobile version of the product", it sounded like you have another. Do you have a desktop version? Desktop operating systems are rooted by default and there is no app isolation. If you can live with a desktop version, you probably do not even need root detection in the first place.

It is a good thing to continuously improve security, and you should do it, but you can expect the mobile version to be safer than the desktop one unless you make a horrible mistake in the new development.