Android Security is Broken — Here’s How We Can Fix It

How Malware infects the Google Play Store and what security researchers can do about it

Why is Mobile Security Important?

Mobile device technology has exploded within the past 10 years, allowing anybody to carry a powerful computing device within the palm of their hand. These devices are always connected and provide services to help consumers go about their day to day lives. While mobile devices make life easier, these connected devices are constantly collecting data on our usage, location, communications and more. Mobile phones are increasingly becoming a part of our lives, and as a result, the data that they log is no longer just bits — it’s a piece of who we are.

While all this data can be useful for providing us intelligent services, users are often unaware of how much and what type of information is collected. And suppose this personal data got into the wrong hands? Our entire identity and privacy would be stripped away from us. It is imperative that users and researchers are aware of what is being collected, both for general awareness as well as for further improvement in the development of technology.

Mobile device operating systems such as Android, authorize the use of sensitive data only to applications that explicitly request them in the form of permissions. However, app developers tend to request excessive dangerous permissions that result in jeopardizing the privacy rights of the user. Every few months we hear about a new malware campaign that was able to infiltrate the walls of the Google Play store and infect millions of unsuspecting users. Even the so-called anti-Malware apps don’t offer any protection against these inconspicuous threats.

To address this issue, we designed a model to assign a risk score to applications based on a scope of dangerous permissions ranging from acceptable to harmful. To test our model, we developed a tool to pull and analyze the dangerous permissions associated with a set of real-world applications from different categories to determine the risk of such permissions. While most users typically accept the requested permissions for convenience sake, our research and development will assist in providing simple awareness of application risk.

How do Android Apps Access Personal Data?

When an application attempts to access protected resources such as personal information or sensor data, the OS checks at runtime to see if whether or not the requesting application was granted permission during installation. Sensitive permissions can only be accessed by trusted applications and are protected by Android’s permission system, which divides permissions into groups based on protection level. The groups are defined as follows:

  • Normal: Application level permissions that do not pose a serious risk when used.
  • Dangerous: Permissions that could potentially leak sensitive data or exploit dangerous system resources. These types of permissions must be confirmed by a user at install time.
  • Signature: Permissions that are only available to applications signed with the same private key.
  • Signature-or-system: Permission available only to applications installed in the system image, signed by the same certificate as the system.

Permissions are also broken down in respects to when users must verify and accept them:

  • Install-time: The user accepts permissions before they install the application.
  • Time-of-use: The user accepts permissions when they are used.

As the name implies, dangerous permissions have the most potential for threat to a user. A list of dangerous Android permissions can be found here.

Malicious Privilege Escalation

While this system of permission approval may sound secure on paper, the reality, according to research, is that only 42% of users are aware of which permissions their apps need, and only 30% know what actions their apps can perform with these permissions. Based on these studies, it is quite evident that the average mobile user is unaware of what their apps are capable of. As a result, harmful apps can exploit a user’s tendency to neglect app permissions by requesting dangerous system resources and escalating their privileges to collect personal data without being detected.

Developers Love Permissions

One of the most dangerous issues of the Android permission model is the fact that developers tend to assign more permissions to their app than the app needs to function. Developers may add permissions to their apps just in case the need arises, but rarely limit permissions to what gets the job done and nothing more (the least privilege principle). Doing so without user awareness evidently puts users at risk. For example, it would be natural to assume that a location-based restaurant recommendation app needs access to GPS data, whereas the use of the same permission requested in an independent developer’s calculator app would be less obvious. In fact, including such permissions in the manifest could endanger the privacy of the users of the application by way of privilege escalation.

Developing a Risk-Score Model

To classify apps based on the severity of potential threats, we had to generate a formula for determining the potential threat of an Android application based on the number of dangerous permissions requested and acceptable use cases. To accomplish this, we first had to identify what permissions were considered appropriate for specific applications. Naturally, different types of applications require a different set of permissions to accomplish their intended task. We decided to observe the following types of Android apps:

  • Social Media (Ex: Twitter, Facebook, Instagram, Skype)
  • Utilities (Ex: MyFitnessPal, Memory Cleaner, Scanner Radio, QR Barcode Scanner)
  • Games: (Ex: Clash of Clans, Flappy Crush, World of Candy)
  • Finance: (Ex: Robinhood, LafAmBank, Santander)
  • Productivity: (Ex: Pandora, Spotify, Firefox)

The next step was to assign a weight value to each dangerous permission within the scope of a specific application category. At a higher level, each dangerous permission found for a specific application belonging to an application category was given a value based on its risk level.

  • Green (Weight of 1) — A dangerous permission that is expected to be found for an application within the specified category.
  • Yellow (Weight of 3) — A dangerous permission that is suspicious behavior for a developer to be requesting.
  • Red (Weight of 5) — dangerous permission that has absolutely no reason to be requested by the application.

We then had to classify dangerous permissions based on the above scale for each application category. Unfortunately, there is no current objective way to measure the severity of dangerous permissions, so we had to subjectively analyze common use cases for each permission within each application category.

Types of Dangerous Permissions and Risk Score per Observed Category

Calculating Application Risk

From the weights and dangerous permissions categorizations as displayed above, we can calculate the risk score for each application analyzed. The risk score can be used to determine which application is most suspicious to download and which application category tends to request permissions outside the appropriate scope.

Mathematical Factors:

  • Risk Score (RS) — The total sum of the weights associated with each dangerous permission by category. To calculate the risk score, use the formula, weight.
  • N — Refers to the total number of dangerous permissions.
  • Danger Level: The final result indicating whether or not the downloaded application can be trusted based on the dangerous permissions requested.

To calculate the Danger Level, use the formula:

  • Danger Level = RS / N

Testing on Real World Android Apps

In order to test our scoring system for apps, we selected 30 apps of various categories to run with PermissionHunter. The apps selected were from both well-known publishers as well as smaller, unknown, and suspicious publishers. The idea was to get a wide range of results to ensure our scale is accurate. For example, a large messaging app such as Skype should have a relatively low-risk score; it shouldn’t have wildly unnecessary permissions and should have a certificate with a good key. On the other hand, it would not be surprising if a prank call app from an unheard-of developer in Asia received a higher score — it may be requesting permissions to access contact info, memory, or the ability to make calls.

Results

Average Risk Score per App Category

Based on our results, Utilities, Finance, and Productivity apps all had much higher average risk scores. Overall, some of the average scores were not exactly what we expected, but most anomalies were able to be accounted for or explained. More importantly, the results from our PermissionHunter tool seemed to match up with the eye test — suspicious looking apps were marked with higher risk scores, and apps from larger developers that were trusted had lower scores. Although having a wider range of app categories may have helped improve our accuracy, the results still matched up relatively well with the expected outcome.

Conclusion

At the end of the day, the last line of defense for preventing malware on Android devices is the responsibility of the user. Users should first and foremost only download apps from the Play Store, rather than online or from another third-party app store. Next, users should always check the basic information provided by an application to ensure that it does what it says. This could include reading reviews (especially negative reviews, because those can be especially telling) and by looking at permissions to ensure there is little chance of privilege escalation. Providing users with more information regarding their privacy and personal examples will most definitely aid users in choosing applications with fewer, more relevant permissions, and is imperative to mitigating the risk of downloading malicious Android apps.

writing about life, culture, and technology.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store