The Permission Slip Attack — Leveraging a Confused Deputy in Android with 'pSlip'

The Permission Slip Attack — Leveraging a Confused Deputy in Android with 'pSlip'

Speakers: Edward Warren, Security Analyst, Azara

Conference: ShmooCon

YouTube: https://www.youtube.com/watch?v=-_jUZBMeU5w

Overview

Edward Warren's ShmooCon 2025 talk, "The Permission Slip Attack," unveils a critical vulnerability pattern in Android applications that leverages the confused deputy problem. This attack allows an unprivileged, malicious application to coerce a trusted, privileged application into performing sensitive actions, specifically placing phone calls, without the user's explicit consent or the attacker's app possessing the necessary CALL_PHONE permission. Warren introduces pSlip, a specialized toolkit designed to identify applications vulnerable to this class of intent injection, along with other insecure coding practices like JavaScript scheme exploitation and hardcoded cryptographic keys.

The significance of this research lies in its exposure of a subtle yet widespread misinterpretation of Android's permission model by developers. While Android's intent system is designed for secure interprocess communication (IPC), errors in handling specific intent actions, particularly ACTION_CALL, can create a powerful bypass. The "Permission Slip Attack" highlights how seemingly innocuous design choices, such as exporting components with broad intent filters, can be weaponized to compromise user privacy and security, underscoring the continuous need for rigorous security analysis in mobile application development.

Background

▶ Watch: Talk introduction, agenda, and speaker background (2:00)

The "Permission Slip Attack" is rooted in the classic confused deputy security flaw, a concept familiar in various computing contexts, from operating systems to web applications. In essence, a confused deputy attack occurs when a trusted entity (the "deputy") is tricked by a less trusted entity into performing an action that the less trusted entity would not normally be authorized to do. For Android, this translates to a privileged application inadvertently granting its permissions to a third-party, untrusted application. Warren draws a parallel to Cross-Site Request Forgery (CSRF) in web hacking, where a browser acts as a deputy, granting permissions to an attacker.

Android's architecture relies heavily on Interprocess Communication (IPC), primarily facilitated by Binder and Intents. Intents are message objects used to request an action from another app component. They can be explicit (targeting a specific component) or implicit (declaring an action to be performed, letting the system find a suitable component). The Android permission model itself is structured into three main types:

• Normal Permissions: Granted at install time, these cover non-sensitive operations (e.g., vibrate, set alarm, access internet).
• Runtime Permissions: Introduced in Android 6.0 (Marshmallow), these require explicit user consent at runtime for "dangerous" actions (e.g., access GPS, camera, place a phone call).
• Signature Permissions: Enforced by cryptographic certificate, these ensure secure communication between apps from the same developer, often used for internal app components.

The core of the "Permission Slip Attack" hinges on the distinction between two specific intent actions:

• ACTION_DIAL: This intent safely pre-populates the phone dialer with a number, requiring the user to explicitly tap a "call" button to initiate the call. It does not require the CALL_PHONE permission for the calling app.
• ACTION_CALL: This intent, in contrast, directly initiates a phone call without any user interaction. Android documentation explicitly states that apps using ACTION_CALL must declare the CALL_PHONE permission in their manifest.

Warren's investigation revealed a crucial misinterpretation among developers. Many believed that if their application received an ACTION_CALL intent, the caller app (the malicious app in this scenario) was responsible for having the CALL_PHONE permission. However, the attack demonstrates that if a privileged, exported component of a vulnerable app is configured to accept ACTION_CALL intents, it effectively becomes a confused deputy. It uses its own CALL_PHONE permission (which it legitimately possesses as a dialer or related service) to execute the call on behalf of the unprivileged attacker, bypassing the CALL_PHONE permission check on the attacker's app. This subtle "slip" in understanding the permission delegation model forms the basis of the attack.

Key Findings

▶ Watch: Snapshot of Android's permission model (4:20)

The central discovery presented by Edward Warren is the Permission Slip Attack, a specific instance of intent injection in Android. This attack leverages a pattern of insecure coding where an unprivileged, malicious application exploits an exported component of a privileged "deputy" application. The deputy app, typically a phone dialer or a related service, possesses the CALL_PHONE runtime permission. By sending a crafted ACTION_CALL intent to this exported component, the malicious app can initiate phone calls without ever declaring or being granted the CALL_PHONE permission itself. This bypasses a fundamental security control designed to protect user privacy.

Warren highlights that the "devil is in the details" of Android documentation and its interpretation. While the documentation clearly states that ACTION_CALL requires the CALL_PHONE permission for the initiating app, this is often misconstrued by developers of the receiving (deputy) app. They incorrectly assume that the Android system or the calling application itself will enforce this permission. However, if the deputy application's component is exported (android:exported="true") and explicitly allows ACTION_CALL via an intent filter, it implicitly trusts any incoming intent and uses its own permissions to fulfill the request. This effectively turns the deputy into a proxy for unauthorized actions.

The prevalence of this vulnerability is a significant concern. Warren notes that despite the clarity of the documentation, he has found numerous vulnerable applications, even submitting reports for newly discovered instances just days before his talk. He mentions attributing "a lot" of CVEs to this attack pattern, underscoring that this is not an esoteric edge case but a recurring flaw in the Android ecosystem.

Beyond the CALL_PHONE permission bypass, the pSlip toolkit and Warren's research also uncover other critical findings:

• JavaScript Injection via Intent Filters: pSlip identifies instances where an intent filter allows for explicit invocation of the javascript: scheme. More alarmingly, it also detects scenarios where applications, even without explicitly listing javascript in their intent filters (e.g., only http or https), will still execute JavaScript payloads sent via an intent. This opens the door to client-side attacks, potentially leading to data exfiltration or other malicious activities within the context of the vulnerable app.
• Hardcoded Cryptographic Keys: The toolkit also scans for hardcoded AES or DES keys, often found in common Java libraries using SecretKeySpec or IvParameterSpec. This finding is particularly relevant for applications interacting with IoT devices (e.g., smart cameras, smart locks), where compromised keys can lead to physical security breaches. Warren mentions the "Open Sesame" talk at BSides London as an example of what can be done with hardcoded keys, highlighting the broader implications of such discoveries.
• Custom Permission Misconfigurations: While not extensively detailed in the talk, pSlip also detects issues with custom permissions, specifically when they are set to a "normal" protection level. This can inadvertently allow other applications to use these custom permissions without explicit user opt-in, creating another avenue for privilege escalation or unauthorized access.

These findings collectively paint a picture of an Android application landscape where common development practices and misinterpretations of security models lead to a range of exploitable vulnerabilities, extending beyond just the CALL_PHONE permission.

Technical Deep Dive

▶ Watch: Crucial difference: ACTION_CALL vs. ACTION_DIAL (6:00)

The technical core of the Permission Slip Attack revolves around the nuanced interaction between Android's Intent system, exported components, and runtime permissions. As previously discussed, the ACTION_CALL intent is designed to initiate a phone call directly, bypassing the user confirmation step, and thus requires the CALL_PHONE permission. In contrast, ACTION_DIAL merely pre-populates the dialer and is considered safe.

The vulnerability arises when an application, typically a pre-installed dialer or a communication utility, explicitly exports one of its components (e.g., an Activity, Service, or Broadcast Receiver) and configures an intent filter for that component to accept ACTION_CALL. The critical detail is the android:exported="true" attribute in the Android Manifest, which makes the component accessible to any other application on the device.

Consider a snippet from a vulnerable AndroidManifest.xml file, as shown in the talk:

In this scenario, a malicious, unprivileged application can craft an intent like this:

When startActivity(intent) is called by the malicious app, the Android system resolves this implicit intent. If com.vulnerableapp.CallActivity is the default or only component registered to handle ACTION_CALL with the tel scheme, the system will launch this activity. Crucially, because com.vulnerableapp.CallActivity is part of an application that does possess the CALL_PHONE permission (as it's designed to handle calls), it will execute the call using its own privileges, completely bypassing the permission check on the malicious calling app. The attacker's application never needs to request or hold the CALL_PHONE permission.

To identify these vulnerabilities at scale, Warren developed the pSlip toolkit. pSlip is a command-line utility designed for automated static analysis of Android Application Packages (APKs). Its primary features include:

1. Call Intent Detection: Scans AndroidManifest.xml files for exported components that declare an intent filter for android.intent.action.CALL (or similar dangerous call-related actions).
2. JavaScript Scheme Exploitation Detection: Identifies intent filters that explicitly allow the javascript: scheme. More importantly, it also flags components that accept http or https schemes, as Warren found that many applications will still execute JavaScript payloads even without explicit javascript scheme declaration in their intent filters. This is a critical vector for Cross-Site Scripting (XSS)-like attacks within the application's context.
3. Hardcoded Secret Detection: Utilizes jadx CLI to decompile APKs and search for patterns indicative of hardcoded cryptographic keys, such as SecretKeySpec or IvParameterSpec usage with static string values. This targets common weak cryptographic practices.
4. Custom Permission Analysis: Detects custom permissions defined with a "normal" protection level, which can lead to unintended access for other applications.

pSlip employs a multi-threaded approach for efficiency, leveraging APKTool for rapid manifest analysis (around 5 seconds for basic scans). For deeper code analysis, particularly for hardcoded secrets, it integrates jadx CLI. This jadx step is more computationally intensive, increasing scan times from seconds to potentially 30 seconds or a minute, depending on the APK size and complexity.

The output of pSlip is designed to be intuitive, presenting findings in both a command-line interface (CLI) and an exportable HTML format. The format typically includes Package, Component, Issue Type, and Details, allowing security analysts to quickly pinpoint vulnerable areas. For instance, a CLI output might show:

The ability to export results to HTML enhances readability and facilitates sharing within security teams. This systematic approach allows researchers and developers to quickly identify and address these classes of vulnerabilities, which often stem from subtle misconfigurations or incomplete understanding of Android's security model.

Demo / Proof of Concept

▶ Watch: Analyzing CALL_PHONE documentation and attack scenario (7:45)

Edward Warren's talk included a demonstration of the JavaScript injection vulnerability identified by the pSlip toolkit, rather than a direct live demonstration of the ACTION_CALL attack, though the latter is the primary focus of the "Permission Slip Attack" concept. The demo repurposed a previous research effort titled "Exposing and Addressing Security Vulnerabilities in Browser Text Input Fields."

The context for this demo is critical: many applications, particularly embedded web views or custom browsers, store sensitive user credentials (like passwords) behind asterisk fields. This previous research categorized two types of vulnerabilities:

• Type A: Malicious browser extensions gaining access to credentials within the Document Object Model (DOM) tree.
• Type B: Websites literally storing passwords directly within the outer HTML field, making them accessible.

Warren's demo showcased how an application vulnerable to JavaScript injection via an intent filter could be exploited to exfiltrate these saved credentials. Even if an application's intent filter does not explicitly list the javascript: scheme, but accepts http or https, it might still execute a JavaScript payload.

The demonstration involved a scenario where a user enters their password into a vulnerable application's input field. The core of the proof of concept was an injected JavaScript payload. While the demo itself showed an alert() box displaying the password stored behind the asterisks, Warren noted that in a real-world attack, this JavaScript could easily be modified to exfiltrate the credentials to an attacker-controlled server.

The payload, sent via an intent to the vulnerable, exported component, would look something like:

This payload, when executed by the vulnerable application's web view, would access the DOM, locate the password input field, retrieve its value, and display it in an alert box. The demo visually confirmed that even without explicit javascript scheme support in the manifest, the application's component processed the JavaScript intent, illustrating a potent client-side vulnerability that pSlip can detect. This highlights the broader utility of the pSlip toolkit beyond just CALL_PHONE exploits, demonstrating its capacity to uncover critical data exfiltration vectors.

Defensive Implications

▶ Watch: Android M's impact on CALL_PHONE permission (8:30)

The "Permission Slip Attack" and the broader findings from the pSlip toolkit present several crucial defensive implications for Android developers and security professionals. Addressing these vulnerabilities requires a multi-layered approach, focusing on secure coding practices, rigorous manifest review, and a deeper understanding of Android's IPC mechanisms.

1. Minimize Exported Components: The most fundamental defensive measure is to avoid exporting application components unnecessarily. The android:exported="true" attribute should only be used when a component is explicitly designed to be interacted with by other applications. For internal components, android:exported="false" should be the default, or omitted if targetSdkVersion is 31 or higher, as it defaults to false in those cases. Limiting the attack surface is paramount.

1. Strict Intent Filter Configuration: Developers must be extremely cautious when defining intent filters.

• ACTION_CALL vs. ACTION_DIAL: For any component that interacts with phone numbers, ACTION_DIAL should be preferred over ACTION_CALL unless direct, user-interaction-free calling is an absolute requirement. If ACTION_CALL must be used, the component should implement robust caller permission checks.
• Scheme Filtering: Intent filters should precisely define the schemes they are designed to handle. Broad http or https filters should be carefully scrutinized for potential JavaScript injection risks. If a component is not designed to handle javascript: schemes, it should not implicitly execute them. Input validation and sanitization are crucial for any data received via intents, especially when rendering it in a web view.

1. Avoid Hardcoding Cryptographic Keys: The discovery of hardcoded AES or DES keys underscores a critical flaw in cryptographic hygiene. Sensitive keys should never be hardcoded directly into the application's source code or manifest. Instead, they should be securely derived, generated at runtime, or retrieved from secure storage mechanisms (e.g., Android KeyStore, secure remote servers). This is especially vital for applications interfacing with IoT devices, where compromised keys can have physical security consequences.

1. Prudent Use of Custom Permissions: When creating custom permissions, developers must carefully select the appropriate android:protectionLevel. Setting a custom permission to normal protection level can inadvertently allow any application to acquire that permission without explicit user consent, creating a potential privilege escalation path. For permissions that grant access to sensitive resources or operations, dangerous or signature protection levels are more appropriate, ensuring proper enforcement and user awareness.

1. Implement Caller Permission Checks: For exported components that handle sensitive intents, it's a best practice to explicitly check the caller's permissions at runtime within the component's code. Methods like checkCallingPermission() or checkCallingOrSelfPermission() can be used to ensure that the calling application possesses the necessary permissions before fulfilling the request. This adds an extra layer of defense against confused deputy attacks, even if the intent filter is broadly configured.

1. Regular Security Audits and Static Analysis: Integrating tools like pSlip or other static application security testing (SAST) tools into the CI/CD pipeline can help automate the discovery of these patterns early in the development lifecycle. Manual code reviews focusing on intent handling, component exports, and cryptographic implementations are also essential.

By adhering to these defensive strategies, developers can significantly mitigate the risk posed by the Permission Slip Attack and similar intent-based vulnerabilities, contributing to a more secure Android ecosystem.

Key Takeaways

• Confused Deputy Vulnerability in Android: The "Permission Slip Attack" demonstrates how a privileged Android application can be tricked into performing sensitive actions (like placing phone calls) on behalf of an unprivileged, malicious app, bypassing the Android permission model.
• Misuse of ACTION_CALL Intent: The core of the attack leverages a common developer misinterpretation regarding the CALL_PHONE permission, where exported components handling ACTION_CALL intents fail to verify the caller's permissions.
• Importance of Intent Filter Scrutiny: Thoroughly reviewing AndroidManifest.xml for android:exported="true" and associated intent filters, especially for dangerous actions like ACTION_CALL or schemes like javascript:, is critical to prevent intent injection.
• pSlip Toolkit for Automated Detection: The pSlip tool provides an effective way to automatically identify applications vulnerable to the Permission Slip Attack, JavaScript injection, and hardcoded cryptographic keys, streamlining security audits.
• Risks of JavaScript Injection via Intents: Even without explicit javascript: scheme declaration, some applications' web views will execute JavaScript payloads sent via intents, posing a significant risk for data exfiltration and client-side attacks.
• Secure Coding Practices are Paramount: Developers must prioritize minimizing exported components, employing strict intent filter configurations, avoiding hardcoded secrets, and carefully managing custom permissions to build robust and secure Android applications.

About the Speaker(s)

Edward Warren is a Security Analyst at Azara, specializing in uncovering vulnerabilities within complex software systems. He is a seasoned speaker at security conferences, having previously presented at ShmooCon on topics such as Android inter-app collusion, which served as a foundational segue for his current research into intent injection. Warren has a keen interest in discovering and analyzing software bugs, a passion that drives his contributions to the security community. His work with the pSlip toolkit exemplifies his practical approach to identifying and addressing prevalent security flaws in the Android ecosystem.