Permissions are the basis of all application security on an Android device and can come with their own set of complexities to be aware of. Developers for Play Store and OEM applications very seldom make full use of the application security features available on the Android platform.
The majority of security-related Android media articles talk about malware that has been discovered or offer statistics relating to malware on the platform. A large percentage of these malware cases are simply requesting the appropriate permission to perform their misdeed. Whether it is requesting the READ_SMS permission in order to suck out all of your juicy SMSmessages or the SEND_SMS permission in order to send SMS messages to premium rate services, the word “permission” appears often when reading about Android security. This piece will discuss the more technical details of permissions security and describe how to secure your application’s endpoints with strong security configuration.
Users typically only interact with permissions, or are made aware of them, when installing new applications on their device. On these occasions, an activity is presented to the user that displays the permissions that the application is requesting. The permissions screen for the Twitter application looks like this:
The developer or security tester who had to look at the AndroidManifest.xml file associated with this application would see the XML describing the defined and requested permissions for the application. The way that a tester could map permissions names to more detailed descriptions of what they are for is by implementing the following code in Mercury (or slightly modified in a standalone application):
packageManager = self.getContext().getPackageManager() info = packageManager.getPermissionInfo("android.permission.ACCESS_FINE_LOCATION", 0) print self.getContext().getResources().getString(info.descriptionRes)
This reads the description attribute of the permission and effectively maps the permission named android.permission.ACCESS_FINE_LOCATION to its description: “Access precise location sources such as the Global Positioning System on the phone. When location services are available and turned on, this permission allows the app to determine your precise location.”
The risk to the user associated with each of these requested permissions, and the ability of other applications to request this permission, is defined by an attribute of the permission called its protectionLevel. These attributes can be seen in the above image at the top of the snippet of the Twitter application’s manifest. Each defined permission has an associated protectionLevel. This attribute can only be set by the application that originally created the permission, in its AndroidManifest.xml file. Based on the protection level of a permission, it may be displayed in the installation review screen as part of the hidden dropdown menu or more prominently displayed if it could pose a threat to privacy. It should be noted that this “risk rating” assignment is at the discretion of the application that defined the permission.
Protection Levels can be one of four following values:
Play Store applications that do not have any intention of sharing their data or functionality with applications from other developers should always define permissions with the signature protection level. This ensures that a malicious application cannot request this permission. This does not affect the application’s ability to integrate or communicate with other applications created by the same developer, as these applications would be signed with the same certificate.
An examination of the Twitter application’s manifest reveals that all except one permission defined by the application make use of the signature protection level. The permission named com.twitter.android.permission.AUTH_APP makes use of the dangerous protection level. This means that another application could successfully request this permission and access functionality on the Twitter application that requires it. This in itself does not constitute a risk: the functionality exposed to other applications that could attain this permission would have to be examined for its implications to be known.
A developer should always think about the permissions they are requesting and whether they are absolutely necessary. To illustrate the differences between a normal approach and a conservative security-driven approach to requesting permissions, consider a telephone directory application.
This application allows a user to search for telephone numbers of local businesses and then save these numbers to the user’s contact list. The normal approach to this would be to request the WRITE_CONTACTS permission and simply add the contact directly to the user’s contacts database. A more conservative approach would be to start the ContactEditorActivity with the information pre-populated. This is possible because of the flexible and modular IPC framework provided by Android. To test this approach to the problem, issue the following command indrozer which will start ContactEditorActivity without requiring any application permissions:
dz> run app.activity.start --action android.intent.action.INSERT --mimetype vnd.android.cursor.dir/contact --extra string name "MWR InfoSecurity" --extra string phone +123456789
The resulting activity from issuing this intent can be seen in the following screenshot:
This simple example demonstrates that there is often more than one way of performing a task, in order to give the user of the application a greater degree of control over what is happening on their device. This also reduces the required permissions and therefore reduces the impact of exploiting this application.
A general rule of thumb is that the more permissions that an application holds, the higher the impact of exploiting it becomes. If an application makes use of more permissions with a protection level of dangerous, then an application could access user data or perform actions on the device. This behaviour may catch the attention of attackers or could scare away potential users.
Some permissions held by an application have greater implications than others. Naturally, a permission that allows an application to read sensitive data, such as SMS messages and emails, has a greater impact on privacy than a permission that allows an application to collect battery statistics. In the same way, some permissions could help an attacker to compromise all of the data on the phone. One such permission is the INSTALL_PACKAGES permission.
The INSTALL_PACKAGES permission allows an application to install another Android package. Therefore, if an application holding this permission is exploited by a malicious entity, they could use it to install a Trojan application on the device with almost any permissions. It should be noted that only applications that come as part of the Android system image or signed by the same certificate as the “android” package can request this permission.
In many cases, phone vendors do not thoroughly vet which applications hold this permission on their devices and in the past MWR has found applications like document readers and web browsers holding this permission. This is a very dangerous practice that should be avoided. In general, an application that makes use of native code should not hold the INSTALL_PACKAGES permission. When using native code, there is significant potential for bugs which can allow the control of execution, and, combining this with the INSTALL_PACKAGES permission, can result in the installation of attacker-defined packages.
If insufficient security configuration is placed on applications that hold sensitive data, then a malicious or compromised application could gain access to this data. A security tester could look for the following, in terms of security on IPC endpoints (activities, broadcast receivers, services and content providers):
When reviewing a device, a security tester should bear in mind that there are some permissions that they would not have dealt with before, when assessing Play Store applications. Some permissions are unattainable for normal applications that do not come pre-installed on devices or are not signed by the same certificate as the “android” package (usually signed by Google but sometimes also modified by OEMs). Examples of some of these powerful permissions that use the signatureOrSystem protection level are:
Exploiting an application that holds one of these permissions could allow an attacker a great degree of control over the device and therefore over its data.