1. Introduction

Alongside the increase in popularity and number of users of the Android operating system (OS), thousands of applications appear every day in the official Android Market (Google Play Store) and alternative markets [1]. This popularity and expansion can be attributed to the capabilities provided by the development of Android applications [2]. However, sometimes these capabilities are prone to some vulnerabilities leading to their misusage [3]. One of such capabilities is inter-component communication (ICC), specifically PendingIntent (PI) [4]. Though this feature is very useful in Android applications, as in notifications and alerts, its insecure use can pose various risks for the user and it may lead to attacks such as denial of service, privilege escalation, and data leakage [4, 5]. Failure to detect these vulnerabilities in Android applications can lead to a decrease in the use of such applications by the victim of attacks, imposing losses on the industry in general. It is, therefore, necessary to detect these vulnerabilities before publishing Android applications in different markets [3]. However, testing the applications published in different markets poses challenges for provider stores, including the fact that such test and analysis are time-consuming.

PI is a powerful feature for ICC in Android. The PI stores a base Intent that will be executed later by another application or component but with the same identity and permissions as the sender application [5]. In fact, PI is a token that one application, such as Application A, sends to another application, such as Application B, thus allowing Application B to inherit Application A’s permissions to execute a predefined piece of code. Therefore, insecure use of PIs can lead to severe security consequences in the form of denial of service attacks, identity theft, and privilege escalation [6, 7].

Several methods have been proposed to detect PI vulnerabilities that vary in their precision, execution time, and analysis type. XManDroid is a security framework that has limited precision and produces a large number of false positives [7]. In [8] is presented a static-based approach that is capable of detecting only one type of PI vulnerability with low precision and many false positives. IntentDroid [9] is a dynamic analysis approach that has inherited the limitations of dynamic analysis such as runtime overhead. PIAnalyzer [10] is a method based on static analysis that is capable of detecting a higher number of PI-related vulnerabilities with higher precision compared to other methods but has the challenge of execution time. Table 1 showcases examples of tools, with comprehensive details elaborated upon in the “Related Work” section.

In this paper, a new PI-related vulnerability is introduced. The PI can be vulnerable if an explicit base Intent is wrapped in the implicit Intent with nonstandard action. However, as far as we know, other methods have been proposed to detect PI vulnerabilities, if the base Intent is explicit, it is considered as a secure PI. The proposed method is a fast and precise method based on static analysis to detect PI-related vulnerabilities. The proposed method is implemented as a tool called PIVAT¹ (see Nomenclature for a complete list of abbreviations). For evaluation, PIVAT is compared with PIAnalyzer. To this end, both methods are implemented and experimentally evaluated for 51 benchmark applications. PIVAT detects the new PI-related vulnerability that is not detected by PIAnalyzer. In addition, PIVAT takes less time to detect the vulnerabilities than PIAnalyzer.

This paper is organized as follows. In Section 2, the basic concepts related to the components of Android applications, Intent and PI objects used for ICC, and PI-related vulnerabilities are described. Section 3 reviews the related literature. In Section 4, a new PI-related vulnerability is introduced. Section 5 describes in detail the proposed method for analyzing and detecting PI vulnerabilities. In Section 6, the evaluation of the proposed method and comparison with PIAnalyzer is presented, and finally, the paper is ended with a conclusion.

2. Background

This section reviews the basic concepts underlying this study. An Android application contains several files and folders. A key file in the structure of Android applications is AndroidManifest.xml, which contains a list of components hosted by an application. Some information in the file is used for communication among components during runtime, while others are related to the permissions applied and requested by the application [12].

Every Android application is made up of four components: (1) Activity that represents the user interface and forms a significant part of Android applications; (2) Broadcast Receiver that waits to receive messages from the Android system or other Android applications, such as incoming calls or text messages from other components or other systems; (3) Content Provider, which acts as a standard interface for sharing data between applications; and (4) Service that runs applications in the background. Service components are unique because their processing is hidden in the user device and creates various opportunities for malicious actions [13].

An Intent specifies the target component of a message, facilitating communication among Android components. There are two types of Intent: explicit Intent and implicit Intent. An Intent is explicit if it specifies the target component and thus must be passed to the same component. However, if an action instead of a component is specified in an Intent, the Intent is implicit. This Intent can pass the request to any application that can perform the specified action and has declared that action in its Intent filter. To receive an Intent, a service or activity must be declared in the manifest (broadcast receivers can be declared in the manifest or at runtime). If the Exported attribute is true for a component in the manifest, or the component contains at least one Intent filter, then that component is public. This means that it can receive Intents from other applications. Intent filters specify the types of Intent to be delivered to public components [14].

A PI is a special kind of Intent that stores a base Intent to be executed later by another application or component, while having the identity and permissions of the sender application. An application can send a PI to a third-party application or system component to perform predefined tasks at another time on behalf of the sender application. The point is that the main application does not need to be actively running or in memory at that moment, as the receiver will run it just it were being run by the main application. For this purpose, Android transfers the permissions and identity of the sender application to the target application receiving the PI. In fact, PI is an Intent that will perform the action specified by the source application, on its behalf, i.e., with its identity and permissions, irrespective of whether the source application is running or not [5, 15, 16]. PI is most used for notification and alarm services [4].

Whenever the PI receiver calls its Send method, the associated Intent is executed with the identity and permissions of the source application [8]. However, the PI receiver can modify three main parts of the basic Intent data, which may in turn modify the meaning of the basic Intent that runs with the permissions and identity of the main application. If the sender already defines the target component or Intent action, the PI receiver can no longer override it. However, if not already defined by the sender, an unwanted target component or Intent action can be defined after delivering it to the recipient. Finally, the PI receiver can always add extra data after receipt. That is, an implicit Intent (whose target component has not been defined) can be modified by the receiver application to target any component (with the main application’s permission), including system features such as clearing the phone [10]. Such vulnerabilities can result in attacks leading to privilege escalation, denial of service, and data leakage. Therefore, detecting these vulnerabilities is essential.

The PI can be transferred either to a trusted system component (such as an alarm manager) or to another Intent that wraps it. PI-related vulnerabilities depend on the types of their transmission, which are briefly described below.

2.1. Type I: Implicit PI Sent to a System Component

Vulnerability: The application X can create a PI containing an implicit Intent and pass it to a system component such as a notification manager [10].

Exploit: When the user clicks on the notification, the target component of the X is expected to take delivery of the Intent. However, any application that can perform the action specified in the base Intent and has declared this action in its Intent filter may receive the Intent, potentially leading to a denial of service attack. Figure 1 shows an example of such vulnerability.

2.2. Type II: Implicit PI Wrapped in an Implicit Intent

Vulnerability: Application X can create a PI containing an implicit Intent and send it through an implicit Intent. When the PI is processed, the associated base Intent is detected and processed by a component based on the Intent filter. When several components have the same Intent filter, the component with the highest priority is selected for processing the corresponding Intent [17].

Exploit: Each application can receive an implicit PI [17] and use the Send method of that PI to send intents with the desired data on behalf of the original sender. A malware can manipulate Intent data and thus use leakage or modification of sensitive data and distribute PI for Intent spoofing purposes, which can lead to denial of service and data leakage attacks [8]. Figure 2 shows an example of such vulnerability.

2.3. Type III: Empty PI Wrapped in an Implicit Intent

Vulnerability: Application X can create a PI containing an empty Intent and send it through an implicit Intent. When no action is specified in the PI, the PI receiver can configure any action and perform it on behalf of the application that has sent the PI [17].

Exploit: A malware can show interest in PI via Intent filter. As soon as the empty PI is received, the malware sets a malicious action in the PI, so that the malicious action is performed by Application X when the PI is processed [17]. This can result in privilege escalation and denial of service attacks. Figure 3 shows an example of such vulnerability.

2.4. An Example of a Vulnerable PI

An example of a code representing the insecure use of PI is shown in Figure 4 (quoted from [10]). The code provided in Figure 4(a) is an example of a vulnerable program. This program has permission to make phone calls. In line four, an empty base Intent has been created. In line five, the base Intent is wrapped inside a PI and sent through another implicit Intent called implicitWrappingIntent (lines six to eight). As the Intent including PI is sent implicitly in the application, it can be received by any application that has declared a corresponding filter in its manifest. The code provided in Figure 4(b) represents a malicious program that can use its Intent filter to receive the implicit Intent sent by the vulnerable application and receive the PI wrapped therein. The program does not have permission to make phone calls. In line three of the code, PI is extracted and given that the base Intent in the vulnerable code is empty with no defined action, the base Intent has been manipulated in line four and the action has been defined to make a phone call to a specific phone number. Calling the Send method of the PI object in line six, the malicious application has been able to make a phone call using the identity and permission of the vulnerable application. Therefore, the malicious application could execute its malicious request by exploiting a vulnerable application that used PI insecurely.

3. Related Work

There are several methods for analysis and detection of PI vulnerabilities that vary in their type of analysis, accuracy, execution time, and efficiency. Existing security methods are implemented in different manners and architectures and use various techniques and mechanisms that are generally divided into three main groups, i.e., prevention-based, analysis-based (static or dynamic), and runtime monitoring [12].

XManDroid enables runtime monitoring of ICC and develops communication policies based on a combination of specific permissions [7]. Since XManDroid monitors all communications among components, it is capable of preventing vulnerabilities. However, XManDroid has limitations in distinguishing benign flow of ICC communication from colluding cases and generates a large number of false alarms. This method is more suited for monitoring a small number of applications installed on a device.

The method presented in [8] is based on static analysis and is able to identify only one type of PI-related vulnerabilities.

IntentDroid is another approach that can dynamically analyze Android applications and detect PI-related vulnerabilities [9]. IntentDroid is only capable of detecting vulnerabilities arising out of communications among Activity components of the application and does not examine vulnerabilities related to communications among Service, Broadcast Receiver, and Content Provider components.

IccTA is an open-source tool for performing ICC-based taint analysis that can identify privacy data leakages by providing a control flow diagram through the application code instrumentation technique [18]. IccTA is able to detect PI-related vulnerabilities [19].

PITracker is an automated analysis tool based on Intent flow analysis [20]. This means that each PI object will analyze an application to determine how it was created (origin) and where it ultimately goes (target). For this purpose, it decompiles the APK file and converts the DEX file into an intermediate SMALI code. By identifying PI methods in SMALI code and backward slicing of previous statements on method’s control flow graph (CFG), the information of base Intent is obtained. In the next step, the fourth parameter of the creator method of PI is checked. If it is FLAG_IMMUTABLE, it means that the malware cannot change the semantic of PI and this PI is secure. If the fourth parameter is not set, the permissions requested by that application will be extracted. And in the next step, with forward analysis, it finds all statements that are the destination of PI. If the destination of PI is an implicit Intent or a notification, and based on the delegated permissions, the tool gives that application a component hijacking or permission re-delegation label. The authors reported that based on manual inspection of the SMALI code of 50 randomly selected apps, PITracker detects PI vulnerability with a high precision [20].

In [21], a Soot-based tool is developed for detecting the PI vulnerabilities. Like PITracker, they check the fourth parameter of creator of PI to detect potential vulnerabilities. In this paper, the security implications of empty PI and Pending Intents with implicit base Intents are examined. The detection process begins by converting the APK files of the programs into Jimple intermediate code and detecting methods that create PI without the FLAG_IMMUTABLE parameter. These methods are then analyzed to determine if the base Intent is implicit or empty. If either condition is met, it is reported as insecure. However, the analysis does not extend to examining the destination of the Intent, resulting in an incomplete Intent flow analysis.

PIAnalyzer is a static analysis tool designed to detect PI-related vulnerabilities [10]. PIAnalyzer converts the bytecode extracted from the APK file into an intermediate SMALI code using the ApkTool, which is a reverse engineering tool. The developers of PIAnalyzer have designed SMALI Slicer, which performs the main part of PIAnalyzer analysis, in order to analyze the intermediate SMALI code. PIAnalyzer returns a set of influencing statements using SMALI Slicer. After analysis of the statements, if the PI has an implicit base Intent and is sent to a third-party application, a vulnerability is reported, and an alarm is made if it is sent to a system component. PIAnalyzer is able to detect PI-related vulnerabilities with about 90% precision, but it has limitations in terms of application analysis speed.

We introduce a new PI-related vulnerability which is detected by PIVAT in addition to the vulnerabilities pointed out in other methods. Furthermore, PIVAT is capable of detecting PI-related vulnerabilities with greater speed in comparison of PIAnalyzer.

4. Type IV: A New PI-Related Vulnerability

A new vulnerability characterized as explicit PI wrapped in the implicit Intent is introduced in this paper.

Vulnerability: Program X has permission to access the Internet and upload data. It creates a PI containing an explicit Intent to upload data to the Internet and sends it through an implicit Intent. When an implicit Intent containing a PI is processed, it is detected and received by a component based on the Intent filter.

Exploit: Abuse of this vulnerability can occur in two scenarios. The first is similar to the vulnerability described in Section 2.2, where the implicit Intent containing PI has a standard action. In this case, the malicious Application Y, which has permission to access the contact information and has declared in its Intent filter the action used in the implicit Intent of Application X can receive an implicit Intent containing PI and extract the PI therein. Then, it can add the contact information in the extended data of base Intent, call the Send PI method, and upload the data that it has added to the base Intent. As a result, Application Y, which does not originally have permission to access the Internet and upload data, can receive the PI and thus inject the user’s private information into the creator application of PI and send it out of the device. As a result, data injection and data leakage attacks occur. The second scenario is when the implicit Intent containing the PI has a nonstandard action. In this case, Application Y, which does not have permission to access contact information and whose developer is the developer of Application X and which is the only application that recognizes the nonstandard action used in Application X, can declare the same nonstandard action in its Intent filter and receive the PI. Next, it can add the contact information in the extended data of the base Intent and call the Send PI method. In this way, it can upload to the Internet the data that it has added to the base Intent. As a result, Application X, which does not originally have permission to access contact information, can collude with Application Y to access this information and send it out of the device. As a result, a collusion attack occurs. Figure 5 is an example of this vulnerability and shows collusion between applications.

5. The Proposed Method

Figure 6 shows an overview of the proposed method, which is performed in three main analysis stages. In the first stage, the PI in the application is identified. To this end, the application manifest file is extracted using the ApkTool. Component extraction in the method identifies components of the application that need to be analyzed based on the manifest. On the other hand, using the Soot tool, the Dalvik bytecodes are converted into the three-address Jimple code, which is an intermediate code. In the PI extraction step, the PIs called in each component are extracted upon receiving the Jimple code of the components extracted in the previous step.

In the second stage, PI analysis is performed to identify the base Intent and the target component of the PI and to determine its status. To this end, an intra-procedural CFG is constructed to detect the basic blocks containing PI and its previous and next blocks that are in turn used to identify the PI target components and the base Intent related with PI. The base Intent is detected only if the target components are likely to have vulnerabilities.

In the last stage of analyzing and reporting vulnerabilities, if there is a possibility of PI vulnerability, the base Intent is analyzed and the vulnerabilities, if there are any, are reported.

The details of each stage are described below.

5.1. PI Detection

The Android application file, APK, is reverse engineered using the ApkTool so that its manifest file is extracted. The components of the application can be identified and extracted using its manifest file. To identify PI, the components of Activity, Broadcast Receiver, and Service need to be analyzed. Therefore, PIVAT analyzes parts of Jimple code that are related to the intended components. On the Android platform, Java source codes are compiled into .class files and then converted to .dex files using “dx” tool. This .dex file contains the Dalvik bytecode that is run on the Dalvik virtual machine. PIVAT converts the Dalvik bytecodes into intermediate Jimple code using Soot tool. The intermediate Jimple code is a three-address code of bytecode that improves the static analysis capability of Android applications. An example of Java code and its translation into the intermediate Jimple code using Soot is shown in Figure 7. Chain is a collection data structure that provides fixed-time access to its elements. There are three types of chains in the body of Jimple code: Chain of Locals, Chain of Units, and Chain of Traps. In Chain of Locals, there are variables in the application that either accept a value in an instruction (Definition) or their values are used in an instruction (Use). As shown in Figure 7, Chain of Locals is defined at the top of the method along with the types of value they accept. The Chain of Units contains the main instructions of the application and the Chain of Traps includes the exceptions of the program.

To identify the variables of type PI in the Jimple code, the local chain section is examined and the variables of type PI are identified. Then, using the Chain of Units, the instruction where the PI variables specified in the previous step are defined (i.e., assign values) is found. If these instructions call one of the four methods of getActivity (), getActivities (), getBroadcast (), and getService (), these instructions are designated as PI callers and the analysis will continue based on such instructions. Therefore, the output of this stage is a list of instructions that define the variables of type PI and call one of the four methods mentioned above.

5.3. Analysis and Report of Vulnerabilities

According to the classification presented in Figure 8 and PI-related vulnerabilities in Sections 2 and 4 of this paper, when the PI is sent to a system component (target component) and its base intent is implicit, Type I vulnerability discussed in Section 2.1 is reported. On the other hand, when the PI has been placed inside another implicit Intent as extra data and the base Intent is implicit, Type II vulnerability described in Section 2.2 is reported. However, if the base Intent is implicit with no action, Type III vulnerability described in Section 2.3 is reported. When the PI is placed as extra data inside another implicit Intent that has no standard action and the base Intent is explicit, Type IV vulnerability discussed in Section 4 is reported.

6. Evaluation and Results

In this section, PIVAT is compared to PIAnalyzer, an open-source tool for PI-related vulnerability analysis. To better compare and evaluate the results, both methods are first converted to intermediate Jimple code using Soot tool and then the algorithm associated with each approach is implemented [11]². Then, the execution time and efficacy of both tools are evaluated by running them on 51 benchmark applications; 50 benchmark applications are randomly selected from Google Play and one benchmark application containing four types of vulnerabilities is developed by the authors of the paper. All evaluations in this section are performed on a system with an Intel Core i3-3120M processor with 4 GB of RAM and Windows 10 OS.

The authors employed manual inspection to evaluate the precision of PI vulnerability detection tools [10, 20]. This method requires a significant amount of time and effort, as it necessitates the analysis of many source or intermediate code files. In a manual inspection of ten applications, PIAnalyzer accurately identified vulnerabilities in nine instances [10]. To evaluate precision, PIVAT is compared with PIAnalyzer. For the vulnerabilities of Types I, II, and III, PIVAT successfully detected all vulnerabilities identified by PIAnalyzer, indicating that its precision is comparable to that of PIAnalyzer at approximately 90%. But PIAnalyzer cannot detect Type IV vulnerability that is detected by PIVAT. Also, PITracker and others tools and approaches cannot detect Type IV vulnerability.

Table 2 shows the results of comparing the execution time of the above tools in detection of PI-related vulnerability, and Figure 9 shows the graphs related to evaluation results.

In (A), PIVAT detects the absence of PI faster because it only searches for local variables in each method. However, it takes longer for PIAnalyzer to detect the lack of PI in the application because it searches all the instructions in the application code. Therefore, in (1), PIVAT performs a faster analysis.

In (B), PIVAT detects PI-related vulnerabilities faster because it only analyzes basic blocks that may contain the PI target component and its base Intent and does not analyze all instructions of the application.

In (C), the application contains an explicit PI and sends it to a system component. In this case, the PIAnalyzer detects the absence of PI-related vulnerabilities earlier because it first analyzes the base Intent type and does not continue the analysis if it detects that the base Intent is explicit. However, PIVAT first analyzes the PI target component and then analyzes the base Intent type in the next step, and therefore it takes longer for it to realize that the PI is not vulnerable.

The results in Table 2 and Figure 9 show that PIVAT performed better than PIAnalyzer in 95% of cases, and just in 5% of cases, PIAnalyzer performed faster than PIVAT with a time difference which is not significant.

The results of the evaluations show that PIVAT is highly precise and about 27% faster than PIAnalyzer in terms of application analysis speed.

In Figure 10, we present cumulative distribution function (CDF) plot of the execution time for our tool, PIVAT, and PIAnalyzer to analyze each application. We can see that more than 50% applications can be analyzed by PIVAT in less than 4.5 s each, while PIAnalyzer can analyze less than 30% of the applications in this time.

7. Conclusion

Secure use of PIs in Android application development can reduce vulnerabilities in Android applications and prevent various attacks such as denial of service, data leakage, and privilege escalation. In this paper, a new PI-related vulnerability is introduced. The PI can be vulnerable if an explicit base Intent is wrapped in the implicit Intent with nonstandard action. The proposed method is presented for detecting PI-related vulnerabilities in a shorter time. For this purpose, the Android application code is converted to the intermediate Jimple code and PIs are extracted from its components. Then, vulnerabilities are analyzed and reported in the proposed method using the status of the base Intent and the target component. To identify the base Intent and the target component, data flow analysis is performed on an intra-procedural CFG for methods containing PI caller. To evaluate the proposed method, it is implemented besides PIAnalyzer and the analysis is performed on 51 benchmark applications. The results show that the proposed method detects Type IV vulnerability that is not detected by PIAnalyzer. In addition, the proposed method is 27% faster than PIAnalyzer in terms of application analysis speed. Further research can focus on increasing the precision of the proposed method and evaluating the proposed method with more benchmark applications.

Conflicts of Interest

The authors declare no conflicts of interest.

Funding

This research did not receive any specific grant from funding agencies in the public, commercial, or not-for-profit sectors.

Endnotes

¹PIVAT: PendingIntent Vulnerability Analysis Tool.

²https://github.com/msniea/PIVATool.