Skip to content

MASTG-TEST-0364: Exported And Unprotected Activities That Expose Sensitive Functionality

Overview

If an exported activity does not define android:permission with a proper protection level and performs or grants access to sensitive functionality, another third-party app outside the intended trust boundary can start it with an Intent and reach that functionality without going through the app's intended flow. See Android Activities for details on activities, App Permissions for permissions and protection levels, and Inter-Process Communication (IPC) Mechanisms for the IPC model of Android.

This test checks whether the app exposes sensitive functionality through exported and unprotected activities.

Example Attack Scenario:

Suppose a banking app protects its account screen behind a login activity but also declares an unprotected account-details activity that is exported, for example by setting android:exported="true" and without any limiting android:permission.

  1. An attacker reverse engineers the app and finds the exported account-details activity (see Enumerating Activities).
  2. The attacker writes a malicious app that calls startActivity with an explicit intent targeting that activity by its component name.
  3. The account-details activity starts directly, without going through the login activity.
  4. The account-details activity displays the victim's account data without requiring authentication.

Steps

  1. Use Reverse Engineering Android Apps to reverse engineer the app.
  2. Use Obtaining Information from the AndroidManifest to obtain the AndroidManifest.xml.
  3. Use Enumerating Activities to list the exported activities and their associated android:permission.
  4. Use Static Analysis on Android to inspect the code of each exported activity.

Observation

The output should contain a list of exported activities and the relevant parts of their implementation.

Evaluation

The test case fails if any exported activity is not protected by an appropriate android:permission that restricts which apps can start it and exposes or performs sensitive functionality, for example by displaying sensitive data, performing a security-relevant action, or allowing a caller to bypass authentication.

Further Validation Required:

Inspect each exported activity using Reviewing Decompiled Java Code to determine whether it exposes sensitive functionality:

  • Determine whether the activity displays or returns sensitive data (for example, account details, messages, or stored secrets).
  • Determine whether the activity performs a security-relevant action (for example, changing settings or credentials).
  • Determine whether starting the activity directly bypasses an authentication step, such as a login or PIN screen, that the app relies on elsewhere.

Then determine whether external access to the activity is appropriately restricted for the functionality it exposes and the app's intended trust boundary:

  • Determine whether the activity has a legitimate reason to be started by third-party apps. If it doesn't, it shouldn't be exported.
  • If external access is required, determine whether the activity is protected by an appropriate android:permission or an equivalent access control. Appropriate means the control matches the sensitivity of the activity and the set of apps that should be allowed to start it.
  • Verify that the permission is effective for that trust boundary, for example by using a signature protection level or another control that is not broadly grantable to untrusted apps.

Best Practices

MASTG-BEST-0052: Restrict Access to Android App Components

Demos

MASTG-DEMO-0128: Sensitive Data Exposed Through an Unprotected Activity