If you give your users company-issue Android devices, or allow them to use their own as part of your BYOD strategy, you are probably familiar with the struggle between them wanting to run apps on their devices and your security teams trying to protect the confidentiality and integrity of corporate data on many devices.
The security teams’ view is clearly justified: apps that “exfiltrate or leak sensitive data from the device” were identified as a significant risk in CESG’s recently published guidance on how to enable users to access protectively marked information on Android devices.
On the other hand, if your user has brought-their-own-device, it is understandable that they will want to use it as their own, keep personal information on it and install apps on it. Even with a company-issued device, your user will likely demand apps to help improve their productivity.
If this challenge is not managed properly, it can pose a significant threat to your corporate data and network.
The concern is that most users will install apps from an online marketplace: the Google Play Store, or any of the multitude of vendor-specific offerings. These marketplaces accept submissions from anybody, typically with very little in the way of verification of who they are.
This has led to marketplaces containing a large number of poor quality, or outright malicious, apps.
This isn’t a new problem and each marketplace now offers a different level of protection against malware – from none, in some cases, to sophisticated systems that try to identify malicious apps. The Play Store, for instance, uses a system known as ‘Bouncer’ to identify “potentially malicious software” uploaded to it and prevent it from being distributed.
Bouncer improved the quality of apps dramatically – when Google first announced it they reported a 40% decrease in the number of potentially-malicious downloads from the Play Store, then called the Android Market.
However, it’s not infallible. It was demonstrated soon after Bouncer’s release that it was possible to bypass some of the automated app verification mechanisms and to upload malicious apps to the Play Store regardless.
The Play Store solution also offered no protection against apps loaded from third-party marketplaces, or loaded directly onto the device (a technique known as “sideloading”). Recently, Google attempted to tackle this problem by rolling out a ‘Verify Apps’ feature in Android, which performs a cursory scan of every app installed, even if it did not come from the Play Store. This check can flag potentially-malicious apps and displays a warning to the user.
Whilst Verify Apps offers some improvements over Bouncer, it still has major drawbacks – the fact that it can be disabled in settings and it only displays a warning means that if your users tried to install a malicious app, it wouldn’t necessarily prevent them from doing so.
Are these controls enough to safeguard your sensitive corporate data? Probably not. They offer a level of protection, but not enough.
So how do you tackle this risk?
CESG recommend a view endorsed by MWR: that you maintain an “enterprise application catalogue”, a list of approved apps that your users can install on their devices. This list can be distributed through a corporate app store and enforced using a suitable MDM solution.
This is good advice and allows you to understand the risk posed by the Android devices used in your organisation much better. You can enable your users by giving them access to the apps they want and you can also help apps developers and the wider community to do Android security better, by sharing your acquired Android security knowledge.
However, it presents a whole new challenge: how do you review apps and decide whether to accept into your catalogue?
Organisations have, historically, outsourced their information security needs to third-parties where they can draw on the experience of domain experts. So, you could try to do this with the assessment or verification of your app catalogue.
This can be a good solution for apps handling particularly high-risk information, but the cost would soon become prohibitively high if you asked them to assess the dozens of low-risk applications that your users demand and what happens when they apps are updated?
As an organisation you have access to many of the same tools as domain experts, so you could perform the assessment of small updates and apps handling low-risk information in-house.
But how do you perform a suitable baseline security review of these apps?
To perform a baseline review, your security team must identify potential vulnerabilities through a mixture of decompilation and guess-work, before writing their own one-use apps to confirm and test the impact of these issues. This traditional security assessment methodology is labour-intensive and slow and can require your security team to have intimate knowledge of how to develop for the Android platform.
We have experienced the problems caused by this methodology ourselves when undertaking Android security testing engagements and through our clients who want to minimise the risk of using Android in their organisations.
In order to reduce the pain of Android security assessment, we pooled our knowledge and developed a toolset to help make Android assessments faster, easier and more consistent.
The toolset, drozer pro started life as an open-source offering which was overwhelmingly well received by our internal users, clients and the wider information security and development communities.
drozer pro helps to solve several of the key challenges that the community face when performing a baseline security assessment of an Android app.
You are able to perform a much faster assessment because much of the time-consuming process of developing test-case apps has been automated.
drozer pro’s automation features allow your security team to connect a test Android device (or run Android under an emulator) and quickly, and graphically visualise the real attack surface as recognised by the Android runtime. With this visualisation, they are able to take each attack vector and analyse it to identify potential vulnerabilities and then run proof-of-concept exploits against those vulnerabilities to assess the risk they expose you to.
In short, instead of spending time writing code, you security team are enabled to do what they do best – review attack vectors and identify the risk they pose.
Being able to quickly conduct a security assessment in this way is critical if you are going to maintain an enterprise application catalogue. It helps to reduce the total cost of implementing the project, because you have a quick and cost effective way to perform a simple baseline assessment of an app.