Full Report
The goal of the talk was to figure out what a user could do with no permissions. Android has three types of permissions for actions: Application defined. These are permissions and capabilities defined in the appfest manifest for an application. Runtime Operations (Dangerous). Things like location, phone calls and other things must be verified every time they happen. System Permissions. These are things that require leaving the application, going to the Android settings and explicitly allowing the application to do. There are default permissions within Android for each application. The author of the post dove into what these were in order to analyze the attack surface. Some of these allowed for interactions with other applications, such as Chrome. If we don't have a permission, can we convince another app to do something for us? The first permission bypass was the INTERNET permission. If an application doesn't have this permission, then they cannot make web requests. However, the Chrome deeplink (implicit intent) allows sending an arbitrary request through it. Then, the response can contain the app to send the data back to. With this, the author was able to successfully make a web request without internet access! There is a special message called SYSTEM_ALERT_WINDOW which can only be called from extremely privileged locations. Of course, user applications cannot trigger this directly. But, can anything mimic this functionality? TOAST is used for displaying messages to the user. However, it can be used to display almost anything. From webviews, to pictures to videos which cover the entire screen. Theoretically, it has a time limit of 4 seconds. Naturally, the TOAST can be done over and over again to bypass this limitation though. The fake system message can be used for clickjacking and Ransomware. The clickjacking is particularly bad since we can hijack a click to approve location permissions or start a phone call. Overall, interesting research into bypassing the permission boundaries of the Android eco-system.
Analysis Summary
This analysis is based **only** on the provided context. The context describes research findings on permission boundary bypasses in Android that leverage implicit intents and system UI elements, but **it does not cite any specific CVE identifiers, product versions, or official patch information.**
Since no official CVEs or product versions were named, the corresponding fields below will be marked as "Not Specified."
# Vulnerability: Android Permission Boundary Bypass via Implicit Intents and System UI Manipulation
## CVE Details
- CVE ID: Not Specified
- CVSS Score: Not Specified
- CWE: Not Specified (Resembles Improper Access Control/Authorization)
## Affected Systems
- Products: Android OS (General analysis concerning how permissions operate)
- Versions: Not Specified
- Configurations: Applications lacking specific permissions (e.g., INTERNET permission).
## Vulnerability Description
The research explores bypassing Android's defined permission model when an application has no mandatory permissions. Two primary bypass vectors were identified:
1. **INTERNET Permission Bypass:** An application without the `INTERNET` permission cannot initiate web requests. However, by utilizing a Chrome **deeplink (implicit intent)**, the application can compel Chrome (which *does* possess the internet permission) to send an arbitrary web request on its behalf. The response handler can then be directed back to the originating application, achieving outbound web connectivity without proper authorization.
2. **SYSTEM\_ALERT\_WINDOW/TOAST Manipulation for Clickjacking:** While user applications cannot directly call the highly privileged `SYSTEM_ALERT_WINDOW`, the **TOAST** mechanism (used for brief user messages) can be manipulated. By repeatedly triggering TOASTs, an attacker can display custom content (WebViews, images, videos) that covers the entire screen, effectively bypassing the 4-second limit. This overlaid false system message can be used for clickjacking, hijacking user input to approve sensitive actions (like granting Location permissions or initiating phone calls), or deploying ransomware-like interfaces.
## Exploitation
- Status: PoC available (Author successfully demonstrated both techniques)
- Complexity: Low (Relies on standard Android IPC mechanisms like implicit intents)
- Attack Vector: Local (Requires installation of a malicious application)
## Impact
- Confidentiality: Potential (Data exfiltration possible via the forged web request)
- Integrity: High (Ability to trick users into granting high-privilege permissions or executing unintended actions)
- Availability: Potential (Ransomware scenario described)
## Remediation
### Patches
- [No specific vendor patches or version updates were referenced in the context.]
### Workarounds
- Security guidance against installing untrusted applications.
- User vigilance regarding unexpected on-screen overlays or prompts, especially those that might obscure critical permission dialogues.
## Detection
- **Indicators of Compromise (IOCs):** Applications making outbound network requests despite lacking the `android.permission.INTERNET` declaration in their manifest. Applications rapidly displaying UI elements that cover the entire screen and persist beyond expected short intervals (like standard TOAST notifications).
- **Detection Methods and Tools:** Static analysis tools looking for improper handling of implicit intents targeting system browsers, and dynamic analysis monitoring for excessive/abusive use of the TOAST API function (`android.widget.Toast`).
## References
- [Vendor advisories: Not Specified]
- [Relevant links - defanged: Not Specified]