Implicit PendingIntent

Description

Implicit intent vulnerabilities in Android applications, in particular implicit pending intent pose significant security risks. These vulnerabilities arise when developers use implicit intents without specifying the target component explicitly, relying on intent filters to determine the recipient. Attackers may exploit this by sending malicious intents that match the criteria of implicit intents, leading to unauthorized actions or access. Common issues include intent spoofing, where fake intents are crafted, and the potential for malicious applications to register intent filters that match the implicit intent criteria. Permission escalation, data exposure, and insecure components are additional concerns, below is a list of potential security issues that might arise from implicit pending intent

Intent Spoofing:
Attackers may attempt to send fake intents that match the criteria of the implicit PendingIntent. This could lead to unintended actions being performed by the application, potentially causing security breaches.
Malicious Intent Filters:
If intent filters are not carefully configured, malicious applications could register intent filters that match the criteria of implicit PendingIntent. This can result in sensitive actions being performed by unintended components.
Permission Escalation:
Implicit PendingIntent may lead to permission escalation if the target component requires certain permissions. An attacker might exploit this to trigger actions that require higher privileges, leading to unauthorized access.
Data Exposure:
If sensitive data is passed through implicit PendingIntent, there's a risk of data exposure if the intent is intercepted or manipulated. Developers should ensure proper encryption and validation of data sent through intents.
Dynamic Broadcast Receiver Registration:
Implicit PendingIntent triggering a Broadcast Receiver might be susceptible to attacks if receivers can be dynamically registered. Attackers could register their own receivers to intercept broadcasts and perform malicious actions.
Insecure Components:
If the target component (Activity, Service, Broadcast Receiver) specified by the implicit PendingIntent is not properly secured, it may be vulnerable to various attacks, including privilege escalation or data tampering.
Use of Untrusted Input:
If the implicit PendingIntent involves using untrusted input, such as data received from external sources, it might introduce vulnerabilities like injection attacks. Validate and sanitize inputs to prevent such security risks.
Unprotected Extras:
Passing sensitive information through extras in implicit PendingIntent without proper protection can lead to data leakage. Developers should be cautious about what information is included in extras and ensure it is properly secured.
Overly Broad Intent Filters:
If intent filters are too broad, they might match unintended components, increasing the attack surface and potentially allowing attackers to trigger actions that were not intended.
Failure to Check Caller Identity:
- Components launched by implicit PendingIntent should verify the identity of the caller to prevent unauthorized access. Failure to do so might result in security vulnerabilities.

Java

import android.content.Intent;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;

public class YourActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // Create an implicit base Intent and wrap it in a PendingIntent
        Intent base = new Intent("ACTION_FOO");
        base.setPackage("some_package");
        PendingIntent pi = PendingIntent.getService(this, 0, base, 0);
    }
}

Recommendation

Developers can address the vulnerability by applying any (or even better, all) of the following:

Ensuring that the action, package, and component fields of the base Intent are set (explicit Intent);
Ensuring that the PendingIntent is only delivered to trusted components;
Using FLAG_IMMUTABLE (added in SDK 23) to create PendingIntents. This prevents apps that receive the PendingIntent from filling in unpopulated properties. In case the app also runs on devices running SDK 22 or older, we recommend developers to apply the previous options while strengthening the PendingIntent creation with the pattern:
Being cautious with the data included in the intents.
Canceling PendingIntents when they are no longer needed.
Keeping your app updated with the latest Android security practices.

Java

import android.content.Intent;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;

public class YourActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        if (android.os.Build.VERSION.SDK_INT >= 23) {
            // Create a PendingIntent using FLAG_IMMUTABLE
            Intent base = new Intent("ACTION_FOO");
            base.setPackage("some_package");
            PendingIntent pi = PendingIntent.getService(this, 0, base, PendingIntent.FLAG_IMMUTABLE);
        } else {
            Intent base = new Intent("ACTION_FOO");
            base.setPackage("some_package");
            PendingIntent pi = PendingIntent.getService(this, 0, base, 0);
        }
    }
}

Links

Google

Standards

OWASP_MASVS_L1:
- MSTG_PLATFORM_2
OWASP_MASVS_L2:
- MSTG_PLATFORM_2
PCI_STANDARDS:
- REQ_2_2
- REQ_6_2
- REQ_6_3
- REQ_11_3
OWASP_MASVS_v2_1:
- MASVS_CODE_4
SOC2_CONTROLS:
- CC_2_1
- CC_4_1
- CC_7_1
- CC_7_2
- CC_7_4
- CC_7_5
- CC_9_1