Who Owns Your Android Application?

In spite of the world’s most accomplished security professionals working on the Android platform, there have been cases where a user should not have ‘trusted’ the released application. Here are some precautions how developers can take to reduce vulnerabilities in Android applications
– Nazneen Rupawalla, Application Developer, ThoughtWorks

Just as with any software system, Android has its list of security concerns. And it’s a pretty tough competition between the Android platform developers on one side and the hackers on the other.
The flexible platform works on heavy collaborations between applications, and dependencies can range from simple to complex. In this scenario, the dependencies are bound to be exploited to acquire data, passwords, and eventually control over the application.
In this series, are listed a few security measures that can be adopted right from the development stage, to avoid ‘introducing’ vulnerabilities in Android applications.

Here is a typical Android application:
On studying the diagram, if one was asked to list down the components that could cause the Android device to leak data or capabilities, what would the most probable answer be?
Well, it should be every single component!

A typical Android Application

That’s right, every single component could be exposing data if developers do not take the necessary precautions during development.

For instance:
1.    The activities could leak personal data to the log file.
2.    The service could activate remote calls from other apps that don’t have permission.
3.    The settings file could be world readable or world writable allowing access to the service.
For e.g., an application requires the user’s location for a feature. As this is a temporary purpose, a developer could store the location obtained in a world readable file. But then Boom! we have another application accessing the location without requesting the appropriate permissions. The effectiveness of the permission model is nullified.
4.    The content provider could grant access to the database.
5.    The data transmitted over the network could be in clear text or there is the possibility of the web service being compromised.
Most of you might believe that with the Android permission model in place, there should not be any fear of compromising security. And yes, it is most often easier to write a secure app in Android than it is to write an insecure app but only when one knows what’s safe and what’s not safe.
Here are a few do’s and don’ts as well a few tools that could help one develop a secure application.
Dealing with IntentFilters
The Requirement:
The same service needs to be initiated for two different jobs.

The Implementation:
This code is for let’s say, Application 1.

The Issue:
Application 1 does two simple things - it uploads data and downloads data. A malicious app when run, can be observed to download data via Application 1. This is because the malicious app knows the ‘action’ that will trigger the service. Now, as the service was initiated via an implicit intent, Application 1 allows the malicious app to download data on its behalf.

Call Out Points:
Explicit Intents specify the component to start by name (the fully qualified class name). You typically use an explicit intent to start a component in your own app, because you know the class name of the activity or service you want to start. For example, start a new activity in response to a user action or start a service to download a file in the background.
Implicit Intents do not name a specific component, but instead declare a general action to perform, which allows a component from another app to handle it. For example, if you want to show the user a location on a map, you can use an implicit intent to request that another capable app show a specified location on a map.

The Solution:
An Intent Filter signals the Android system to expose components to other applications. So, it’s a good idea to make an explicit decision of whether or not to mark a component as exported. Android doesn’t require one to do so but, as discussed, there are security repercussions for not doing so.
If developers choose to set the value of ‘exported’ as ‘false’ in their intent filter definition, they can prevent accidentally exporting internal components.

In the AndroidManifest.xml:
Before:

After:

So breaking this down, if one does not ‘intent’ a component to be exported in their application and down the line, when an intent filter is added for any purpose, there is a clear possibility of the application inadvertently exporting that component. This is a security vulnerability, if nothing else.
Note: If you do wish to make your components available but only for limited use, there are permissions you can grant in the AndroidManifest.XML.
The above solution can solve what is called the Confused Deputy Problem.
What is a Confused Deputy Problem?
Let’s use an example to explain this further. An Android Operating System has a WiFi manager which is inside the system server. And Application 1 in the question has a service that talks to the WiFi manager.

In Scenario I -
1.    Application 1 asks the WiFi manager, whether it’s allowed to access WiFi.

Androip App with the Wi-Fi manager denies access to the Malicious App

2.    Application 1 would probably be granted the permission as it has requested for the appropriate WiFi permission during installation.
3.    If a malicious application that requests no such permission is installed, and it asks the WiFi manager for permission to access, it would be denied.
But what happens in the case of Application 1 exposing a component (perhaps, through an exposed intentfilter) that is part of the WiFi control? And the malicious application decides to ask Application 1 for access.

A component of an Application gives access to the Malicious App

In Scenario II:
1.    The malicious application asks Application 1 to access WiFi.
2.    Application 1 would ask the WiFi manager and grant the malicious application, the permission. This is because Application 1 has asked for the permissions during the installation.
3.    Application 1 could return some information back to the malicious application without having the correct permissions. This makes Application 1, the confused deputy.
Application 1 is being ‘deputized’ by the WiFi manager and leaks information to the other app without the correct permissions.
This can be avoided by, explicitly mark components as exported and granting appropriate permissions in the manifest file.