| Name |
Android Activity Hijack |
|
| Likelyhood of attack |
Typical severity |
| Medium |
Medium |
|
| Summary |
An adversary intercepts an implicit intent sent to launch a Android-based trusted activity and instead launches a counterfeit activity in its place. The malicious activity is then used to mimic the trusted activity's user interface and prompt the target to enter sensitive data as if they were interacting with the trusted activity. |
| Prerequisites |
The adversary must have previously installed the malicious application onto the Android device that will run in place of the trusted activity. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Find an android application that uses implicit intents] Since this attack only works on android applications that use implicit intents, rather than explicit intents, an adversary must first identify an app that uses implicit intents to launch an Android-based trusted activity, and what that activity is. |
|
| 2 |
Experiment |
[Create a malicious app] The adversary must create a malicious android app meant to intercept implicit intents to launch an Adroid-based trusted activity. This malicious app will mimic the trusted activiy's user interface to get the user to enter sensitive data. |
- Specify the type of intent wished to be intercepted in the malicious app's manifest file using an intent filter
|
| 3 |
Experiment |
[Get user to download malicious app] The adversary must get a user using the targeted app to download the malicious app by any means necessary |
|
| 4 |
Exploit |
[Gather sensitive data through malicious app] Once the target application sends an implicit intent to launch a trusted activity, the malicious app will be launched instead that looks identical to the interface of that activity. When the user enters sensitive information it will be captured by the malicious app. |
- Gather login information from a user using a malicious app
|
|
| Solutions | To mitigate this type of an attack, explicit intents should be used whenever sensitive data is being sent. An 'explicit intent' is delivered to a specific application as declared within the intent, whereas an 'implicit intent' is directed to an application as defined by the Android operating system. If an implicit intent must be used, then it should be assumed that the intent will be received by an unknown application and any response should be treated accordingly (i.e., with appropriate security controls). Never use implicit intents for inter-application communication. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-923 |
Improper Restriction of Communication Channel to Intended Endpoints |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-173 |
An adversary is able to disguise one action for another and therefore trick a user into initiating one type of action when they intend to initiate a different action. For example, a user might be led to believe that clicking a button will submit a query, but in fact it downloads software. Adversaries may perform this attack through social means, such as by simply convincing a victim to perform the action or relying on a user's natural inclination to do so, or through technical means, such as a clickjacking attack where a user sees one interface but is actually interacting with a second, invisible, interface. |
| CAPEC-499 |
An adversary, through a previously installed malicious application, intercepts messages from a trusted Android-based application in an attempt to achieve a variety of different objectives including denial of service, information disclosure, and data injection. An implicit intent sent from a trusted application can be received by any application that has declared an appropriate intent filter. If the intent is not protected by a permission that the malicious application lacks, then the attacker can gain access to the data contained within the intent. Further, the intent can be either blocked from reaching the intended destination, or modified and potentially forwarded along. |
|