Android applications are built using modular components such as Activities, Broadcast Receivers, and Content Providers. When these components are improperly exported – meaning they are accessible to other apps – they present serious attack vectors for pentesters and malicious actors. Here, we explore the risks, methods of exploitation, and mitigation strategies for such misconfigurations.
What are exported components?
When a component in Android is marked as android:exported="true" in the AndroidManifest.xml, any app can interact with it – not just yours. This is often needed for system-level communication, but overzealous exporting (or forgetting to mark internal components as “false”) opens up vulnerabilities. Exported components include activities, broadcast receivers, and content providers.
Activities are screens that can be launched. If exported, they can be opened or misused by other apps.
Broadcast receivers listen to system or custom events. If exported, any app can trigger them.
Content providers share data between apps. Exported ones allow data access, insertion, or deletion by others.
Quick tip: The default for android:exported has changed over the years and varies by context. Always set it explicitly to avoid surprises.
Attacking exported activities
How do things go wrong?
If an activity is exported with no restrictions, any app (even a malicious one) or even ADB can start it, possibly bypassing UI flows, authentication, or accessing screens meant only for admins.
Typical attack flow
Discovery: Use tools like Objection, Drozer, or just analyze the APK and manifest for exported activities.
Manual launch: Launch the activity via ADB:
adb shell am start -n com.victim.app/.SensitiveActivity
Intent tampering: Pass crafted extras or parameters, potentially bypassing checks or causing unintended behavior.
Real-world example
A “forgot password” activity is exported but doesn’t check who’s launching it. An attacker could launch it directly and reset any user’s password.
Broadcast receivers: Silent but dangerous
Attack surface
Exported broadcast receivers are meant to receive system broadcasts – but any app can send them an intent.
Exploitation
Send a crafted broadcast via ADB or malicious app.
adb shell am broadcast -a com.victim.app.ACTION_RESET --es phone_number "attacker_number"
If the receiver triggers a sensitive action (sending SMS, changing user data), the attacker rides on the app’s permissions.
Lesson
Always restrict receivers. Use permission checks and avoid exporting unless needed.
Content providers: Data leaks and more
Attack surface
Content providers nage structured data (like SQLite databases or files) and can be accessed via URIs.
Attack steps
Enumeration: Use content CLI, Drozer, or similar tools to list provider URIs.
Data leakage: Query, update, or delete app data:
content query --uri content://com.victim.app.provider/secret
Worst case: Credentials, user info, or even app logic can be exfiltrated or tampered with if no permissions are enforced.
Mitigate
Assign read/write permissions; never export unless cross-app access is truly needed.
How pentesters find and exploit these flaws
Static review: Analyze the AndroidManifest.xml for components with android:exported="true", especially those with powerful capabilities or intent-filters.
Dynamic testing: Use tools like Drozer and ADB to interact with exported components, sending benign and malicious data to map and exploit the attack surface.
Reverse engineering: Decompile APKs (with jadx, apktool, etc.) to find what happens under the hood when a component is triggered.
Defending against component hijacking
For developers
Never export unless necessary: Use android:exported="false" by default.
Apply permissions: Use android:permission in the manifest for any component that must be exported; require custom permissions for especially critical operations.
Signature-level permissions: Use protectionLevel="signature" when sharing data between your own apps.
Validate input: Always check and sanitize data received via Intents or Content Providers.
Consistent manifest configuration: Explicitly set exported attributes for all components to avoid default misexposures.
Secure declarations example
Activity
<activity
android:name=".SensitiveActivity"
android:exported="false" />
Broadcast receiver
<receiver
android:name=".SensitiveReceiver"
android:exported="true"
android:permission="com.target.SPECIAL_PERMISSION"/>
Content provider
<provider
android:name=".MyProvider"
android:exported="true"
android:readPermission="com.target.permission.READ"
android:writePermission="com.target.permission.WRITE"/>
Conclusion
Testing for and exploiting misconfigured exported components is a core skill in Android pentesting. Recognizing and abusing these flaws provides access to sensitive functionality and data, but understanding mitigation is equally critical for building secure mobile apps. By combining static manifest review, runtime attacks (via ADB or Drozer), and sound permissions architecture, both attackers and defenders can master this essential area of app security.
References
https://developer.android.com/privacy-and-security/risks/android-exported
https://appsec-labs.com/hacking-android-apps-through-exposed-components/
https://www.varutra.com/attacking-android-components-content-providers/
https://redfoxsec.com/blog/how-to-exploit-android-activities/
https://developer.android.com/privacy-and-security/risks/insecure-broadcast-receiver
https://www.linkedin.com/pulse/exploiting-android-architecture-clear-gate-fippf
https://developer.android.com/privacy-and-security/risks/access-control-to-exported-components
https://mas.owasp.org/MASTG/tests/android/MASVS-PLATFORM/MASTG-TEST-0029/