Android’s Inter-Application
Model and Security Risks
Donald E Frederick
8/20/2012
References
• Information and text in these slides taken
from “Analyzing Inter-Application
Communication in Android” by Chin, Felt,
Greenwood, and Wagner (UC Berkeley)
• The article, slides, and ComDroid software
available at http://www.comdroid.org/
• Also, see Android’s documentation at
http://developer.android.com/guide/topics/se
curity/index.html
Presentation Organization
• Introduction
• Inter-app model (inter-process
communication)
• Security Risks / Attacks
• Example
• ComDroid
• Recommendations
Introduction - Android
• Provides a rich API and
allows the end-user
full customization
• Sandboxes application
– “mutually distrusting
principals”
– Default access to only
its own data
• Message passing
between
“components”
B
A
C
Introduction - Dangers
• If Sender does not correctly specify recipient
– Attacker can intercept the message
• If Component does not restrict from whom it
can receive messages
– Attacker can inject code
Introduction – Dangerous Examples
• SMS Message Spy Pro
– User facing activity functions as a tip-calculator
– Collects all SMS messages and sends them to third-party
– http://www.smrtguard.com/resource/sms-message-spy/
• MobiStealth
– Collects SMS messages, call, browser, and GPS histories
and sends them to third-party
– http://www.mobistealth.com/
• Many others
– Many bill themselves as security software for protecting
children, or even spying on a spouse
IPC - Intents
• Link applications and form the foundation of the
message passing system
• Are messages containing a recipient and data
(optional)
• Used for intra- and inter-app communication and
system-wide notifications (system broadcast Intents)
• Are divided into explicit and implicit
– Explicit: specifies a definite application
– Implicit: specifies a kind or categories
• Are delivered to components
IPC - Components
•
Activities
– Started with intents
– Can return data
– All UI is defined in an activity
•
Services
– Started with intents
– Background; no UI
– Other components bind to
•
•
Allows binder to invoke service’s methods (must be declared in the interface)
Broadcast receivers (3 types)
–
–
–
–
Work on intents, which may be sent to multiple apps
Background; no UI
Normal – sent to all registered receivers at once
Ordered – sent to receivers in order; any app can halt progression of message; apps can set
their own priority level
– Sticky – remain accessible after initial delivery; available to be re-broadcast to future (new)
receivers
•
Content providers
– Databases addressable by an URI
– Used for internal (app’s own) data needs
– Can be used to share data between apps
IPC - Components
• Activities, Services, and Broadcast Receivers can
send/receive Intents
• Intents (explicit & implicit) can
– Start Activities
– Start, stop, and bind Services
– Broadcast information to Broadcast Receivers
• To receive Intents, component must be declared
in the manifest
• By default, components can only receive internal
Intents
IPC – Exporting Components
• Public components can receive Intents from other apps
• Is public (exported) if either:
– EXPORTED flag is set
– At least one Intent filter
• Intent can contain
– Component name, an action, data, a category, extra data
• Intent filter constrains incoming Intents by
– Action: a general operation to be performed
– Data: specifies the type of data
– Category: additional information about the action
• No rule against multiple applications specifying the same Intent
filter
• Intent filters ARE NOT a security mechanism
IPC - Permissions
• Caller must have a certain permission
• Core system API does
– e.g., <uses-permission
android:name="android.permission.CALL_PHONE"
></uses-permission>
• Can specify a protection level
IPC – Protection Levels
• Normal
– Granted automatically
• Dangerous
– Granted during installation. If user does not accept, installation fails.
• Danger of Human Centipad
• Signature
– Granted only if requesting app is signed by the same developer that defined
the permission
– Useful for restricting component access to those apps under the control of the
same developer
• SignatureOrSystem
– Granted if meet the Signature requirement OR if installed in the system
application folder
– Market apps cannot install into the system app folder
– Device manufacturers or end-users can manually install into the system app
folder
Attacks
• Only consider attacks on exported components
– Consider non-exported components and exported
components with a Signature (or higher) permission level
to be private and not susceptible to the below attacks
• Type 1 - Intents sent to the wrong application
– Can leak data
– Broadcast theft, activity hijacking, and service hijacking
• Type 2 – Receiving external Intents
– Data corruption, code injection
– Malicious broadcast injection, malicious activity launch,
malicious service launch
Type 1 – Broadcast Theft
• Broadcasts (via implicit Intent) vulnerable to
eavesdropping and denial of service attacks
• Eavesdropping
– Risk when app sends public broadcast
– Can listen to all public broadcasts by creating a
“wide” intent filter
– No user feedback to sender that broadcast has been
read
Eve
Alice
Bob
Eavesdropping
• Denial of Service
–
–
–
–
Ordered broadcast vulnerable
Attacker sets priority to highest level
Can cancel broadcast
Can inject malicious code or data
• After all broadcast receivers receive the data, it is sent
back to the initial sender
Carol
Eve
Alice
Carol
Bob
Denial of Service
Type 1 – Activity Highjacking
• Malicious Activity launched in place
of desired Activity
Alice
– Either used as an irritation or phishing
• If multiple Activities have the same
Intent filter, then user is notified to
select the correct Activity.
• If highjacking is successful, a False
Response attack may then happen
– The attacker may return malicious code
or data to the user
Bob
Eve
Activity/Service
Highjacking
Alice
Bob
Eve
False Response
Type 1 – Service Highjacking
• Malicious Service bound to in place of
desired Service
Alice
– Can steal data, lie about tasks
• If multiple Services have the same
Intent filter, Android selects one at
random!
• If highjacking is successful, a False
Response attack may then happen
– The attacker may return malicious code
or data to the user
Bob
Eve
Activity/Service
Highjacking
Alice
Bob
Eve
False Response
Type 2 – Malicious Broadcast Injection
• Blindly trusts an incoming Broadcast
• Broadcast receivers most vulnerable
when register to receive system
actions, which makes the component
public
– Can be explicitly called
– Will fall for malicious broadcast if
Service doesn’t check the Intent’s action
• It should contain an action string that only
the system can add
Alice
Eve
Intent Spoofing
Type 2 – Malicious Activity Launch
• Exported Activities can be launched
by Intents (explicit or implicit)
• Launching an Activity can cause three
types of attacks
– Affect state, modify data
– Trick the user into thinking they are
changing settings in Malicious Activity,
but are really changing settings in the
Attacked Activity
– Leak information by returning a result to
the malicious code
Alice
Eve
Intent Spoofing
Type 3 – Malicious Service Launch
• Exported Services can be started
and bound to
• A malicious Service launch is
similar to a malicious Activity
lanuch
• Since Services relay on input data,
there a greater chance to put the
Service at risk
Alice
Eve
Intent Spoofing
ComDroid
• ComDroid is website and server-side software
the checks apks for vulnerabilities
• Manual tests on Android Market apps found
12/20 apps had at least one vulnerability
• Easy to use (example)
Some Recommendations
• Use caution with implicit Intents and exporting
Components
• Use explicit Intents to send private data
• Use explicit Intents for internal communication
• Returned results should be checked for authenticity
• Avoid exporting Components
• The same Component should not handle both internal
and external Intents
• Intent filters are not security measures
• See Section 3.3 for all recommendations
References
• Information in these slides taken primarily
from “Analyzing Inter-Application
Communication in Android” by Chin, Felt,
Greenwood, and Wagner (UC Berkeley)
• The article, slides, and ComDroid software
available at http://www.comdroid.org/
• Also, see Android’s documentation at
http://developer.android.com/guide/topics/se
curity/index.html