CWE-926: Improper Export of Android Application Components | Glexia
CWE-926 (Improper Export of Android Application Components) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE ATT&CK…
Glexia's Take · Automated analysis
CWE-926: Improper Export of Android Application Components
Improper Export of Android Application Components represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Availability Integrity: Unexpected State DoS: Crash, Exit, or Restart DoS: Instability Varies by Context: Other applications, possibly untrusted, can launch the Activity.
- Availability Integrity: Unexpected State Gain Privileges or Assume Identity DoS: Crash, Exit, or Restart DoS: Instability Varies by Context: Other applications, possibly untrusted, can bind to the Service.
- Confidentiality Integrity: Read Application Data Modify Application Data: Other applications, possibly untrusted, can read or modify the data that is offered by the Content Provider.
Developer Pattern
CWE-926 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-926, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-926: Improper Export of Android Application Components
The Android application exports a component for use by other applications, but does not properly restrict which applications can launch the component or access the data it contains.
The attacks and consequences of improperly exporting a component may depend on the exported component: If access to an exported Activity is not restricted, any application will be able to launch the activity. This may allow a malicious application to gain access to sensitive information, modify the internal state of the application, or trick a user into interacting with the victim application while believing they are still interacting with the malicious application. If access to an exported Service is not restricted, any application may start and bind to the Service. Depending on the exposed functionality, this may allow a malicious application to perform unauthorized actions, gain access to sensitive information, or corrupt the internal state of the application. If access to a Content Provider is not restricted to only the expected applications, then malicious applications might be able to access the sensitive data. Note that in Android before 4.2, the Content Provider is automatically exported unless it has been explicitly declared as NOT exported.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- This application is exporting an activity and a service in its manifest.xml: Because these components have intent filters but have not explicitly set 'android:exported=false' elsewhere in the manifest, they are automatically exported so that any other application can launch them. This may lead to unintended behavior or exploits.
- This application has created a content provider to enable custom search suggestions within the application: Because this content provider is only intended to be used within the application, it does not need to be exported. However, in Android before 4.2, it is automatically exported thus potentially allowing malicious applications to access sensitive information.
Remediation
- Build and Compilation: If they do not need to be shared by other applications, explicitly mark components with android:exported="false" in the application manifest.
- Build and Compilation: If you only intend to use exported components between related apps under your control, use android:protectionLevel="signature" in the xml manifest to restrict access to applications signed by you.
- Build and Compilation Architecture and Design: Limit Content Provider permissions (read/write) as appropriate.
Detection
- Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.