Multimed Tools Appl DOI 10.1007/s11042-016-3273-x
Research on android malware permission pattern using permission monitoring system Seung-hwan Ju 1 & Hee-suk Seo 2 & Jin Kwak 3
Received: 10 February 2015 / Revised: 23 August 2015 / Accepted: 11 January 2016 # Springer Science+Business Media New York 2016
Abstract Mobile anti-viruses used mainly are the reverse engineering-based analysis and the sandbox-based analysis. There methods can analyze in detail. But, they take a lot of time and have a one-time payout. This study investigates the permissions requested by Android applications, and the possibility of identifying suspicious applications based only on information presented to the user before an application is downloaded The pattern analysis is based on a smaller data set consisting of confirmed malicious applications. The method is evaluated based on its ability to recognize malicious potential in the analyzed applications. This study is a service-based malware analysis, it will be based on the mobile security study. Keywords Mobile security . Application permission . Application analysis
* Jin Kwak
[email protected] Seung-hwan Ju
[email protected] Hee-suk Seo
[email protected]
1
Department of Computer Engineering, Korea University of Technology and Education, Cheonan-si, Chungcheongnam-do, Republic of Korea
2
Interdisciplinary Program in Creative Engineering, Korea University of Technology and Education, Cheonan-si, Chungcheongnam-do, Republic of Korea
3
Department of Information and Computer Engineering, College of Information Technology, Ajou University, Suwon, South Korea
Multimed Tools Appl
1 Introduce Android malware appears to have moved beyond the proof-of-concept and destructive phase almost completely. The first malware recorded by Symantec, Ewalls [12], attempts to steal personal information from the device it is installed on, including the devices IMEI (International Mobile Equipment Identity) number and details from the SIM (Subscriber Identity Module) card including operator name and serial number. It is worth noting that despite this, the FakePlayer Trojan [1–2] is often considered the first malware aimed at Android [13]. This could be explained by the spread of the malware, as Ewalls appears to have managed to compromise a far smaller number of Android devices than Fakeplayer [9]. The Android system uses several methods to secure the devices of the users. Below we will describe the security features that affect applications directly, which are the features that are relevant for malicious applications to attempt to defeat or circumvent; Permissions Sandbox Application signing Remote kill switch File system Protection Google Bouncer Anti-virus applications Despite these are security policies [3], the consensus is that the number of malicious applications targeting the Android platform is increasing, and the malware is becoming more and more sophisticated. As such, even if the numbers are grossly overstated, identifying and neutralizing malicious applications should be a top priority for both Google and other interested parties. We study common malwares permission patterns using pattern monitoring system (Fig. 1).
2 Background 2.1 Android permission Android is built on top of Linux. Android applications are written in Java, although they can have some native code components. In Android, each application is installed as a separate user. Each application has its own home directory where its code and data reside and it is accessible only by that application’s
Fig. 1 Android structure [1]
Multimed Tools Appl
user ID. Right off the bat, one application can’t go look at the files of another application. This makes all sharing explicit. So that’s how Android solves the sandboxing problem [7–10]. Android restricts the capabilities of applications installed on the device by explicitly requesting the user to allow the application to access various parts of the operating system or features of the device [17,18]. In order for an application to be able to use one of these capabilities, it is required to have the related permission been granted by the user during installation. Permissions [4] are stored in a file called manifest.xml found inside the Application Package file of the application, and cannot be changed after the application is installed. An exception from this rule is made when updating applications, but the user is still required to approve any new permissions, in a similar process as when first installing the application (Fig. 2).
2.2 Android update attack The Android security model [5,6,11,15,16] is based mainly on permissions. A permission is a restriction limiting access to a part of the code or to data on the device. An application can define its own permission variables and the permissions it needs inside the application’s AndroidManifest.xml manifest file. One or more < uses-permission > tags can be used declaring the permissions that your application needs. For example, an application that needs to monitor incoming SMS messages would specify:
…
Fig. 2 Permissions of android application
Multimed Tools Appl
The system comes with some predefined permissions. When you install an Android application, a pop-up tells you what kind of permissions the application needs (Fig. 3). The first technique typically piggybacks [14] the entire malicious payloads into host apps, which could potentially expose their presence [4,7–10]. The second technique makes it difficult for detection. Specifically, it may still repackage popular apps. But instead of enclosing the payload as a whole, it only includes an update component that will fetch or download the malicious payloads at runtime. As a result, a static scanning of host apps may fail to capture the malicious payloads. While some embed root exploits that allow for silent installation of additional apps without user intervention, we here focus on other variants that use the update attacks without root exploits. We develop a system to monitor that mobile application permissions at application update. Monitoring system for permission request by application keeps track of permission requests from various applications.
3 Mobile application permission monitoring system We study a tool for analyze permissions of applications. It is monitor permission requests by application installing. It keeps track of permission requests from various applications. Permission request is a part of the installation of Android applications and the same process is done when the applications are updated. Therefore, it is possible to monitor permission requests
Fig. 3 The difference permission with malware
Multimed Tools Appl
from applications upon update by tracking the AndroidManifest.xml file of an application software or by tracking the system function that requests permission. First, methods to detect event of app installation (including update); BroadcastReceiver Intent The monitoring system inherits the BroadcastReceiver object and has the authority to access various Android system events. It collects the broadcast messages, filters the information on adding an application or updates among the messages, and obtains the information on the app from the filtered messages (Fig. 4). This system uses the Intent object to detect the update events. Upon the occurrence of an application event, the onReceive() method of the corresponding application is called, and the Intent object passed as an argument contains the event status values. This system monitors the permission request status when applications are installed by using the values of Intent object. The system has been designed to detect the application update event when the Intent object of Intent.ACTION_PACKAGE_ADDED. Upon the detection of application installation event, this system accesses the application that generated the event and saves the requested permission in the files by date. Context object passed as the first argument of the onReceive() is used. PackageManager object can be obtained using the getPackageManager() method of the Context object, and the PackageInfo object can be obtained from the PackageManager (Table 1). PackageInfo object contains various package information as well as the application permission request information, which is how this system can search the permission request from the installed applications. When the monitoring system is executed, it generates and outputs the list of all previously collected files. The file list contains the package name with message reception time stamp so that users can search various information including the time of installation, requested permission, and permission request history. Since the name of the application and installation time are saved along with the requested permission, a new file will be generated for the same application if the date is different (Fig. 5). Files containing this information can be checked through the corresponding monitoring system application, and this system creates groups by the label of each application.
Fig. 4 Overview of monitoring system for application permission
Multimed Tools Appl Table 1 Structure of PackageInfo Object
Users can check the list of files categorized by label from the first screen. When one of the items in the list is selected, the list organized by date can be checked again. Select the date and press the OK button to view the list of permission requests for the corresponding date. In case of applications installed after installation of this monitoring system, the entire history of permission requests from initial installation and all updates are saved for systematic management and analysis (Fig. 6). This system to monitor the permission request by application allows users to search the relationship between application services and permission requests. Also, users can check the history of permission requests from each application and manage the applications accordingly.
4 Malware application patterns We can analyze malwares to our permission monitoring system. Generally speaking, almost Android malware are Trojans. Because of the sandbox, the attack vectors used by viruses and Fig. 5 Change event list of application permission request
Multimed Tools Appl Fig. 6 Permission request status of such application
worms are largely unavailable to the malware developers. Utilizing Trojans have thus become the norm. Applications misused for this purpose are often paid applications redistributed as free applications on third-party markets. DroidDream is a Trojan that leverages two root exploits, rageagainstthecage and exploid, to gain control of the device. DroidDream gained full control of the device if the root exploits succeeded. DroidDream pattern: INTERNET CHANGE_WIFI_STATE ACCESS_WIFI_STATE READ_PHONE_STATE This pattern is rather interesting, as it consists of only four permissions, and only one of them is overrepresented in the malicious data set. Running this pattern against the complete data set resulted in twelve malicious applications caught. Comparatively, from the legitimate market data set the pattern matched 199 applications, mostly from the Google Play market. Geinimi is found attached to repackaged legitimate applications. The malware has not been found in the Google Play market, but has been found in third party markets, mainly Chinese. The Trojan has many capabilities, but these capabilities are hidden until it is instructed by a C&C server (Command and Control server) to utilize them. The capabilities range from making premium phone calls to stealing personal data like IMEI number and the geographic location of the device. Genimi pattern: ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION CALL_PHONE INTERNET MOUNT_UNMOUNT_FILESYSTEMS READ_CONTACTS READ_PHONE_STATE SEND_SMS SET_WALLPAPER
Multimed Tools Appl
WRITE_CONTACTS WRITE EXTERNAL_STORAGE. The Geinimi Trojan requests a rather distinct set of permissions, many of which are not often requested by legitimate applications. Using this pattern on the data set resulted in no hits from the legitimate markets, only the malicious data set. The pattern matched two additional malware samples; Universal Androot, which is infected with the Lotoor Trojan, and the Arspam malware. The GoldDream Trojan infects devices through repackaged versions of legitimate Android games. Once installed on a device, it begins to monitor phone calls and text messages, and transmits information like phone numbers, text message contents and duration of phone calls to an external server. GoldDream pattern: INTERNET ACCESS_NETWORK_STATE READ_PHONE_STATE ACCESS_WIFI_STATE WRITE_EXTERNAL_STORAGE ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION RECEIVE_SMS / SEND_SMS / READ_SMS CALL_PHONE PROCESS_OUTGOING_CALLS PACKAGES / INSTALL_PACKAGES RECEIVE_BOOT_COMPLETED. The Pjapps Trojan establishes a botnet of infected devices. When an application infected with Pjapps is installed on a device, the Trojan sends private information like the IMEI number and the SIM serial number to a C&C server and awaits further commands. These commands include sending text messages, installing applications and adding bookmarks to the browser. Pjapps pattern: ACCESS_NETWORK_STATE ACCESS_WIFI_STATE DISABLE_KEYGUARD READ_PHONE_STATE RECEIVE_SMS / SEND_SMS WRITE_EXTERNAL_STORAGE INTERNET
5 Conclusions Manual pattern recognition has proven to be effective in selecting applications for closer scrutiny. Patterns in the permission requests of malicious applications were identified, and can be applied to the complete data set in order to single out applications matching the identified patterns. This cannot be considered a reliable way of uniquely identifying malicious
Multimed Tools Appl
applications in the complete data set, but applications matching the malicious patterns can be singled out for review. A system to monitor permission requests from mobile applications was studied for security reasons as many application malicious codes created by tampering permission requests have been discovered recently. Users can use this system to check the permission request history of each application and manage applications. This permission monitoring system saves log files and requested permission obtained from the initial installation event of an application. And, when the application is updated, the permission requests and update dates after the update are compared with the existing requests. Mobile terminals with this permission monitoring system save all history of permission requests from the installation to any updates of applications for the purpose of systematic management and analysis. This monitoring system can be used for various research such as pattern analysis of applications that abuse the permission request system and Android permission requested by malicious codes. We have considered some ways the project can be extended, and how the dataset can be used for further research. We want to study that including third-party permissions and explore machine learning methods in the future. In the future we will use this system to find patterns using the relationship between application services and requested permissions and will devise a more advanced system to validate applications using this information. Acknowledgments This work was supported by the ICT R&D program of MSIP/IITP, Republic of Korea. [13912-06-003, Development of Mobile S/W Security Testing Tools for Detecting New Vulnerabilities of Android]
References 1. Arxan (2012) State of Security in the App Economy: Mobile Apps under Attack 2. Barrera D et al (2010) A methodology for empirical analysis of permission-based security models and its application to android. Proceedings of the 17th ACM conference on Computer and communications security. ACM 3. Chandramohan M, Tan HBK (2012) Detection of moblie malware in the wild. Computer 45(9) 4. Chandramohan M, Tan HBK (2012) Detection of moblie malware in the wild. Computer 45(9) 5. Enck W et al (2009) Understanding android security. IEEE Security & Privacy Magazine 7(1):50–57 6. Enck W, et al (2011) A Study of Android Application Security. Proc. 20th USENIX Conf. Security, Security 7. F-Secure. Threat description: Trojan:android/droidkungfu.c. Available: http://www.f-secure.com/v-descs/ trojan_android_droidkungfu_c.shtml. Accessed 15.02.10 8. F-Secure. Threat description: Trojan:android/ginmaster.a. http://www.f-secure.com/v-descs/trojan_android_ ginmaster_a.shtml. Accessed 15.02.10 9. F-Secure. Threat description: Trojan-downloader:osx/ashback.c http://www.f-secure.com/v-descs/trojandownloader_osx_flashback_c.shtml. Accessed 15.02.10. 10. F-Secure. Threat description: Virus:boot/brain. http://www.f-secure.com/v-descs/brain.shtml. Accessed 15. 02.10. 11. Felt AP et al (2011) Android Permissions Demystified. Proc. 18th ACM Conf Comput Commun Security (CCS) 12. F-Secure (2014) Mobile threat report 13. McAfee (2012) McAfee Threats Report: First Quarter 2012 14. Moser A, Kruegel C, Kirda E (2007) Exploring Multiple Execution Paths for Malware Analysis. Proc. IEEE Symp. Security Privacy, SP, pp 231–245 15. Shabtai A et al (2009) Google Android: A State-of-the-art Review of Security Mechanisms. Technical Report. Cornell University
Multimed Tools Appl 16. Xu R, Saidi H Anderson R (2012) Aurasium: Practical Policy Enforcement for Android Applications. 21st USENIX Security Symp. USENIX 17. Yan LK, Yin H (2012) DroidScope: Seamlessly Reconstructing the OS and Dalvik Semantic Views for Dynamic Android Malware Analysis. Proc 21st USENIX conf. Security Symp., Security 18. Zhou Y, Jiang X (2012) Dissecting Android Malware: Characterization and Evolution. Proc 33rd IEEE Symp Security and Privacy
Seung-hwan Ju Ph.D Candidate at Department of Computer Engneering, Korea University of Technonogy and Education, Korea B.S, M.S degree from Korea University of Technonogy and Education, Korea Interest : Application Security, Mobile Security, SCADA Security
Hee-suk Seo Professor, Department of Computer Engneering, Korea University of Technonogy and Education, Korea B.S, M.S, Ph.D. degree from Sungkyunkwan University, Korea Interest : Network Security Technology, Security Simulation, System Security.
Multimed Tools Appl
Jin Kwak Professor, Department of Cyber Security, College of Information and Technology, Ajou University, Korea B.S, M.S, Ph.D. degree from Sungkyunkwan University, Korea Interest : Cryptographic protocols, Application System Security, Secure Privacy