Preventive Policy Enforcement with Minimum User ...

4 downloads 292567 Views 1MB Size Report
rate numbers. The TOP 10 Android malware families reported in [13] showed that FakeInst family accounted for 45% of threats followed by SmsSend variants for.
Arab J Sci Eng DOI 10.1007/s13369-015-1665-2

RESEARCH ARTICLE - COMPUTER ENGINEERING AND COMPUTER SCIENCE

Preventive Policy Enforcement with Minimum User Intervention Against SMS Malware in Android Devices Abdelouahid Derhab1 · Kashif Saleem1 · Ahmed Youssef2 · Mohamed Guerroumi3

Received: 9 December 2014 / Accepted: 13 April 2015 © King Fahd University of Petroleum & Minerals 2015

Abstract In this paper, we propose MinDroid, a usercentric preventive policy enforcement system against SMS malware in Android devices. The design of MinDroid takes into consideration the user’s little understanding of the Android permission system. This can be done by deriving the policy rules from the behavioral model of the malicious SMS applications rather than adopting user-defined rules. MinDroid requires user intervention only during the first T time units from the application installation time. The user during this time period is notified to accept or reject the SMS-sending operations. MinDroid execution is specified as a finite state machine, and its security properties are formally proven using Metric Temporal Logic. We also show that MinDroid is resilient against threats trying to compromise its correct functionality. In addition, an analytical study demonstrates that MinDroid offers good performance in terms of detection time and execution cost in comparison with intrusion detection systems based on static and dynamic analysis. The detection efficiency of MinDroid is also studied in terms of detection rate, false positive rate, and ROC distance. A pro-

B

Ahmed Youssef [email protected] Abdelouahid Derhab [email protected] Kashif Saleem [email protected] Mohamed Guerroumi [email protected]

1

Center of Excellence in Information Assurance (COEIA), King Saud University, Riyadh, Kingdom of Saudi Arabia

2

College of Computer and Information Sciences (CCIS), King Saud University, Riyadh, Kingdom of Saudi Arabia

3

Faculty of Electronic and Computer Science, USTHB University, Algiers, Algeria

totype implementation of MinDroid is tested under Android emulator. Keywords SMS malware · Policy enforcement · Prevention · Android

1 Introduction The current era comes up with an enormous growth in the field of wireless communication with respect to solutions, devices, and their software [1]. The mobile devices offer many applications that become very essential for people to manage daily life [2]. Almost all the personal and confidential information nowadays is stored and transferred through these mobile devices [3]. Therefore, security becomes essential and is required to be employed at every layer [4–8] to deal with specific attacks. In mobile devices, the operating systems such as Android and iOS play an important role in managing the resources and providing services to applications [9]. The Android operating system is popular among users and dominant in the mobile world. According to a report from Strategy Analytics [10], Android had 85 % of the global mobile market share in the second quarter of 2014. This popularity makes Android attractive for malware developers, which aim at making monetary profit by infecting the maximum number of devices. A report study [11] has shown that 98.05 % of mobile threats targeted the Android operating system in 2013. In the third quarter of 2013, F-secure reported that 81.1 % of the mobile threats were profit-motivated and 97.14 % of the latter targeted Android OS [12]. Most of the profit-motivated malwares perform SMS-sending operations to perform their attacks. A recent report published in 2014 [13] revealed that 83 % of the Android malwares analyzed

123

Arab J Sci Eng

by F-secure were performing SMS-sending activity, making it the most common activity among malware. The attacks performed by the SMS-sending trojans (or SMS malware) are the following: –







SMS spam This is the most basic form of attack where unsolicited messages are sent to subscribers for commercial advertising [14]. Sending spam from a compromised mobile device reduces the risk of exposing the spammer and keeps the spammer’s identity hidden. Users might find out about the existence of malware in their devices sending out SMS spam when their monthly phone bills arrive. The spams might also contain links to malicious applications. SMS premium rate fraud Unsolicited messages that trick subscribers to call premium rate numbers or subscribe for services that are charged to the bill of the victim. These SMSs result in costly sums being transferred from the user’s account to that of the cybercriminals. We have seen a continuous growth of SMS-sending trojan families performing this attack such as FakeInst, OpFake, PremiumSms, and SmsSend. For instance, a malware named Trojan-SMS.AndroidOS.FakeInst.ef, masquerades as an application for watching porn videos. Once it is installed, it starts sending SMS messages to predefined premium rate numbers. The TOP 10 Android malware families reported in [13] showed that FakeInst family accounted for 45 % of threats followed by SmsSend variants for 34 %. SMS privacy attack Some malware such as Android/ SmsHnd.A, AndroidOS.Bankrypt.BH, and Android. Nickispy can read sensitive information stored at the device such as bank account, phone identifiers (IMES, IMSI), and GPS location and send it to the attacker. SMS flooding It takes place when unsolicited SMSs are sent to a user, which can lead to a denial of service (DoS) in both the core network and the radio access networks [15].

In Android, applications can access resources such as telephony, network, and SMS functions using APIs. The latter are protected through a security mechanism called permissions. Each application must define the permissions it requests in its AndroidManifest.xml file. A user needs to grant all the requested permissions to install the application. Otherwise, the application cannot be installed. In Android 4.2 (Jelly Bean), the user is notified when an application attempts to send SMS to a premium rate number. However, a malware can hide this notification from the user. Beginning with Android 4.4 (KitKat), only one default SMS application, selected by the user, is allowed to write to the SMS provider and receives SMSs. The other SMS applications can only read the SMS provider and are notified when an SMS is received. However,

123

this design choice cannot prevent the SMS attacks. According to [13], 0.1 % of the applications received from Google’s Play Store were identified as malicious. Thus, a user might download a compromised SMS application that sends both legitimate and malicious SMSs. Most of the users ignore or have little understanding of the Android permission policy. This was confirmed in a survey [16], which showed that only 17 % of users look at the permissions when installing applications. It has also been noticed that developers request more permissions than they actually need [17]. As legitimate and malicious applications can request the same permissions, it is often difficult for the users to determine during the installation time whether the requested permissions are harmful or not. In order to help the user to accurately distinguish between legitimate and malicious SMS applications, we propose MinDroid, a new user-centric policy enforcement approach for Android devices, which notifies the user of all SMS-sending operations performed by an application within the time interval [a, a + T ], where a is the installation time of the application and T is the duration of the testing phase. Then, the user either accepts or rejects the operation. Knowing that a malicious application starts sending SMS within a short time θ ≤ T after its installation on the device, it is sufficient that the user intervenes only during the first T time units of the application lifespan, in order to prevent all malicious SMS-sending operations. The main contributions of the paper are the following: Firstly, we design MinDroid by considering two types of SMS threats occurring during the testing phase: (a) SMSs are generated by a malicious application without the user’s knowledge and (b) a compromised SMS application that sends both legitimate and malicious SMSs. To the best of our knowledge, this second threat has not been addressed before. Secondly, we extend the attack models to consider attacks performed by a malicious application for the first time after the expiration of the testing phase. Thirdly, we prove using Metric Temporal Logic (MTL) that any malicious SMS application that is installed with or without the user’s knowledge is eventually blocked. Fourthly, we verify the security properties of MinDroid and its resilience against attacks, as well as its performance in terms of detection time, execution cost, and detection efficiency. Fifthly, we provide a proofof-concept implementation of MinDroid under Android Emulator. The rest of the paper is organized as follows. Section 2 provides related work. In Sect. 3, we present system model and basic idea. The description of MinDroid is given in Sect. 4. Security analysis, resilience analysis, complexity analysis, and detection efficiency analysis are provided in Sects. 5, 6, 7, and 8, respectively. In Sect. 9, we present proofof-concept implementation. Finally, Sect. 10 concludes the paper.

Arab J Sci Eng

2 Related Work To detect the installed SMS malware on the Android device, the existing approaches apply static or dynamic analysis to check whether the installed applications are malware. In the static techniques [18–24], code static information is used to check whether there is a malicious code in the program. However, obfuscation techniques can be used to avoid detection. In dynamic techniques [25–33], the program behavior is monitored during its execution to detect whether there are any inconsistencies with the normal behavior. The problem with this approach is its cost and the possibility of detection evasion. In other approaches, called policy enforcement, the behavior of a legitimate application is expected to follow certain rules. If a rule violation occurs, the behavior is considered as malicious. The policy enforcing approaches are divided into mitigating and preventive. The mitigating approach cannot prevent the occurrence of an attack as the rule violation is only triggered after the attack has been carried out. On the other hand, the preventive approach can prevent the occurrence of the attack. 2.1 Mitigating Policy Enforcement Approach In [34], DroidForce enforces policies on Android applications to combat SMS premium rate fraud and data leakage. However, some polices cannot prevent the attacks. For example, one policy states that “no more than two premium rate message per day might be sent to each telephone number.” As each message costs money, this policy tries only to mitigate the losses and do not prevent the attack. Nauman et al. [35] proposed Apex, a policy enforcement framework, which allows users to impose runtime constraints on the usage of resources by applications. However, there is no guarantee that the constraints can prevent the attacks. 2.2 Preventive Policy Enforcing Approach Almohri et al. [36] proposed DroidBarrier, which is a runtime process authentication model for Android. DroidBarrier provides legitimate applications with security credentials, which are used for authentication when the processes associated with the application are created. Processes that do not have credentials fail to authenticate, and their corresponding applications are considered as malicious. The problem in this model is the need to initially determine which applications are legitimate. Derhab et al. [37] provided a cryptographic key to each SMS application known by the user. The application is enforced to encrypt their SMSs using the provided key. All the SMSs have to pass through a filter at the kernel level before going out of the device. If the filter can correctly

decrypt the SMS, it sends the decrypted message to the wireless communication medium. Otherwise, it prevents the SMS from going out of the device and tracks the application, which sent the malicious SMS. However, each SMS application in this solution has to encrypt the outgoing SMSs, which requires application modification. Also, it incurs additional cost in terms of processing time due to the encryption and decryption operations. In additions, it increases the SMSsending time. Xu et al. [38] proposed Aurasium, which automatically repackages an application to attach a user-level policy enforcement code. The role of this code is to monitor any security violations such as sending SMS to premium numbers. If such a case occurs, Aurasium displays the destination number and the SMS content, so the user confirms or denies the operation. The major drawback of Aurasium is the need to install permissions for each application. Also, the user needs to intervene each time there is an attempt to send SMS. Sun et al. [39] proposed Patronus, an intrusion prevention system for Android. Patronus defines a list of intrusive transactions that might violate Android security. Whenever there is an attempt to execute a transaction, e.g., sendText, Patronus, using API hooking, suspends the execution and checks whether there is any permission associated with this transaction. If there is no rule in the policy database, Patronus will notify the user and display the transaction content (e.g., destination number and SMS content). The transaction will resume execution when it is allowed by the user. Otherwise, it will be blocked. Although Patronus employs a preventive mechanism (i.e., API hooking), there is no discussion whether the policy is preventive or not. Sakamoto et al. [40] proposed DroidTrack, which alerts a user in case there is a possibility of information leakage, i.e., when the application invokes an API to collect sensitive information, it invokes another API to communicate externally. The user can either confirm or reject the execution of the API. However, this solution requires user intervention each time the two types of APIs are invoked. 2.3 Comparison with Related Work Our work is different from the other preventive policy enforcement solutions in that it requires user intervention only during the first T time units from the application installation time, called the testing time. This choice is based on the behavioral model adopted by most of the malicious SMS applications, i.e., they send the first malicious SMS within a short time θ ≤ T . The user-centric policy proposed in this work focuses on the actions performed by the application during the testing phase. After the expiration of T, it is possible to tell whether the application is legitimate or not. The other difference is that some solutions suggest giving users more

123

Arab J Sci Eng

control to manage and revoke the permissions if necessary, which implies that users should have good understanding of the Android permission policy. Our work removes this management burden from the user and focuses more on deriving rules from the malicious behaviors rather than adopting userdefined rules.

3 System Model and Basic Idea

bypass the sandbox protection mechanism and have control over the operating system and data. MinDroid addresses this attack by using some solutions against the privilege escalation attack [41] or using SELinux-enabled kernel, which is available staring from Android 4.3. In SELinux, data are protected from applications that can access to the root user by applying a custom security policy that specifies the applications that have access to the data [42].

3.1 Basic Idea: Motivating Examples

3.3 Attack Model

In this section, we describe the functionality of some SMS malware to justify the choices we are going to adopt in our attack model. One example of SMS spam botnet, which masquerades an Android game, initiates a connection with a Command and Control (C&C) server once it is installed. The C&C server replies with a list of phone numbers and the message payload to deliver. The malware waits 1.3 seconds after sending each spam and checks with the C&C server every 65 seconds for more numbers. Another example of SMS malware is developed to automatically send costly SMS messages to premium numbers. After 10 seconds from its installation, the malware establishes a connection with the C&C server. After that, an SMS with a unique identifier is sent to the premium number. The malware keeps continuous connection with the C&C server by exchanging information and commands every 10 min. The above examples show that the malware does not waste time after installation and tries to quickly perform the attack in order to gain the maximum profit from the infected device before being detected. Based on this observation, the basic idea behind MinDroid is to monitor the behavior of the installed applications for a short time period only to decide whether they are malicious or not.

An SMS attack is said to be successful if the malicious SMS can go out of the device. We consider two types of SMS threats: –



Threat 1 The malicious application is hiding its SMSsending activity from the user and only sends malicious SMSs. Threat 2 The user installs a compromised SMS application, i.e., SMS-sending activity is not hidden from the user, but the application is secretly sending malicious SMSs as well. This kind of threat happens when an attacker repackages a legitimate application and inserts a malicious code.

We assume that each SMS malware starts its malicious activity within a time period of (T) time units after its installation on the device. This assumption is realistic as the SMS malware either starts sending SMS immediately after installation such as FakeInst [13] or after getting instructions from a Command and Control (C&C) server such as RootSmart [43]. 3.4 Legitimate Application Model We consider two types of legitimate application models:

3.2 Security Model – We assume that the Android kernel is initially not compromised (i.e., free from malicious code), and MinDroid is installed before the installation of any SMS application. MinDroid utilizes the Sandboxing feature provided by Android kernel. This feature enables isolating applications from one another. In Android, each application is assigned a unique user ID (UID) and is run as a separate process. The filesystem access policy does not allow one user (resp., application) to access or modify another user’s (application’s) files. We assume that an attacker cannot get root privileges of the target device using the privilege escalation attack. Once a malware gains access to the root account, it can

123



Model 1 The legitimate SMS application does not send any SMS within (T) time units after its installation. Model 2 The legitimate SMS application can send an SMS within (T) time units after its installation.

4 MinDroid Description An Android application can send SMSs by invoking one of the there SMS-sending methods of the SmsManager class, which are sendTextMessage, sendMultipartTextMessage, and sendDataMessage. MinDroid intercepts in real time the calls to SMS-sending APIs. These calls are invoked by applications with SMS_SEND permission, i.e., Android-

Arab J Sci Eng

Legitimate App

sendTextMessage

MinDroid

(1) Suspend

Malicious App

API call interception

(2) Resume

sendTextMessage

(1)

User Known SMS Applications

Application status Policy database

Confirmation pop-up window

Suspend

(3) Block

Malicious Legitimate code code

Compromised App (1) Suspend sendTextMessage

(2) Resume (1) Suspend sendTextMessage

(3) Block

Fig. 1 Architecture of MinDroid

Manifest.xml file of the application contains the following line:

MinDroid performs the following steps each time the SMS application calls one of the three methods mentioned above:



The architectural design of MinDroid is shown in Fig. 1, and it is composed of the following components: 1. Known SMS applications It contains the list of applications, which are known for their SMS-sending activity, and registered by the user. 2. API call interception It intercepts the calls to SMSsending and suspends executing the invoking application. 3. Application status For each application with SMS_SEND permission, MinDroid stores the following variables: (a) Known, a boolean variable which holds true if the application is known and registered by the user, (b) InsTime, which denotes the installation time of the application, and (c) state, which denotes the current state of the application as follows: Unauthorized, Pre-authorized, Authorized, User decision, and Blocked. 4. Policy database It contains the rules the application must satisfy when an SMS-sending method is invoked.

1. Suspend executing the application (arrow (1) in Fig. 1). 2. Check if the rule is satisfied. 3. Block running the application if the rule is violated (arrow (3) in Fig. 1). Otherwise, the application resumes execution (arrow (2) in Fig. 1).

We define the rule as follows: “The application is not hiding its SMS-sending activity from the user and has not sent any malicious SMS for a duration of T time units (i.e., testing period) after the installation.” We can notice that this rule is composed of two parts: the first one (i.e., “must be known by the user”) checks whether the rule is violated by Threat 1 and the second one checks whether the rule is violated by Threat 2. The issue that might arise is how can we distinguish between legitimate SMS and malicious SMS during the testing period? To resolve this issue, we propose that the user be responsible for making this distinction for each SMS sent during this testing period.

123

Arab J Sci Eng Fig. 2 Finite State Machine of MinDroid

Unauthorized State

Call_ SMS Known = True

Pre-authorized State

user_response=YES

Call_ SMS and CurrentTime -InstTime T

Call_ SMS User decision State

Blocked State

user_response=NO or To

The various states assigned to an SMS application and the actions taken by MinDroid are illustrated by a finite state machine (FSM) in Fig. 2. Transitions are labeled with conditions that need to be met, and the states are described as follows: –



Unauthorized State Initially, the status of the application is set to unauthorized. If an SMS-sending method is invoked in this state, a rule violation is triggered, and the application enters the Blocked State. It enters the Preauthorized State when it is registered by the user and added to the Known SMS applications list. Pre-authorized State In this sate, we distinguish two cases: (a) The testing period is expired, and then, the application enters the Authorized State. (b) The SMS-sending method is invoked before the expiration of the testing period, and then, the application enters the User decision State.



User decision State In this sate, MinDroid starts a timer T_Response of duration TR time units and asks the user through a confirmation pop-up window, which contains the content of the SMS required to be sent, to confirm whether the SMS is originated by him/her or not. If the user’s response is positive, the SMS is sent and the application transits back to the Pre-authorized State. If the user’s response is negative, a rule violation is triggered, and the application enters the Blocked State. If T_Response expires and no response is received from the user (i.e., timeout is triggered), it means that the user was not holding the device when the SMS-sending method was invoked (i.e., SMS is not originated from the user).

123

– –

Authorized State

In this case, a rule violation is also triggered, and the application enters the Blocked State. Blocked State In this state, the application is considered as malicious and it is blocked. Authorized State In this state, the application is authorized to send SMSs.

5 Security Analysis 5.1 Introduction to Metric Temporal Logic In this section, we formally prove the security properties of MinDroid using Linear Temporal Logic (LTL) and Metric Temporal Logic (MTL). In LTL, a temporal formula is composed of predicates and temporal operators such as  (‘at every moment in the future’), ♦ (‘eventually’),  (‘at every moment in the past’),  (‘at some moment in the past’). MTL extends LTL with timing constraints. In this paper, we only use tow basic constraints, as defined in [44]: – –

 I ϕ means that ϕ is true in all time instants of interval I. ♦ I ϕ means that ϕ is true in at least one time instant in interval I.

In our proofs, we are going to use propositions like the ones defined in [44]: –

X ⇒ ♦[0,t) Y , means that when X happens, Y must happen within t time units

Arab J Sci Eng

X ⇒ ♦[t,t] Y , means that when X happens, Y must happen after exactly t time units. X ⇒ [0,t] Y , means that when X happens, Y must have happened t time units before.

method within T time units after the installation. Formally:

Some temporal formulas in LTL can be re-expressed in MTL as follows:

From the FSM in Fig. 2, it infers that Call_SMS holds true when the state of the application is Unauthorized, Preauthorized, or Authorized. Let t ∈ [0, T ) be the time instant at which Call_SMS holds true, and then, there are only two cases:

– –

– – – –

ϕ ≡ [0,+∞) ϕ ♦ϕ ≡ ♦[0,+∞) ϕ ϕ ≡ (−∞,0] ϕ ϕ ≡ (−∞,0] ϕ

(Malicious ⇒ ♦[0,T ) Call_SMS)

– 5.2 Verification of MinDroid Before verifying the security properties, we formally define some predicates and variables employed by our proof. –

– – –

– – –

Predicates UN, PR, AU, UD, and BL holds true if the application is in the Unauthorized, Pre-authorized, Authorized, User decision, and Blocked State, respectively. Malicious a predicate that holds true if the application is malicious. Benign a predicate that holds true if the SMS application is legitimate. Known a predicate that holds true if the application is registered by the user and added to the Known SMS applications list Call_SMS a predicate that holds true if the application invokes an SMS-sending method. TO a predicate that holds true if a timeout is triggered. response_user the response provided by the user following appearance of the confirmation pop-up window. It takes two values: YES and NO. MinDroid has to ensure two security properties.

Property 1 Whenever a malicious SMS application is installed on the device, it will be blocked within (T + TR) time units. Formally, this property is written as follows: P1 ≡ (Malicious ⇒ ♦[0,T +TR) BL)

Case 1 UN = TRUE, this means that at time t Call_SMS held true while the application was in the Unauthorized state. Formally: Malicious ⇒ (♦[t,t] Call_SMS ∧ [0,t] UN)

(4)

According to the FSM, we have: (♦[t,t] Call_SMS ∧ [0,t] UN) ⇒ ♦[0,0] BL

(5)

From (4) and (5), it follows that: (Malicious ⇒ ♦[t,t] BL)

(6)

Since t ∈ [0, T ) ⊂ [0, T + TR), we have (Malicious ⇒ ♦[t,t] BL) ⇒ (Malicious ⇒ ♦[0,T ) BL) ⇒ (Malicious ⇒ ♦[0,T +TR) BL) –

(7)

Case 2 PR = TRUE, this means that at time t Call_SMS held true while the application was in the Pre-authorized state since 0 < t < t, and t ∈ [0, T ). Formally: Malicious ⇒ (♦[t,t] Call_SMS ∧ [t ,t] PR)

(8)

From the FSM, we infer that: (1)

Property 2 Under the first legitimate application model, whenever an SMS application is blocked, then it has not been benign at any moment since its installation. Let TI be the duration between the installation and the blockage events. Formally, this property is written as follows: P2 ≡ (BL ⇒ ¬([−TI,0] ¬Benign))

(3)

(♦[t,t] Call_SMS ∧ [t ,t] PR) ⇒ ♦[0,0] UD

(9)

As t, t ∈ [0, T ), we get from (8) and (9): Malicious ⇒ (♦[0,T ) Call_SMS ∧ [0,T ) P R)

(10)

(♦[0,T ) Call_SMS ∧ [0,T ) PR) ⇒ ♦[0,0] UD

(11)

(2)

Proof (Proof of Property 1) In accordance with the assumption made in the attack model, a malicious application invokes an SMS-sending

At User decision State, a timeout is triggered after exactly TR time units unless the user confirms whether the SMS is originated by him/her or not within TR time units. In case of malicious SMS, we know that the user is

123

Arab J Sci Eng

not aware of it. So, the user either denies that he/she sent the SMS or does not provide any response. Formally: UD ⇒ (♦[0,TR)r esponse_user = NO) ∨ (♦[TR,TR] TO) ⇒ ♦[0,0] BL

(12)

From (10), (11), and (12), it follows that: Malicious ⇒ ♦[0,T +TR) BL

(13)

From (7) and (13), it follows that: (Malicious ⇒ ♦[0,T +TR) BL). Thus, Property 1 is verified. Proof (Proof of Property 2) As ¬([−TI,0] ¬Benign) ≡ [−TI,0] Malicious, P2 can be written as follows: P2 ≡ (BL ⇒ ([−TI,0] Malicious)

6 Analysis of MinDroid Resilience In this section, we analyze the security of MinDroid and discuss its resilience against the following potential attacks: –

Case 1 The Blocked state is reached from the Unauthorized state. BL ⇒ ([−TI,0] UN ∧ [0,0] Call_SMS)



The verification of property (P1) means that all the SMS attacks are blocked by MinDroid. Property (P2), on the other hand, ensures that MinDroid does not block SMSs originated from legitimate applications. Therefore, under the first legitimate application model, null false positive is achieved. However, property (P2) cannot be verified under the second legitimate application model. Under this model, both malicious and legitimate applications can send SMSs within T time units. Therefore, MinDroid might block legitimate SMS applications. To deal with this issue, we study the detection efficiency of MinDroid under the second legitimate application model in Sect. 8.

(14)

From the FSM in Fig. 2, the Blocked state can be reached from the two states: Unauthorized and Pre-authorized. Thus, there are only two cases: –

Thus, Property 2 is verified.

(15)



Case 2 The Blocked state is reached from the Preauthorized state. BL ⇒ ([0,0]r esponse_user = NO) ∨ ([0,0] TO) (16)

In both cases, a rule violation occurred, and the application was considered as malicious. Formally: (BL ⇒ ([0,0] Malicious))



(17)

We know that once an application is malicious, it cannot become legitimate. Formally, Malicious ⇒ Malicious ≡ Malicious ⇒ Malicious

(18)

As the lifetime of the application is bounded between the installation time and the blockage time, we have: Malicious ⇒ [−TI,0] Malicious

(19)

From (17) and (19), it follows that: (BL ⇒ ([−TI,0] Malicious)

123

(20)



SMS Malware installation A user might download a malicious application and install it. The installed malware starts sending malicious SMS. The latter will be prevented from going out of the phone as shown in Sect. 5. As MinDroid is installed before any SMS application, no malicious SMS is generated from the device. Compromising MinDroid code An attacker might try corrupt the MinDroid code in order to disable the prevention mechanism offered by MinDroid. The code integrity is ensured in this case by setting the system partition as read-only. Also, the sandboxing principle ensures no application can modify the code of MinDroid. The protection of the kernel against the privilege escalation attack ensure that there is no way to compromise MinDroid code. Compromising the policy database and the application status An attacker might try to corrupt the policy database or the application status so it can generate malicious SMSs. As the policy database belongs only to MinDroid and can only be modified by the trusted MinDroid system. Because of the Sandboxing principle, other applications cannot access the policy database and the application status. In addition, as the kernel is secured against privilege escalation attack, a malicious application cannot change the access permissions and corrupt the policy database and the application status. Threat 1 is triggered after the expiration of T By knowing the value of T, threat 1 as defined in Sect. 3 can be adapted to evade MinDroid detection. A malicious application might keep itself silent during the testing period and do nothing. After the expiration of T, the application is considered legitimate and can freely send malicious SMSs. To deal with this issue, we propose to add another

Arab J Sci Eng Table 1 Comparison of mobile anti-malware

Intrusion detection system

Static analysis



Dynamic analysis

Detection time

O()

O(S)

IC

I

O(B) per analysis

O(L)

1 encryption and 1 decryption/SMS

I

rule to the policy database, which states “when an application sends SMS for the first time, notify the user.” As the application only sends malicious SMSs, the first attempt of performing SMS-sending operation will be blocked by MinDroid. Threat 2 is triggered after the expiration of T By knowing the value of T, threat 2 as defined in Sect. 3 can be adapted to evade MinDroid detection. A malicious application might keep itself silent during the testing period and send only the SMSs generated by the user. After the expiration of T , the application is considered legitimate and can freely send malicious SMSs. To deal with this issue, we propose to extend the policy database to check the system states as proposed in [45]. We have the following states: (1) screen state (i.e., off or on), (2) lock state (i.e., locked or unlocked), and (3) application visibility (i.e., foreground or background). Before sending any SMS, MinDroid has to check whether the screen is off, or locked, or the application is executed in the background. If one of the constraints holds true, it means that the SMS is not originated by the user.

In this section, we analyze the complexity of MinDroid and compare it with the static analysis-based IDS, the dynamic analysis-based IDS, IAS [37], and other policy enforcement solutions. The complexity is studied under the following two metrics:



MinDroid and other policy enforcement solutions

Execution cost

7 Complexity Analysis



IAS [37]

Detection time The required time for successful malware detection after the malware started sending malicious SMSs. Execution cost The number of sequential operations required to execute the mobile anti-malware solution.

The results of comparison are given in Table 1. In the table, S denotes the required time to make an observation in the dynamic analysis IDS, B denotes the total size of applications (in bytes) that are analyzed, and L denotes the running time of the SMS application. IC is the inter-process communication

time.  is the time period between the occurrence of two static analysis processes, and I is the time required to execute an instruction. 7.1 Detection Time The static analysis can ensure early detection. However, if obfuscation techniques are employed, there is a need to periodically verify whether the program has been modified or not. In the worst case, a program obfuscation and a malware execution can occur just after the static analysis process. The attacks then are launched for a time S before its detection by the next analysis process. The detection time of the dynamic analysis depends on the time required to make an observation about the malware execution and to build its profile, which is proportional to S. As for IAS, the detection time is the time required to send the malicious SMS from the malware to the outgoing SMS filter, and it equals the inter-process communication time I C. The latter takes values in the order of microseconds [46]. The detection time of MinDroid and the other policy enforcement solutions is I as they prevent the occurrence of the attack at the application layer by executing one instruction, which is checking whether the policy rule of SMS-sending is violated or not. The duration of this checking operation depends on the CPU speed, and it takes values in the order of nanoseconds. On the other hand, the detection time incurred by the IDS is in the order of seconds [47]. 7.2 Execution Cost In the static analysis-based IDS, the application codes are passed as an input to the analysis process. The latter disassembles the binary code of the applications and extracts their system calls and library functions. Thus, the execution cost of the analysis process is proportional to the size of the analyzed applications B. The dynamic analysis-based IDS needs to continuously monitor the application behavior, which leads to an execution cost complexity of O(L). As for IAS, one encryption operation is executed by the SMS application and one decryption operation is executed by the outgoing SMS filter system for each SMS. On the other hand, MinDroid and other policy enforcement solutions need only

123

Arab J Sci Eng

λ

Fig. 3 User availability model

A

N

μ

to check the rule violation, which is equivalent of executing one instruction whose duration is I .

8 Detection Efficiency Analysis In this section, we study the efficiency of MinDroid at detecting SMS malware. This efficiency mainly depends on the user availability at the time of launching the SMS attack for the first time. If the user does not respond to the confirmation pop-up window, a malicious application is not detected but blocked, and a legitimate application is also falsely blocked. We model the user availability as a continuous-time birthdeath Markov chain, as shown in Fig. 3. The chain consists of two states: Available, denoted by A, and Not available, denoted by N . Initially, the user is in state A. Then, it transits to state N at rate λ and transits back to state A at rate μ. The user availability model is implemented and simulated using C language. We evaluate the detection efficiency of MinDroid using the following three metrics: –





True positive rate (TPR) defined as the number of SMS attacks detected by the user to the total number of SMS attacks that are generated randomly within T time units. False positive rate (FPR) defined as the number of legitimate SMSs blocked by MinDroid to the total number of legitimate SMS that are generated randomly within T time units. ROC distance ROC (receiver operating characteristic) curve is a plot of the true positive rate against the false positive rate. A better ROC curve has y-values which grow at a faster rate than its x-values. ROC curve is better to be near the upper left-hand corner (or the point of perfection at (0,100)), at the very best, i.e., the further to the  top left the better. We define the ROC distance as: ( F P R 2 + (1 − T P R)2 ) × 100, where T P R and F P R denote the true positive rate and the false positive rate, respectively. We can note here that the lower ROC distance is, the more efficient MinDroid is.

We simulate two types of applications: legitimate and malicious. From each type of application, we generate 100 SMSs that are uniformly distributed over the time interval [0, T ]. The number of true positives is incremented each time the user checks a malicious SMS. On the other hand, the

123

number of false positives is incremented each time the user does not check a legitimate SMS. In the simulation results, each plotted point represents the average of 30 executions. The theoretical and simulation results are both plotted in the Figs. 4, 5 and 6. The theoretical results are obtained by computing the stationary distribution of the Markov chain, which is defined as follows: μ λ+μ λ πN = λ+μ πA =

Under stationary conditions and assuming uniformly distributed SMS activities over [0, T ], the true positive rate (respectively, false positive rate) becomes the probability that the user is available (respectively, not available), which equals π A (respectively, π N ). We evaluate the detection efficiency of MinDroid under the following three types of user availability scenarios: – – –

The expected sojourn times in states A and N are equal (Formally, λ = μ). The expected sojourn time in state A is higher than that in state N (Formally, λ < μ). The expected sojourn time in state A is lower than that in state N (Formally, λ > μ).

Figures 4, 5, and 6 show the true positive rates and false positive rates of MinDroid as a function of the testing time period T . The latter is bounded between 1 and 10,000 for Fig. 4 and between 1 and 100 for Figs. 5 and 6. This difference is due to the fact that simulation results in Fig. 4 require 10,000 time units to converge to the theoretical ones. As for Figs. 5 and 6, 100 time units are sufficient to achieve this convergence. In Fig. 4, the results are presented under different settings. In each setting, λ is chosen to be equal to μ. The first observation we can draw from the figure is that the true positive rate is high when the testing time T is low. MinDroid achieves full detection of SMS malware when T ≤ 2 and λ = 0.01 (resp., T ≤ 30 and λ = 0.001). The reason for this is that the user is available during the whole testing period and does not leave the mobile device. As T increases, TPR (resp., FPR) decreases (resp., increases) for all the levels of λ as the user is more likely to leave the mobile device. MinDroid converges faster to the steady state when the user is more available (i.e., λ is lower). The theoretical value of TPR and FPR under steady state is 0.5. TPR and FPR achieved by MinDroid become close to the theoretical value as the T is increased. When λ = 1, 0.1, 0.01, and 0.001, TPR and FPR values become very close and can be approximated to the theoretical ones when T = 30, 1000, 10,000, and 10,000, respectively.

Arab J Sci Eng 1

lambda=1, mu=1 (simulation) lambda=0.1, mu=0.1 (simulation) lambda=0.01, mu=0.01 (simulation) lambda=0.001, mu=0.001 (simulation) lambda=1, mu=1 (theoretic) lambda=0.1, mu=0.1 (theoretic) lambda=0.01, mu=0.01 (theoretic) lambda=0.001, mu=0.001 (theoretic)

0.6

False positive rate

0.9

True positive rate

0.7

lambda=1, mu=1 (simulation) lambda=0.1, mu=0.1 (simulation) lambda=0.01, mu=0.01 (simulation) lambda=0.001, mu=0.001 (simulation) lambda=1, mu=1 (theoretic) lambda=0.1, mu=0.1 (theoretic) lambda=0.01, mu=0.01 (theoretic) lambda=0.001, mu=0.001 (theoretic)

0.8

0.7

0.5

0.4

0.3

0.6 0.2 0.5

0.1

0.4 1

10

100

1000

0

10000

1

10

100

T (time units)

1000

10000

T (time units)

(a)

(b)

Fig. 4 Detection efficiency (λ = μ) 1

0.1

0.99

0.09

0.98

0.96

0.07

False positive rate

0.97

True positive rate

0.08

lambda=0.1, mu=1 (simulation) lambda=0.01, mu=1 (simulation) lambda=0.001, mu=1 (simulation) lambda=0.1, mu=1 (theoretic) lambda=0.01, mu=1 (theoretic) lambda=0.001, mu=1 (theoretic)

0.95 0.94 0.93

0.06 0.05 0.04 0.03

0.92

0.02

0.91

0.01

0.9

0

10

20

30

40

50

60

70

80

90

lambda=0.1, mu=1 (simulation) lambda=0.01, mu=1 (simulation) lambda=0.001, mu=1 (simulation) lambda=0.1, mu=1 (theoretic) lambda=0.01, mu=1 (theoretic) lambda=0.001, mu=1 (theoretic)

0

100

0

10

20

30

40

50

60

T (time units)

T (time units)

(a)

(b)

70

80

90

100

Fig. 5 Detection efficiency (λ < μ) 0.7

1

lambda=1, mu=0.1 (simulation) lambda=1, mu=0.01 (simulation) lambda=1, mu=0.001 (simulation) lambda=1, mu=0.1 (theoretic) lambda=1, mu=0.01 (theoretic) lambda=1, mu=0.001 (theoretic)

0.6

0.9

False positive rate

True positive rate

0.5

0.4

0.3

0.8

0.7

0.6

0.2

0.5

0.1

0.4

0 0

0.3 10

20

30

40

50

60

T (time units)

(a)

70

80

90

100

lambda=1, mu=0.1 (simulation) lambda=1, mu=0.01 (simulation) lambda=1, mu=0.001 (simulation) lambda=1, mu=0.1 (theoretic) lambda=1, mu=0.01 (theoretic) lambda=1, mu=0.001 (theoretic)

0

10

20

30

40

50

60

70

80

90

100

T (time units)

(b)

Fig. 6 Detection efficiency (λ > μ)

123

Arab J Sci Eng Table 2 ROC distance Testing time

λ=μ 1

μ=1 0.1

0.01

0.001

λ = 0.1

λ=1 λ = 0.01

λ = 0.001

μ = 0.1

μ = 0.01

μ = 0.001

T =1

37.00

4.57

0

0

4.57

0

0

50.11

51.99

51.99

T =2

50.77

10.93

0

0

6.411

0

0

73.49

80.75

80.75

T =5

63.59

25.40

1.55

0

8.57

0.80

0

104.51

110.40

112.52

T = 10

66.51

37.00

4.57

0

9.99

1.27

0

110.59

123.41

125.15

T = 20

64.29

50.77

10.93

0

13.05

1.08

0

119.35

131.23

132.70

T = 30

70.47

53.50

15.41

0

11.40

1.22

0

121.48

133.03

134.82

T = 40

69.72

60.85

20.83

0.61

11.12

0.94

0.14

124.40

135.01

136.61

T = 50

66.18

63.59

25.40

1.55

11.54

0.66

0.14

127.37

136.14

138.16

T = 60

70.00

61.18

28.04

2.35

11.07

0.94

0.14

128.03

136.75

138.49

T = 70

68.91

60.38

31.01

2.82

11.45

1.50

0

127.23

136.51

138.92

T = 80

72.69

58.83

32.85

3.48

10.98

1.03

0.28

126.94

136.84

138.87

T = 90

70.28

62.22

35.072

4.10

11.92

1.74

0.18

126.66

137.55

139.34

T = 100

70.42

66.51

37.00

4.57

12.06

1.79

0.14

126.47

138.16

139.48

In Fig. 5, we study the detection efficiency of MinDroid under higher values of user availability compared to the user unavailability. To do so, we fix μ to 1 and vary λ. In the figures, the results are presented under three values of λ: 0.1, 0.01, and 0.001. We can observe that better detection efficiency is achieved when λ is decreased, which is due to increasing user availability. For example, MinDroid ensures full detection when T ≤ 2 and λ = 0.01 (resp., T ≤ 30 and λ = 0.001). The theoretical values of TPR under steady state are: 0.909, 0.99, and 0.999 when λ = 0.1, 0.01, and 0.001, respectively. As for FPR, the values are 0.091, 0.01, and 0.001 when λ = 0.1, 0.01, and 0.001, respectively. Under λ = 0.01, and 0.001, the simulation results are very close to the theoretical ones. As for λ = 0.1, this approximation starts when T = 20. In Fig. 6, we study the detection efficiency of MinDroid under higher values of user unavailability compared to the user availability. To do so, we fix λ to 1 and vary μ. In the figures, the results are presented under three values of μ: 0.1, 0.01, and 0.001. We can notice that the detection efficiency decreases as μ decreases. This is because the user is likely to leave the mobile device for longer durations, which negatively affects TPR and FPR. The theoretical values of TPR under steady state are 0.091, 0.01, and 0.001 when μ = 0.1, 0.01, and 0.001, respectively. As for FPR, the values are: 0.909, 0.99, and 0.999 when μ = 0.1, 0.01, and 0.001, respectively. TPR and FPR values become very close to the theoretical ones starting from T = 50 for all the values of μ. Table 2 shows the ROC distances of MinDroid based on the true positive and the false rates obtained in Figs. 4, 5, and 6. We can observe that very high ROC distances are obtained

123

Fig. 7 Hooking of sendTextMessage API function

under high user unavailability and high testing time periods. The ROC distances decrease when the user availability and/or the testing time period increases. The detection efficiency of MinDroid is optimal when the ROC distance is 0. This value is observed under some values of λ, μ, and T.

Arab J Sci Eng Fig. 8 MinDroid implementation in Android architecture

User Return result (YES, NO)

Application API call

Confirmation Pop-up window

Android Application

Return result (Yes, No, Timeout )

SMS-sending API Hook RuleViolationChecking

Application Framework

Return result (true, false) Call Library

Libraries

Android Runtime

Library

Linux Kernel

9 Prototype Implementation In this section, we describe the prototype implementation of MinDroid under Android mobile Emulator [48]. To intercept API calls in real time, we use the same approach described in [40], which hooks the API functions at their entry points before running the original API. To perform the hooking, only modifications to the Android framework are required, which makes the implementation easier. Figure 7 shows how sendTextMessage API function is overwritten through hooking. The added code is shown in italic red font. The rest of code, which shown in black font, is the original API [49]. The RuleViolationChecking function checks whether sending SMS will trigger any rule violation. If so, an error is invoked and the API function is not executed. Otherwise, API execution is resumed. This function can also be added to the other SMS-sending APIs of the SmsManager class, which are sendMultipartTextMessage and sendDataMessage. Figure 8 shows how MinDroid is implemented in the Android architecture. When an application invokes an SMS-sending API, the first function called in this API is RuleViolationChecking function. This function checks the occurrence of any rule violation. According to MinDroid description in Sect. 4, it can be done with/without the user involvement. If the user confirmation is required, a pop-up window is appeared to wait for the user’s response. The values returned by the user are Y E S or N O according to whether it confirms or denies the SMS-sending operation. The confirmation pop-up window, on its turn, returns YES, NO, or Timeout, and the RuleViolationChecking function returns true or false. If True is returned, an error is invoked. Otherwise, the SMS-sending

API resumes execution and calls the corresponding library to carry out the operation. Figure 9 shows screenshots of prototype implementation. In Fig. 9a, the user pre-authorizes the known SMS applications. Figure 9b, c shows the execution of MinDroid when malicious and normal SMSs are sent, respectively.

10 Conclusion The Android-based mobile devices are facing a serious risk of being compromised by mobile malware, and being exploited as a platform to launch SMS-based attacks. The solutions based on static and dynamic analysis are showing their limits as it is always easy to evade detection. To deal with this issue, we have proposed MinDroid, a user-centric preventive policy enforcement system against SMS that takes into consideration the user’s little understanding of the Android permission system and reduction in his/her intervention time. In the system, the user just needs to intervene during the first T time units from the application installation time. MinDroid only intercepts calls to SMS-sending APIs and does not need to analyze the application or monitor its runtime. MinDroid execution is specified as a FSM, and its security properties are formally proven using MTL. We have also analyzed the security resilience of MinDroid against some attacks. MinDroid offers good performance in terms of detection time and execution cost in comparison with intrusion detection systems based on static and dynamic analysis. Simulation results show that MinDroid can achieve optimal detection efficiency under some values of user availability (i.e., λ and μ) and testing time period (T ). A prototype implementation

123

Arab J Sci Eng

Fig. 9 Prototype screenshots

of MinDroid is tested under Android emulator. As future work, we plan to extend MinDroid to protect Android devices against SMS-based botnets. Acknowledgments This work is supported by the Research Center of College of Computer and Information Sciences (CRC) at King Saud University, Grant Number RC1303108. The authors are grateful for this support.

References 1. Jones, T.: The emerging role of mobile: a look to 2020. E & i Elektrotechnik Und Informationstechnik 131(1), 5–7 (2014) 2. Cumiskey, K.M.; Ling, R.: The social psychology of mobile communication. Handb. Psychol. Commun. Technol. 33, 228 (2015) 3. Park, Y.J.; Jang, S.M.: Understanding privacy knowledge and skill in mobile communication. Comput. Hum. Behav. 38, 296– 303 (2014) 4. El Hajjaji El Idrissi, Y.; Zahid, N.; Jedra, M.: A new handover authentication method for WiMAX architecture. Arab. J. Sci. Eng. 39(12), 8837–8850 (2014) 5. He, D.; Chen, Y.; Chen, J.: An id-based three-party authenticated key exchange protocol using elliptic curve cryptography for mobile-commerce environments. Arab. J. Sci. Eng. 38(8), 2055– 2061 (2013) 6. Sandhya, M.; Rangaswamy, T.: Zero knowledge and hashbased secure access control scheme for mobile RFID systems. Arab. J. Sci. Eng. 39(3), 1897–1906 (2014) 7. Sridevi, B.; Rajaram, S.: Performance analysis of proposed cost reduction mechanisms for authentication in mobile WiMAX network entry process. Arab. J. Sci. Eng. 39(6), 4727–4735 (2014) 8. Taheri, M.; Bagheri, M.: High secure routing protocol with authentication and confidentiality increased in wireless ad hoc networks. Arab. J. Sci. Eng. 39(2), 1135–1145 (2014)

123

9. Kenney, M.; Pon, B.: Structuring the smartphone industry: is the mobile internet os platform the key?. J. Ind. Compet. Trade 11(3), 239–261 (2011) 10. Mawston, N.: Android captures record 85% share of global smartphone shipments in q2 2014. http://www.strategyanalytics.com/ default.aspx?mod=reportabstractviewer&a0=9921 (2014) 11. Maslennikov, D.: Mobile malware evolution 2013. https:// www.securelist.com/en/analysis/204792326/Mobile_Malware_ Evolution_2013 (2014) 12. Labs, F.S.: Mobile threat report: July–September 2013. http://www.f-secure.com/documents/996508/1030743/ Mobile_Threat_Report_Q3_2013 (2013) 13. Labs, F.S.: Mobile threat report: Q1 2014. http:// www.f-secure.com/documents/996508/1030743/ Mobile_Threat_Report_Q1_2014 (2014) 14. Cloudmark: 2013 global messaging threat report. http://www.cloudmark.com/releases/docs/threat_report/ cloudmark-2013-annual-threat-report (2014) 15. Traynor, P.; Lin, M.; Ongtang, M.; Rao, V.; Jaeger, T.; McDaniel, P.; La Porta, T.: On cellular botnets: measuring the impact of malicious devices on a cellular network core. In: Proceedings of the 16th ACM Conference on Computer and Communications Security (CCS ’09), pp. 223–234 (2009) 16. Felt, A.P.; Ha, E.; Egelman, S.; Haney, A.; Chin, E.; Wagner, D.: Android permissions: user attention, comprehension, and behavior. In: Proceedings of the Eighth Symposium on Usable Privacy and Security, p. 3. ACM (2012) 17. Felt, A.P.; Chin, E.; Hanna, S.; Song, D.; Wagner, D.: Android permissions demystified. In: Proceedings of the 18th ACM Conference on Computer and Communications Security, pp. 627–638. ACM (2011) 18. Arzt, S.; Rasthofer, S.; Fritz, C.; Bodden, E.; Bartel, A.; Klein, J.; Le Traon, Y.; Octeau, D.; McDaniel, P.: Flowdroid: precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps. ACM SIGPLAN Not. 49(6), 259–269 (2014) 19. Batyuk, L.; Herpich, M.; Camtepe, S.; Raddatz, K.; Schmidt, A.D.; Albayrak, S.: Using static analysis for automatic assessment and mitigation of unwanted and malicious activities within android

Arab J Sci Eng

20.

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

31.

32.

33.

applications. In: 6th International Conference on Malicious and Unwanted Software (MALWARE 2011), pp. 66–72 (2011) Enck, W.; Octeau, D.; McDaniel, P.; Chaudhuri, S.: A study of android application security. In: Proceedings of the 20th USENIX Conference on Security (SEC’11) (2011) Grace, M.C.; Zhou, Y.; Wang, Z.; Jiang, X.: Systematic detection of capability leaks in stock android smartphones. In: 19th Annual Network and Distributed System Security Symposium (NDSS) (2012) Schmidt, A.D.; Bye, R.; Schmidt, H.G.; Clausen, J.; Kiraz, O.; Yuksel, K.; Camtepe, S.; Albayrak, S.: Static analysis of executables for collaborative malware detection on android. In: IEEE International Conference on Communications (ICC ’09), pp. 1–5 (2009) Seo, S.H.; Gupta, A.; Sallam, A.M.; Bertino, E.; Yim, K.: Detecting mobile malware threats to homeland security through static analysis. J. Netw. Comput. Appl. 38(0), 43–53 (2014) Suarez-Tangil, G.; Tapiador, J.E.; Peris-Lopez, P.; Blasco, J.: Dendroid: a text mining approach to analyzing and classifying code structures in android malware families. Expert Syst. Appl. 41(4, Part 1), 1104–1117 (2014) Burguera, I.; Zurutuza, U.; Nadjm-Tehrani, S.: Crowdroid: Behavior-based malware detection system for android. In: Proceedings of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM ’11), pp. 15–26 (2011) Bierma, M.; Gustafson, E.; Erickson, J.; Fritz, D.; Choe, Y.R.: Andlantis: large-scale android dynamic analysis. In: Security and Privacy Workshops: Mobile Security Technologies (MoST) (2014) Grace, M.; Zhou, Y.; Zhang, Q.; Zou, S.; Jiang, X.: Riskranker: Scalable and accurate zero-day android malware detection. In: Proceedings of the 10th International Conference on Mobile Systems, Applications, and Services (MobiSys ’12), pp. 281–294 (2012) Ham, H.S.; Kim, H.H.; Kim, M.S.; Choi, M.J.: Linear SVM-based android malware detection. In: Frontier and Innovation in Future Computing and Communications, pp. 575–585. Springer (2014) Rasthofer, S.; Arzt, S.; Bodden, E.: A machine-learning approach for classifying and categorizing android sources and sinks. In: Proceedings of the 21st Network and Distributed System Security Symposium (NDSS 2014) (2014) Salman, A.; Elhajj, I.; Chehab, A.; Kayssi, A.: Daids: An architecture for modular mobile ids. In: 28th International Conference on Advanced Information Networking and Applications Workshops (WAINA), pp. 328–333 (2014) Shabtai, A.; Tenenboim-Chekina, L.; Mimran, D.; Rokach, L.; Shapira, B.; Elovici, Y.: Mobile malware detection through analysis of deviations in application network behavior. Comput. Secur. 43(0), 1–18 (2014) Zhang, Y.; Yang, M.; Xu, B.; Yang, Z.; Gu, G.; Ning, P.; Wang, X.S.; Zang, B.: Vetting undesirable behaviors in android apps with permission use analysis. In: Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security, pp. 611– 622. ACM (2013) Zhou, W.; Zhou, Y.; Jiang, X.; Ning, P.: Detecting repackaged smartphone applications in third-party android marketplaces. In: Proceedings of the Second ACM Conference on Data and Application Security and Privacy (CODASPY’12), pp. 317–326 (2012)

34. Siegfried Rasthofer, S.A.; Lovat, E.; Bodden, E.: Droidforce: enforcing complex, data-centric, system-wide policies in android. In: Proceedings of the 9th International Conference on Availability, Reliability and Security (ARES 2014) (2014) 35. Nauman, M.; Khan, S.; Zhang, X.: Apex: extending android permission model and enforcement with userdefined runtime constraints. In: Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security, pp. 328–332. ACM (2010) 36. Almohri, H.M.; Yao, D.D.; Kafura, D.: Droidbarrier: know what is executing on your android. In: Proceedings of the 4th ACM Conference on Data and Application Security and Privacy (CODASPY’14), pp. 257–264 (2014) 37. Derhab, A.; Saleem, K.; Youssef, A.: Third line of defense strategy to fight against sms-based malware in android smartphones. In: International Wireless Communications and Mobile Computing Conference (IWCMC 2014), August 2014 38. Xu, R.; Saïdi, H.; Anderson, R.: Aurasium: Practical policy enforcement for android applications. In: USENIX Security Symposium, pp. 539–552 (2012) 39. Sun, M.; Zheng, M.; Lui, J.C.; Jiang, X.: Design and implementation of an android host-based intrusion prevention system. In: Proceedings of the Annual Computer Security Applications Conference (ACSAC) (2014) 40. Sakamoto, S.; Okuda, K.; Nakatsuka, R.; Yamauchi, T.: DroidTrack: tracking and visualizing information diffusion for preventing information leakage on android. JISIS 4(2), 55–69 (2014) 41. Lee, H.T.; Kim, D.; Park, M.; Cho, S.J.: Protecting data on android platform against privilege escalation attack. Int. J. Comput. Math. (2014). doi:10.1080/00207160.2014.986113 42. Allalouf, M.; Ben-Av, R.; Gerdov, A.: Storedroid: sensorbased data protection framework for android. In: International Wireless Communications and Mobile Computing Conference (IWCMC 2014), August 2014 43. Security alert: New rootsmart android malware utilizes the gingerbreak root exploit. http://www.csc.ncsu.edu/faculty/jiang/ RootSmart (2012) 44. Bellini, P.; Mattolini, R.; Nesi, P.: Temporal logics for real-time system specification. ACM Comput. Surv. 32(1), 12–42 (2000) 45. Luo, W.; Xu, S.; Jiang, X.: Real-time detection and prevention of android sms permission abuses. In: Proceedings of the first international workshop on Security in embedded systems and smartphones, pp. 11–18. ACM (2013) 46. Tuck, N.; Sherwood, T.; Calder, B.; Varghese, G.: Deterministic memory-efficient string matching algorithms for intrusion detection. In: Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM 2004), vol. 4, pp. 2628–2639 (2004) 47. Van Lunteren, J.: High-performance pattern-matching for intrusion detection. In: Proceedings of 25th IEEE International Conference on Computer Communications, pp. 1–13 (2006) 48. Android Emulator. http://developer.android.com/tools/devices/ emulator.html 49. The Android Open Source Project. http://androidxref.com

123