Skip to content

MASTG-TEST-0366: Exported And Unprotected Broadcast Receivers That Expose Sensitive Functionality

Overview

If an exported receiver 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 send a broadcast to it and invoke that functionality. See Android Broadcast Receivers for details on broadcast receivers, 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 broadcast receivers.

Example Attack Scenario:

Suppose a banking app declares a broadcast receiver that resets the user's password based on extras in the received intent, and the receiver is exported with no android:permission.

  1. An attacker reverse engineers the app and finds the exported receiver, the action it listens for, and the extras it reads (see Enumerating Broadcast Receivers).
  2. The attacker writes a malicious app that sends a broadcast targeting the receiver explicitly, with attacker-chosen extras.
  3. The receiver acts on the unvalidated extras and resets the password (and may disclose the old one to the log).
  4. The attacker takes over the account without any interaction from the victim.

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 Broadcast Receivers to list the exported broadcast receivers and their associated android:permission, including context-registered receivers found in the code.
  4. Use Static Analysis on Android to inspect the onReceive implementation of each exported receiver.

Observation

The output should contain a list of exported broadcast receivers and the relevant parts of their onReceive implementation, including how they use data from the received intent and any permission they require.

Evaluation

The test case fails if any exported broadcast receiver is not protected by an appropriate android:permission that restricts which apps can send broadcasts to it and exposes or performs sensitive functionality, for example by performing a security-relevant action or disclosing sensitive data when it receives a broadcast.

Further Validation Required:

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

  • Determine whether onReceive performs a security-relevant action or discloses sensitive data based on the received intent (for example, reading extras and using them to send a message or change state).
  • Determine whether the receiver validates the data it reads from the intent before acting on it.

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

  • Determine whether the receiver has a legitimate reason to accept broadcasts from third-party apps. If it doesn't, it shouldn't be exported.
  • If external access is required, determine whether the receiver is protected by an appropriate android:permission or an equivalent access control. Appropriate means the control matches the sensitivity of the receiver action and the set of apps that should be allowed to send broadcasts to 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.
  • Determine whether context-registered receivers are registered with RECEIVER_NOT_EXPORTED when they don't need to receive broadcasts from other apps.

Best Practices

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

Demos

MASTG-DEMO-0130: Sensitive Action Exposed Through an Unprotected Manifest-Declared Broadcast Receiver