The app dynamically registers some unprotected broadcast receivers.
Broadcast receivers are an inter-process communication ingest mechanism, allowing apps to receive data in the form of intents coming from other apps. They can be statically declared in the Android Manifest or registered dynamically at runtime. The latter is known as Context-registered receivers, because their lifetime is bound to a given Context object in the app. For example, an Activity is a Context that may have broadcast receivers registered against it at runtime.
As with static receivers, dynamic ones can be exported, protected using permissions or using signature enforcement. If left unprotected, as is the case with this finding, third party apps can send data to these receivers.
The exact impact varies on case-by-case basis depending on how the app handles incoming broadcasts. Although many cases are harmless, commonly seen consequences for the affected apps are:
Performing unintended actions, perhaps on behalf of the user.
Displaying the incoming data to the user on behalf of the app for the purposes of phishing or social engineering, for example by loading a URL specified by the attacker into a WebView.
Exposing sensitive data, for example, by sending its own broadcast in response to the incoming one, or by writing it to a location accessible by other apps.
Steps to Reproduce
This test reverse engineers the application code and detects any context-registered broadcast receivers that have not been protected with permissions.
Business Impact
A malicious app installed on the device can attempt to send broadcast intents that trigger the unprotected broadcast receiver. These intents can modify the runtime of the app, making the app a potential phishing vector. If the sender app's broadcasts contain sensitive information, a malicious app may be able to perform intent sniffing, leaking sensitive data. Furthermore, a malicious app can register itself with high priority, if the broadcast is an ordered broadcast, to receive the broadcast first. If the malicious app is the first to receive the broadcast, it could cancel the broadcast causing a denial of service, or it could inject a malicious data into the broadcast.
Remediation Resources
The evidence table presents the class names and method names where unprotected broadcast receivers have been registered in the app's source code.
Open your source code and browse to the listed methods. Review how they construct the parameters to the registerReceiver calls, what the receivers do with the incoming data and whether they handle sensitive data.
Note that the results might contain instances from third-party code. To inspect the results from your own code first you can search for the package names that your app uses.
If the broadcast receiver handles sensitive information you need to restrict access to it. These are the options:
If your app is supposed to only send and receive broadcasts to itself, avoid both Broadcast Receivers and using LocalBroadcastManager, which is deprecated.
Instead, Google recommends using an observable pattern, such as androidx.lifecycle.LiveData or reactive streams, depending on your use case.
Note: for results pointing to third-party libraries included in your app you should consider inspecting them carefully to see if the affected broadcast receiver handles sensitive information and if that's the case, consider updating or replacing those libraries.
Finding Description
The app dynamically registers some unprotected broadcast receivers.
Broadcast receivers are an inter-process communication ingest mechanism, allowing apps to receive data in the form of intents coming from other apps. They can be statically declared in the Android Manifest or registered dynamically at runtime. The latter is known as Context-registered receivers, because their lifetime is bound to a given
Contextobject in the app. For example, anActivityis aContextthat may have broadcast receivers registered against it at runtime.As with static receivers, dynamic ones can be exported, protected using permissions or using signature enforcement. If left unprotected, as is the case with this finding, third party apps can send data to these receivers.
The exact impact varies on case-by-case basis depending on how the app handles incoming broadcasts. Although many cases are harmless, commonly seen consequences for the affected apps are:
Steps to Reproduce
This test reverse engineers the application code and detects any context-registered broadcast receivers that have not been protected with permissions.
Business Impact
A malicious app installed on the device can attempt to send broadcast intents that trigger the unprotected broadcast receiver. These intents can modify the runtime of the app, making the app a potential phishing vector. If the sender app's broadcasts contain sensitive information, a malicious app may be able to perform intent sniffing, leaking sensitive data. Furthermore, a malicious app can register itself with high priority, if the broadcast is an ordered broadcast, to receive the broadcast first. If the malicious app is the first to receive the broadcast, it could cancel the broadcast causing a denial of service, or it could inject a malicious data into the broadcast.
Remediation Resources
The evidence table presents the class names and method names where unprotected broadcast receivers have been registered in the app's source code.
Open your source code and browse to the listed methods. Review how they construct the parameters to the
registerReceivercalls, what the receivers do with the incoming data and whether they handle sensitive data.Note that the results might contain instances from third-party code. To inspect the results from your own code first you can search for the package names that your app uses.
If the broadcast receiver handles sensitive information you need to restrict access to it. These are the options:
RECEIVER_NOT_EXPORTED](https://developer.android.com/reference/androidx/core/content/ContextCompat#RECEIVER_NOT_EXPORTED()) when registering your receiver. This is only possible if your app targets Android 13 or higher or if you use theContextCompatclass from version 1.9.0 or higher of the AndroidX Core library.broadcastPermissionwith a signature permission when registering your receiver withregisterReceiver(BroadcastReceiver, IntentFilter, String, Handler).If your app is supposed to only send and receive broadcasts to itself, avoid both Broadcast Receivers and using
LocalBroadcastManager, which is deprecated.Instead, Google recommends using an observable pattern, such as androidx.lifecycle.LiveData or reactive streams, depending on your use case.
Note: for results pointing to third-party libraries included in your app you should consider inspecting them carefully to see if the affected broadcast receiver handles sensitive information and if that's the case, consider updating or replacing those libraries.
Risk and Regulatory Information
Severity: medium
CVSS: 4
Policy Category: Needs Remediation
Application
See more detail in the NowSecure Report
Evidence
| Class Name | Method Name | |---|---| | a5.a | l() | | a5.c | l() | | a5.e | h() | ... and 13 more