Hacking Android Activity Intents

The mobile application shown below is a password manager which helps to manage and store passwords in a secure manner.

Details about the app used for this blog post can not be disclosed at this time, but it serves as real-life proof of concept for the vulnerability class of insecure Android intents.

Before explaining this vulnerability, let’s understand what are Android Activity Intents?

An Activity represents a single screen in an app. You can start a new instance of an Activity by passing an Intent to startActivity(). The Intent describes the activity to start and carries any necessary data.

For more information:
http://developer.android.com/guide/components/intents-filters.html

If intents are not secured via the AndroidManifest.xml file, these intents can be easily called to view other instances of intents hidden within the mobile application. These hidden intents could contain cached data which may potentially include the user’s sensitive cached data.

How can this vulnerability be exploited?

In the event that that a user’s mobile phone has been misplaced, a malicious attacker could bypass the passcode lock mechanism in the application in order to view sensitive information stored within the mobile application.

Due to insecure permissions on the AndroidManifest.xml file, these intents could be called manually to display on the mobile device.

Steps to exploit this vulnerability:

1. Extract the mobile’s application APK file from the mobile device

2. Review the mobile application’s AndroidManifest.xml file. Look out for activity with intents

3. Take note of package name and activity name

4. Connect mobile device to your PC, and connect to adb. Type in the following in terminal:

adb shell

su

5. Launch the vulnerable mobile application.

6. In another terminal type:

am start -n / to-intent-uri:MAIN

Within an ADB shell, the Activity Manager (am) tool can be used to interact with the Android Operating System by performing various system actions.

For more information: http://developer.android.com/tools/help/adb.html

7. After entering the above command, access to the whole mobile application on the victim’s mobile device will be granted. All passwords encrypted and stored on the device can now be accessed without knowing the decryption key or passcode.

How to fix this vulnerability?

Set android:exported = false on each Activity declared on the AndroidManifest.xml file.

This tells Android whether the content provider is available for other applications to use:

true: The provider is available to other applications. Any application can use the provider’s content URI to access it, subject to the permissions specified for the provider.

false: The provider is not available to other applications. Set android:exported=”false” to limit access to the provider to your applications. Only applications that have the same user ID (UID) as the provider will have access to it.

The default value is “true” for applications that set either android:minSdkVersion or android:targetSdkVersion to “16” or lower. For applications that set either of these attributes to “17” or higher, the default is “false”.

In the event that access need to be granted to other applications, you can still set android:exported=”true” and limit access to your provider by setting permissions with the permission attribute.

For more information: http://developer.android.com/guide/topics/manifest/provider-element.html