Introduction
Many Android applications on the Google Play Store request a plethora of permissions to the user. In most cases, those permissions are actually required by the application to work properly, even if it is not always clear why, while other times they are plainly unnecessary for the application or are used for malicious purposes.
In a world where the user’s privacy is becoming one of the primary concerns on the internet, it is important for the users to understand the permissions each application is requesting and to determine whether or not the application really needs it.
In this blog post, we will go over what exactly these permissions are, and we will illustrate legitimate permission usages as well as several illegitimate permission usages. We hope that this blog post will help the reader understand that blindly granting permissions to an application can have a severe impact on their privacy or even wallet.
What are application permissions
If developers want their application to perform a sensitive action, such as accessing private user data, they have to request a specific permission to the Android system. The system will then automatically grant the permission to the application if the permission was already granted before, or the user will be shown a dialog asking for the user to grant the permission. Each granted permission allows the application to perform a specific action. For example, the permission android.permission.READ_EXTERNAL_STORAGE grants read access to the shared storage space of the device.
By default, Android applications do not have any permissions that allow them to perform sensitive actions that would have an impact on the user, the system or other applications. This includes accessing the local storage outside of the application container, accessing the user’s messages or accessing sensitive device information.
The Android operating system differentiates three types of permissions: normal permissions, signature permissions and dangerous permissions.
Normal permissions grant access to data and resources outside of the application sandbox which have very little risk to compromise user’s data or other applications on the system. Normal permissions declared in the application’s manifest are automatically granted upon installing the application on the device. Users do not need to grant these permissions and cannot revoke them. The android.permission.INTERNET permission, allowing the application to access the internet, is an example of normal permission.
Signature permissions grant access to custom permissions declared by an application signed with the same certificate as the requesting application. These permissions are granted automatically by the system upon installation. Users do not need to grant those permissions and cannot revoke them.
Dangerous permissions grant access to data and resources outside of the application sandbox which could have an impact on the user’s data, the system or other applications. If an application requests a dangerous permission in its manifest, the user will have to explicitly grant the permission to the application. On devices running Android 6.0 (API level 23) or above, the application has to request the permission to the user at runtime through a prompt. The user can then choose to allow or deny the permission. The user can later revoke any granted permissions in the settings of the application, in the device settings. On devices running Android 5.1.1 (API level 22) and older, the system will ask the user to grant all the dangerous permissions during installation. If the user accepts, all the permissions will be given to the application. Otherwise, the installation of the application will be cancelled. The android.permission.ACCESS_FINE_LOCATION permission, allowing the application to access the precise location of the device, is an example of a dangerous permission.
Android maintains a list of all the permissions and their protection level.
Legitimate permissions usage
While permissions can be dangerous as it allows the applications to access sensitive data or resources, permissions are also essential for many features of a regular application. For example, the Google Map application would not be able to work as intended if it was not granted permission to access the location of the device.
In this section, we will quickly go over a few permissions that are needed for an application to work properly. You will see that while most of the time the reason of the permission is obvious, it may sometimes not be clear why at all.
Let’s start with a basic example: KMI Weather, a Belgian weather application.
The KMI Weather application (version 2.8.8) declares the following standard permissions in its manifest:
android.permission.ACCESS_COARSE_LOCATIONandroid.permission.ACCESS_FINE_LOCATIONandroid.permission.ACCESS_NETWORK_STATEandroid.permission.INTERNETandroid.permission.WAKE_LOCKandroid.permission.VIBRATE
The ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION permissions are dangerous permissions used by the application to automatically fetch the weather data for the current city the device is in. The other permissions (ACCESS_NETWORK_STATE, Internet and WAKE_LOCK) are normal permissions and are therefore granted automatically by the system.
We can see in this first basic example that each requested permission has an obvious purpose for the application. However, this does not mean that the application will not misuse these permissions, as we will see in the next section.
In some cases, it is not clear why an application would request a permission. Let’s take for example the well-known Spotify application.
The Spotify application (version 8.5.41.531) requests the following permission in its manifest: android.permission.READ_PHONE_STATE. The permission allows the application to access the phone number, the device IDs, whether a call is active, and the remote number calling the device. Since Spotify is an application to listen to music, why on earth would it need such a permission?
As previously stated, the READ_PHONE_STATE permission allows the application to know whether a call is active or not. This is used by Spotify to pause the music when a call is received by the application, since users would not be happy if the music kept playing while they answer a phone call. In addition, the permission allows the retrieval of the device IDs, which are used by many applications for device binding and analytics purposes.
As was shown in the previous example, applications will sometimes request permissions which don’t appear to make sense in their context at first glance, but which are actually very useful for the application and the user’s experience.
The main problem with many permissions is that they cover many different functionalities. From the user’s perspective, it’s often very difficult to know what exactly a specific permission is used for. The Android team recognized this shortcoming and introduced a new API that allows the developer to explain why a specific permission is requested. This dialog can be shown before the user is asked for the permission:
In addition to the explanation, Android regularly fine-tunes their permissions to prevent confusion. For example, the permission READ_CONTACTS originally also allowed the application to access the call and message logs. This was changed in Android 4.1, where new permissions were added and the READ_CONTACT permission no longer gave access to the call and message logs.
Unfortunately, applications sometimes also request permissions which plainly do not make sense for the application or which are used ill-intentionally, as we will highlight in the next section.
Malicious permissions usage
In the previous section, we saw that applications sometimes request permissions which you would not think they would need at first glance while they have, in fact, a perfectly good reason to request them.
In this section, we will explore the other side of requesting permissions: malicious usage of permissions. We will explore four different scenarios, using real-world examples.
Data collections
The first scenario we will explore is probably the one most people have in mind when an application requests many permissions which don’t appear to make sense for the application: An application harvesting data about its users.
We will illustrate this scenario by using a well-known social media application, Facebook.
It is common knowledge that Facebook harvests data about its users for advertising purposes. The data collected by Facebook ranges from personal information you provided to the platform to call logs history and details about SMS. Here, we will focus on how Facebook gathered the latter.
Just like any other Android application, the Facebook application has to request permissions in order to access the data and resources outside of the application sandbox. If we take a close look at the permissions requested by an older version of the Facebook Lite application, we will see, among others, the following permissions: READ_SMS and READ_CALL_LOG. The first permission allows the application to get details about the SMS messages that were sent and received, and the second permission allows the application to retrieve the call history of the device. While the READ_SMS permission could potentially be used to get multi-factor authentication codes, or to allow the application to act as an SMS application, these permissions also allows a lot of personal data to be collected by the application.
You might think that this is easily resolved as you can just revoke the permission or not grant it in the first place, but before Android 6.0 this was not possible. If you wanted to have an application, you needed to grant all the requested permissions. As for later versions of Android, while it is indeed possible to not grant such permissions, many users will blindly grant them due to ignorance of the consequences or simply out of convenience. Some applications may even refuse to work without the specific permission.
In addition to the above, Facebook uses an alternative way of collecting user data: other applications. There are many instances of applications sharing data with Facebook. Should you grant a sensitive permission to such an application, your data might be shared with Facebook even if you carefully denied the related permissions to Facebook in the first place. As shown by a report from Privacy International, many applications share data they have on you with Facebook., by using the Facebook SDK.
Collecting data for advertising purposes is arguably a malicious usage of application permissions. Whether you’re against this kind of practice or not, it’s easy to agree that collecting such amount of data even for legitimate purposes poses a threat to the user’s privacy and might even impact entire communities. A great example of this is the Facebook-Cambridge Analytica data scandal, where sensitive user’s data was leaked and supposedly used to influence elections.
Note that in the case of Facebook, their business model entirely relies on this data collection and on sharing it with advertisers, which is now public knowledge. In addition, most permissions requested by Facebook are tied to features of their applications. For example, as already mentioned, the READ_SMS permission allows Messenger to be used as an SMS application, while having access to the location allows Facebook to link your images to specific locations, or to share your location with your friends if you want to.
There are many other applications, such as adware, which operate in a similar way, but arguably with more malicious intentions. Such applications will typically request a lot of permissions which will be used to gather data about the user, that will be shared with advertising networks in order to show highly targeted advertisements. More often than not, the requested permissions will have no other purpose than to gather data about the user.
Malware-like applications
The second scenario we will take a look at is applications requesting many permissions and using them to exploit the user or the device.
A good example of this is the Joker malware. Joker will subscribe the user to paid services without the user’s consent by leveraging dangerous permissions granted to the application. This is obviously not something you would want as you will get charged for a service to which you subscribed unknowingly.
The Joker malware will request the READ_PHONE_STATE permission to obtain the user’s phone number and then uses it to initiate subscriptions to paid services. Usually, the paid services will require a confirmation code sent to the provided phone number. The malware will therefore also request the READ_SMS permission to retrieve the confirmation code from the received SMS and ultimately confirm the subscription. The user will then be charged monthly for the service. You can take a look at the in-depth analysis of Joker for more information
This is far from the only example of how permissions could be used maliciously. Another example would be an application that requests the SEND_SMS permission and send SMS to premium numbers (i.e. FakeInst), or an application accessing the SD Card and exfiltrating documents of the user. Other malware-like applications will ask for very limited permissions and rely on those to exploit other legitimate applications with more extensive permissions to perform their malicious actions.
Luckily, Google usually reacts quickly to such applications and removes them from the Google Play Store, preventing further victims of such applications. However, despite their fast reactions, many users will have already downloaded the malicious applications and fall victim to them.
Abuse in legitimate permissions
In this third scenario, we will take a closer look at applications which do require specific permissions to work properly, but which will also abuse said permissions in ways that would not be expected from the users.
An example of such application would be an SMS application, requiring the permissions to read and send SMS, which abuses its permissions to send SMS to premium numbers or to intercept multi-factor authentication tokens, as discussed in this article. The read and send SMS permissions are legitimate permissions for an SMS application, the users will therefore naturally grant such permissions. However, the users do not expect the application to misuse these permissions the way it does, making the user pay for services they never subscribed to, or retrieve data allowing the malicious actor to access accounts of the user.
In such a scenario, the only thing the user can really do to protect their privacy is to stop using the application. This is however not something you would want every time as the application in question may be extremely convenient for the users. The choice then boils down to whether or not the user is willing to sacrifice their privacy to enjoy the convenience of the application.
In practice, such applications are not so common. Most of the time, malicious applications will rather request many permissions, even if they are not legitimate permissions for the application. In addition, malware rarely put a significant effort in having an application that appears to be legitimate. Instead, they will typically invest in hiding the application to the eyes of the user, or provide very limited feature and attempt to hide their malicious behavior in some other ways.
Abusing permissions of other applications
The last example of malicious usage of permissions is that of a malicious application which will abuse the permissions of a legitimate application on the device by exploiting its exposed features.
If a legitimate application requests dangerous permissions and then exposes a feature that uses that dangerous permission to the system, it allows any other application installed on the device to enjoy the permission without the need of requesting it. Let’s take for example a file explorer application with the permission to read files on the external storage. If it also exposes a provider that lets another application request the content of a given folder or file, it essentially allows the other applications to read files on the local storage, even if they do not have the READ_EXTERNAL_STORAGE permission. This is known as the Confused deputy problem.
A good example of this issue would be the Google and Samsung Camera applications which were identified vulnerable to such an attack in 2019. The applications exposed an unprotected feature that allowed another application to take pictures or videos through the Camera application. These pictures were written to the SD card, which is typical for Camera applications. A malicious application could request access to the user’s SD card, something that’s not suspicious by itself, send an Intent to the vulnerable app and then extract those images. Even worse, if Geolocation was enabled while taking the pictures, the application could extract that information from the image and essentially track the user without needing the LOCATION permission.
Unfortunately for the users, there’s nothing that can be done to prevent these kinds of issues, apart from hoping that the developers correctly protected any exposed features of their application.
Conclusion
Application permissions are essential for almost every application to work properly. However, as we saw in this blog post, the permissions can also be abused to collect data or to create malware applications. It is therefore important for the users to be able to tell when a permission makes sense for an application and when it does not.
Developers should provide the users with a clear reason on why the application requests the permissions it does in order to help the decision of the user. However, even when this is the case, legitimate permissions on legitimate applications can be misused and the decision of the user comes down to whether or not the user is willing to risk his privacy for the convenience of using the application as it is intended.
About the authors
3 thoughts on “How malicious applications abuse Android permissions”