Extending Android Security Enforcement with A Security Distance Model

Wei Tang, Guang Jin, Jiaming He, Xianliang Jiang

College of Information Science and Engineering Ningbo University Ningbo, Zhejiang, China tangwei@mail.nbu.edu.cn, jinguang@nbu.edu.cn
AbstractCompared to the traditional operating system platforms, smart phone platforms have different infrastructures and security requirements. Therefore new corresponding security strategies are also required. In this paper firstly we analyze the Android applications threats and existing security mechanisms weakness. Then we present an extending of Android Security Enforcement with a Security Distance model, ASESD, to mitigate malware. The new scheme can be implemented in an Android phone and make applications more safe. Our theoratical anlyses and practical evaluations show ASESD more accurate and highly scalabe. Keywords-Android; security; malware; security distance

II.

RELATED WORK

Many of the recent work focus on the smart phone security. Because smart phone platforms often use a Linux kernel, Muthukumaran et al. applied SELinux security policy on smart phone, and Zhang et al. [2] directly replaced Androids Linux kernel with SELinux. Fuchs et al. proposed ScanDroid [3] which determined applications behavior by analyzing programs data flow. While Ongtang et al. usied semanticbased analysis to find malware. But the common drawback of these kinds of schemes is they need the source code of the application to do their analysis. Kirin [4] also validated permission assignment at install time. Kirin checked applications permission request using predefined security rules. Security rules described dangerous permission presentation. But security rules are separated to each other, so Kirin couldnt evaluate the applications overall threat. In addition, Kirins security rules couldnt tell the dangerous level of different permission combinations. III. BACKGROUND INFORMATION

I.

INTRODUCTION

Smart phones and tablet PCs gain popularity rapidly. Their development has benefited from iOS of Apple, Android of Google, Windows phone, and other platforms. And countless application impacts all aspects of peoples life. However, all kind of malware also have opportunities to threaten users phone security. Smart phone operation systems include Android use a sandbox model, which made it very hard for malware to affect other applications in the system. So the most popular type of malware is Trojan, which pretends to be legitimate application and do harms at background, such as stealing users personal data. The Geinimi Trojan appeared in China at the end of 2010 is one representative. Android uses a set of application security enforcements to protect the safety of smart phone [1]. The enforcements include several aspects. The permission based security policy is one of the most important part and has significant influences on smart phone security. Permissions assigned to an application restrict the operations the application can apply to the smart phone. However, legitimate applications and malware both use these permissions, so its difficult for user to identify malware. In this paper, we present ASEDS which aims at helping to mitigate malware. Based on the existing permission policy, we propose the Security Distance (SD) model which measures the dangerous level of certain permission combinations presentation. Using SD, we provide a method to identify malware from legitimate applications when an application requested permissions at install time.

Android application consists of components. According to different functionality; there are four types of components [5]. Activity component defines the applications user interface and interacts with user; Service component provides background processing; Content Provider component is responsible for data storing and sharing; Broadcast Receiver component acts as a mailbox for messages from other applications. Components can interact with other components in the same application and/or another application using Androids inter-process communication (IPC) mechanism. Most Android built-in services such as SNS, Phone book and device-based functions are implemented as components. It is easy for thirdpart applications to use built-in services with Androids IPC, but also exposes smart phone and user data to dangerous. To protect smart phone security, Android mediates IPC based on permission labels [6]. Permission labels are text strings that application can request in the manifest file. Android assigns permissions to application at install time and the permissions cant be changed at runtime. When the applications component wants to communicate with other components, Android reference monitor will check whether the target component need a permission label to access and whether the component initiating the IPC has been assigned the

978-1-4244-7255-0/11/$26.00 2011 IEEE

right permission label. Only the IPCs that pass this mandatory access control mechanism can be established. Well show how permission policy involved when malware harms the smart phone security by analyzing Geinimis behavior. Geinimi is a Trojan affecting Android phones. It can perform various kinds of malicious behaviors such as malicious advertising, compromising personal data and malicious chargeback. It even has the ability to create botnet. Malware is often produced by repackaging legitimate applications with the Geinimi Trojan. At install time, malware requested much more permissions than the legitimate application in order to perform its malicious behaviors. When the user run the malware affected by Geinimi, Geinimi took over process control and started malicious component. Then the process control returned to the original application and Geinimi continued in the background. IV. THE CONCEPT OF SECURITY DISTANCE

permission pairs and SD rules defines how to determine SD of certain permission pairs. V. SECURITY DISTANCE RULES

Like the Geinimi, malware always disguise as normal application [7], perform some useful functions and do malicious behaviors in background. So it is hard for user to be aware of exist of the malware. When the user knows malwares existence, it is often too late as the damage has already been done. Therefore, the best way of mitigating malware is to identify it in install time and prevent it to be installed. Although malware affected by Geinimi looks like legitimate application, it is not completely without a trace. Table 1 show the applications requested permission list before&after the infection of Geinimi. It is clear that Geinimis infection does cause difference by requesting extra permissions. In addition, after infection by Geinimi, application also requested rights to monitor the boot completed state (android. intent.action.BOOT_COMPLETED) and the message received event (android.provider.Telephony.SMS_ RECEIVED ). The reason why there is such a big difference is that Geinimi trys to achieve all possible malicious behavior and these actions are mostly mediated by Android. Therefore, Geinimi needs to request security permissions for these actions. If other malware just apply some of the malicious behavior, such as stealing user's personal data, or just simply malicious chargeback, extra security permissions that are needed will be greatly reduced. But as long as malware wants to perform malicious behaviors, difference will be remaining. On the other hand, when installing application, Android just lists the requested security permissions by application, and depends on the user to determine whether the application is legitimate. But for ordinary users it is difficult to make such judgments just watching the permission list. Extra information is needed to help users to make appropriate decisions.
TABLE I. PERMISSION REQUESTED BEFORE&AFTER GEINIMI
AFFECTS

A permission being assigned to an application can be seen as a sign of getting the ability of using certain kind of functions. So any individual permission will not and should not be threaten the security of smart phone and user data. Because if a function itself is unsafe, then all applications should never use this function, and the permission is no longer necessary. For example, READ_PHONE_STATE permission allows applications to get some phone information (phone numbers, IMEI, IMSI, etc.), but the permission itself will not result in the loss of personal data. Legitimate applications often use this information to identify the users location, so they can provide personalized service. Only the application that requested the READ_PHONE_STATE permission also requested a number of other permissions such as the INTERNET (allowing access to the Internet) may cause the loss of personal data. So the problem is not the permissions themselves, but the relationship between certain permissions. Such as the READ_PHONE_STATE and INTERNET permission pair mentioned before, or the combination of RECEIVE_SMS and SEND_SMS permission. However, not all permission combinations will cause security issues, most of the combinations are safe. By recombining permissions that previously mentioned, READ_PHONE_STATE and RECEIVE_SMS pair, INTERNET and RECEIVE_SMS pair all will not cause problems. Another point need to be noticed is that even if problems arisen by some permission combinations, the severity of problems caused by different permission combinations are different. For READ_PHONE_STATE and INTERNET combination, in the absence of other permissions, only some phone information will be affected. Without other useful user data information, this phone information alone will not cause any personal data leak problem. However, due to the popularity of online payment using text messages, the combination of RECEIVE_SMS and SEND_SMS will have a greater impact on the user. To express the difference between permission combinations with security problems and combinations with security problems as well as To distinguish different levels of security threats, this paper introduces the model of SD and proposes a set of SD rules. SD is a figure that represents the risk level of

Before Geinimi affect INTERNET ACCESS_COARSE_LOCATION READ_PHONE_STATE VIBRATE

After Geinimi affect INTERNET ACCESS_COARSE_LOCATION READ_PHONE_STATE VIBRATE INSTALL_SHORTCUT ACCESS_FINE_LOCATION CALL_PHONE MOUNT_UNMOUNT_FILESYSTEMS READ_CONTACTS READ_SMS SEND_SMS

SD definition: a permission combinations SD is the quantitative representation of the security threat this combination may cause. A permission pairs SD is consisting of a threat point which represents the danger level and related characters. Permission combinations with SD of high threat point means applications with this permission combination have a big chance to threat mobile phone security. On the contrary permission pairs that have SD with low threat point indicate a safe application.

There are four types of SD: Safe SD represents a safe combination of security permissions that has a threat point of 0. Normal SD means a permission pair has no clear security threat with a threat point of 1. Dangerous SD with a threat point of 5 indicates a permission combination may have threat. Severe dangerous SD with a threat point of 25 means a permission pair with serious threat to the mobile phone security.

wireless network, the legitimate application usually needs to use ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE et al. permissions to determine the network status when the application is running to provide a robust service. But the malware usually uses INTERNET in the background, and does not need these. We group this kind of permissions as a safe permission group as they always appear together in legitimate application and can be seen as a safe declaration. Therefore, permission pairs in the same safe permission group can be considered as safe combination and have a safe SD. Except these three kinds of SD which have been discussed above, the last kind of SD is normal SD. Combinations that dont have apparently security problem but also dont belong to the same safe permission group belong to the normal SD category. However, these combinations will still affect the overall threat level of the application because the more security permissions the application request, the more threat the application may cause. Based on the security attribute and the potential user, all permission combinations can be divided into four categories: dangerous permission pairs that used only by malware, dangerous ones both legitimate application and malware may use, normal permission pairs improving applications robust always used by legitimate applications, normal permission pairs both legitimate application and malware may use. This kind of dividing can completely include all permission pairs and is the the theoretical basis of SD. Adding up all the threat point of permission combinations, we can generally determine the threat level of an application. But before that, there are several points that should be considered. C. Classification of Security Permission When analyzing the Android security permission list, we can classify them by their functions and their related device. For example, READ_SMS, RECEIVE_SMS, SEND_SMS, WRITE_SMS, BROADCAST_SMS permissions all related to the SMS function. For the legitimate application, one application may only use a few kinds of these. But a malware may use to more, especially when a legitimate affected by Trojan like Geinimi. So, when computer the security level of an application, the number of different security permission classifications the application used is an important factor that must be considered. D. Closure of Security Distance So far, we only discuss SD between two security permissions, but the real situation is more complex. Consider INTERNET, READ_PHONE_STATE, READ_CONTACTS security permissions. If only considering every two permissions SD, the INTERNET, READ_PHONE_STATE pair, and the INTERNET, READ_CONTACTS pair is dangerous SD with a threat point of 5. READ_PHONE_STATE, READ_CONTACTS pair is normal SD with a threat point of 1. But with real security experience, it is much more dangerous when an application has both access to phone information and contact information. We will use the closure attribute of the SD to reflect this situation. A closed SD means that the threat level of the

By determining the SD of each permission combination, and then calculating the overall safety level of the application using threat point and other related characters, we can provide more security information of the application. A. Dangerous Level It is easy to understand that safe permission combinations and dangerous permission combinations have different SD. But why there are two kinds of dangerous SD? And what is the difference between safe SD and normal SD? We first explain the first question, why we divide permission combinations with security problem into dangerous SD and severe dangerous SD and what are the criteria to distinguish them. Look at two examples of permission pair with dangerous SD and severe dangerous SD. READ_CONTACTS and the INTERNET is a combination of dangerous SD, RECEIVE_SMS and SEND_SMS is a combination of severe dangerous SD. As described in early chapter, the severity of the security problem caused by these two combinations is a different, but this is not the essence of the problem. Something really matter is what kinds of applications may use such a combination. READ_CONTACTS and INTERNET permission pair can be used togethor in a IM application. At the same time, In order to achieve malicious purposes, Geinimi also requests READ_CONTACTS and INTERNET permission pairs. That means both legitimate application and malware may use the READ_CONTACTS and INTERNET permission pairs, although legitimate application uses it for legitimate reason and malware uses it for bad reason. In contrast, for RECEIVE_SMS and SEND_SMS pair, there is no reason to use it in legitimate application. Only malware needs them to achieve malicious chargeback purpose. So, we define the permission combinations that may use both by legitimate application and malware as dangerous SD, and permission combinations used only by malware as severe dangerous distance. However, this definition doesnt mean dangeroussecurity-distance permission pair is less dangerous. B. Safe Permission Group Severe dangerous SD can be seen as a malicious declaration. Application with these kinds of combinations is most likely malware. Correspondingly, there is also a safe declaration. The permission group of INTERNET, ACCESS_NETWORK_STATE and ACCESS_WIFI_STATE is a typical example. INTERNET is security permission for network connection, but because of the complexity of the

combination will not be impacted by other combinations, and an unclosed SD means the combinations threat level will be increase when another related combination with unclosed SD appeared. And when computer the overall threat level of the application, if there are related unclosed SD, the threat point of these SD need to be replaced by the product of the two SD.
New application ASESD security service

Android application installer Figure 1. Software installer extended by ASESD

Figure 2. Evaluation results of ASESD security service

VI.

ASESD SECURITY SERVICE

In the existing Android security enforcement, when installing application, the system will check the applications manifest file for the security permissions it requested, then display the corresponding user interface to remind user. If the user chooses to continue the installation, the system will grant these permissions to application, if user chooses not to trust the application, the system's installation process will be terminated. As we mentioned earlier, the security threats are not described in an intuitive way. It is difficult for common users to obtain an accurate understanding of the consequences of various security permissions. So we proposed ASESD security service based on SD rules to improve the existing Android security enforcement. Figure 1 depicts the Android software installer extended by ASESD. ASESD is implemented as a standalone service which communicates with software installer using the RPC interface. ASESD gets the path of the installation package from software installer, then gets the applications security permission information using PackageManager and PackageParser interfaces. By applying the SD rules, ASESD will calculate the threat point result of the application and return it to the software installer, the software installer can use the result to provide more accurate security information of the application to the user.

Only a few number of applications get a threat point between 50 and 100. User should make addtional caution on these applications, as they may be just legitimate applications with lots of functions or they may have malicious behaviors. User should decide whether to install them combining with other factors. The application affected by Geinimi which is not included in the figure get a threat point over 500. User can identify it easily, and reject to install it. VII. CONCLUSION

This paper proposed a new extending of the Android security enforcement based on the SD rules ASESD, a lightweight application security authentication service. By analyzing the Geinimi and using Geinimi to evaluate our program, we believe that the program is effective in finding potential malware. Next, we will continue to in-depth work, such as using machine learning to improve the SD calculation, make the program more accurate and highly scalabe. ACKNOWLEDGMENT This research was supported in part by International Cooperation Projects (2009DFA12120), Major Projects of National Science and Technology (2011ZX03002-004-02), Major Scientific & Technology Specific Programs of Zhejiang for key industrial project(2010C11G2070007), Scientific Research Fund of Zhejiang Provincial Education Department (Y200906155). REFERENCES
[1] A. Shabtai, Y. Fledel, U. Kanonov, et al. Google Android: A Comprehensive Security Assessment, IEEE Security and Privacy, 8(2):35-44, 2010 X. Zhang, O. Aciimez, and J. Seifert. A Trusted Mobile Phone Reference Architecture via Secure Kernel. In Proceedings of ACM workshop on Scalable Trusted Computing, November 2007. A. Fuchs, A. Chaudhuri, and J. Foster. SCanDroid: Automated Security Certification of Android Applications. In Proceedings of IEEE Symposium on Security and Privacy, May 2010. W. Enck, M. Ongtang, and P. McDaniel. On Lightweight Mobile Phone Application Certification. In Proceedings of ACM Conference on Computer and Communications Security, November 2009. A. Schmidt and S. Albayrak. Malicious Software for Smartphones. Technical Report TUB-DAI 02/08- 01, DAI-Labor, February 2008. W. Enck, M. Ongtang, and P. McDaniel, Understanding Android Security. IEEE Security & Privacy Magazine, 7(1):50-57, 2009. A. Bose, X. Hu, K. Shin, et al. Behavioral Detection of Malware on Mobile Handsets. In Proceedings of the International Conference on Mobile Systems, Applications, and Services, June 2008.

R = ( d c + d ij d jk ) G

(1)

Equation (1) shows how the ASESD calculate the threat point of an application. The dc in the equation stands for the closed SD of the application, dij and djk stand for the related unclosed SD, subscript i and k represent the different permission of the two pairs, and subscript j represents the same permission of the two pairs. G stands for the number of classifications the application used. Finally, we get the overall threat point of the application in R. We have chosen about 100 applications from the Android application store to evaluate the security enforcement extended by ASESD, and the results shown in Figure 2. From the figure, we can see that large part of the applications get their threat point smaller than 20. That means the applications only request a few permissions, and the SD of these permissions are small. So, these must be safe applications.

[2]

[3]

[4]

[5] [6] [7]