Critical Evaluation of Security Framework in Android Applications ...

International Research Journal of Computers and Electronics Engineering (IRJCEE) Vol. 2, Iss. 1, DEC 2014 IRJCEE-120914-TM-2014-I-1

Critical Evaluation of Security Framework in Android Applications: Android-level security and Application-level security Tarun Mall

Samarth Gupta

College of Computing and Informatics UNC Charlotte, USA [email protected]

Genpact LLC, Gurgaon, India [email protected]

Abstract— Android is one of the most-used smartphone operating system in the world. While third-party user installed apps are the key to its success, they also pose a major security threat. These third-party applications cannot always be trusted with private and sensitive data. In order to focus on security vulnerabilities towards data in Android, it is important that the user is well-informed about the steps that he should take to protect himself. This is important because majority of smartphone users know how to use a smartphone but they don’t understand the technology behind it. Android security becomes critical for users to protect and preserve data over extended period of time. While some of the security features may be inbuilt into the android system, others are provided by third-party developers as a separate application or as an additional component of the downloaded application. It is therefore expected that the developers communicate these third-party security features to the users in a comprehensible manner. Keywords- Android; Smartphone, Operating System, Third-party, security, vulnerabilities

1.

INTRODUCTION

Android supports third-party apps for providing user the flexibility to choose from a plethora of applications. However, these third-party applications cannot always be trusted with private and sensitive data. Android incorporates certain security mechanism for user safety and privacy. Android runs all the applications in sandboxed environment Blasing et. al. (2010) [1]. A sandboxed application is not allowed to access data or functionalities outside the scope of sandbox. However, most of the times various apps need to access data outside the default scope of sandbox. For such kind of access, the application developer needs to specify the required permission during development (e.g., access to contacts, access to GPS, access to microphone etc.). The predefined permissions are presented to the user at the time of installation. User can choose to grant the permission and install the app or reject the installation. Android permissions can provide certain level of security to the data inside the Android. However,

many applications work on client-server model. In client-server model for android, applications on various devices are clients, which communicate to one (or more) server. This type of communication requires data exchange between client and server; this data exchange can be done over internet. When data travels over internet there is always chance that someone may eavesdrop over data. To prevent this, Android provides certain ways to use SSL (Secure Socket Layer) and TLS (Transport Layer Security) in the application but this security heavily relies on the application developer. Android security can be broadly categorized into two categories, Enck et. al. (2009) [2]: 1.

Android Level Security

2.

Application Level Security

The two security vulnerabilities mentioned above are concentrating on security of individual android applications. However, there are chances that more than one android application may come together and try to access data beyond their permissions. For instance, if a user gave access to ―contacts‖ to application A and ―internet‖ access to application B, then application A can provide contacts information to application B which can transmit the contacts to a remote server. This type of attack is called application collusion attack. Bartel et. al. (2012) [3] The rest of the paper is organized as follows. In section 2, we try to explain the various types Android-level security vulnerabilities and give some background information required to understand the security vulnerabilities in android application interface. In section 3, we discuss the Application Level security vulnerabilities that may be of consideration to the users. In section 4, we compare the various solutions provided by existing researchers and attempt to simplify to make them comprehensible to the users.

International Research Journal of Computers and Electronics Engineering (IRJCEE) Vol. 2, Iss. 1, DEC 2014 IRJCEE-120914-TM-2014-I-1

2.

ANDROID-LEVEL SECURITY FRAMEWORK

This category contains those vulnerabilities, which are due to fault or missing feature in android operating system. These vulnerabilities are difficult to fix because fixing them will sometimes reduce the flexibility which android provides to its application developers. This permission-based security gives android developers the flexibility required to provide the user with various services. However, this permission-based access control model is not perfect and fully secure. Application collusion is the concept in which more than one app can come together to perform a certain task, which is out of their permission capabilities. For example, the user downloaded two apps, one for removing duplicate images from gallery and other to access twitter account and filter his twitter posts. First app will request for permission to access images and second app will request for permission to internet access. Now if these two applications start behaving maliciously they can easily upload personal images of user to a remote server. Probable solutions towards mitigating application collusion attacks are: Bugiel et. al. (2011) [4] i. Limit attack Surface ii. Limit Multitasking iii. Application Review iv. Aggregate Permissions v. Static Analysis vi. Policy based installation strategy The security model of Android is ‗system-centric‘. This means various applications depend on the android operating system for their access restrictions. System-centric security system is actually not a bad thing; however, it seriously limits the application developer‘s capability to govern the access rights towards their application. For example, there is a shopping application, which can show various products from various sellers. When the user finds the product he wants to buy, he adds the product to cart and chooses payment option. Shopping app will now work with the payment applications on his cellphone for the payment. However, there may be a scenario when the payment application doesn‘t trust shopping app on his phone or if the payment app wants to avoid any payment data to be transferred over public Wi-Fi connection. Android doesn‘t provide any direct solution the similar problems. There may be some workarounds to some problems but a clear cut way to fix such problems would help lot of developers to add more security to their app. The solution to above problem in was provided by creating an application called Secure Application INTeraction (SAINT), With SAINT installed on the

mobile, and an application can declare permission and various conditions under which the permission is granted to other applications at the time of installation. SAINT allows applications to take control of the permission assignment they want to declare through explicit policy. On installation Saintenhanced Android installer fetches the requested permissions from Manifest file. For each permission, it asks the AppPolicy provider, which further consults with the database and returns true or false, based on matching rules. If returned decision is true, the installation proceeds; otherwise, it is aborted. Finally after successful installation new application‘s policies are appended to the database of AppPolicy provider. SAINT stores the permission policy and permission label in XML format. During run-time Saint controls the interaction between various applications. SAINT ensures that all policies are satisfied and then only allows IPC to continue. When a caller initiates an IPC, Saint intercepts it and queries to AppPolicy provider for policies that match that IPC. The AppPolicy provider checks all the policies and verifies whether all policies are satisfied or not. A true or false decision is returned based on the validation. If decision is true IPC transmission continues else IPC is blocked. Conti et. al. (2011) [5] Another problem in android‘s permission system is that user cannot control android permissions once user grants the permission. The reason for this vulnerability is the rigidity of android‘s permission based security model. For example, if user grants access to his social networking to some app, user has no control over the frequency with which the app can check his social networking profile. Or if user doesn‘t want certain apps to run on insecure or public networking due to fear of eavesdropping, there is no way to provide such restrictions. Beresford et. al. (2011) [6] To provide solution to above problem a systemMockdroid, is designed to provide complex policy restrictions based on different condition or scenarios. This system will enforce some policies after some event is triggered. This application monitors permission requests, content providers and intents. This system adds more flexibility to current permissions framework. This system allows designing complex permission policies based on many different conditions, which will be checked at runtime and not at deployment time. This system will also monitor the queries, which are being made by various applications to content providers. Content providers manage access to a structured set of data. They encapsulate the data, and provide mechanisms for defining data security. The author of content provider can design certain policies to enforce various security restrictions on the data. User will not able to change these types of policies. This system will also monitor intents. Intent is a messaging object

International Research Journal of Computers and Electronics Engineering (IRJCEE) Vol. 2, Iss. 1, DEC 2014 IRJCEE-120914-TM-2014-I-1

you can use to request an action from another app component. This system will provide ways to create complex policies to put certain restrictions on various intents. Kern and Sametinger (2012) [7] 3.

APPLICATION-LEVEL SECURITY FRAMEWORK

This category contains the vulnerabilities, which are induced because of application developer‘s mistakes or lack of cautiousness. 3.1 Man-in-the-middle (MITM) attack Android allows third party software to be installed on smartphones via Google‘s Play Store. Often these third party apps need to transmit data over to internet to provide various services, like a weather app may use one‘s location to give him latest weather update or a social networking app may need to transmit his contacts to find other friends on the network. When a data is transmitted over internet most of the times it is vulnerable to eavesdropping or Man-in-the-Middle (MITM) attack. The most common way to protect data while communicating is to use Secure Socket Layer (SSL) or Transport Layer Security (TLS) protocol. Elgamal and Hickman (1997) [8] Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communication security over the Internet. SSL/TLS protocol basically wraps data in a level of encryption, which prevents eavesdropper to steal the data. So in order to provide this layer of encryption the user needs public key of the destination to encrypt your data. Now if a server supports SSL encryption server will present an X.509 certificate, which will contain the required public key, name of the server and timestamp. User can encrypt the data using this key and transmit it securely to the server. To ensure the legitimacy of the certificate it is signed by a trusted third party called Certificate Authority (CA). User should never use a key, which is not signed by a trusted CA. Georgiev et. al. (2012) [9] 3.1.1 Countermeasures for MITM attack The problem with this approach is that the level of security is directly proportional to the skill level of third party developer. A good developer will always ensure that he/she performs all the steps for certificate validation and then only use the key. However, even if one step of validation is ignored it will leave application in a vulnerable state. This application vulnerability can be exploited to gain sensitive information like bank information, social networking account information, contacts information etc. The countermeasures suggested include Lee et. al. (2013) [10]:



 





Enforce Certificate Checking: Android should enforce stricter certificate checking. There are various trust managers which enforce very less or no restriction on validation. Refraining use of these trust managers will ensure some level of security. HTTPS Everywhere: All the android apps who work on client server model should be mandated to use https. Improved Permissions and Policies: New permission policies should be introduced which gives internet access via SSL or Plain text. Users can choose whether to install an app which requires only Plain text internet access. Visual Security Feedback: Whenever any app transmits any data, user should be given visual confirmation. This can be restricted based on what kind of data is being transmitted. MalloDroid Installation Protection: This app can be used to perform static code analysis, which will return the potentially unsafe applications.

3.2 Intent Spoofing attack Another type of attack, which falls under this category, is attacks, which take place due to intraapplication communication in android. ―Intent‖ is a messaging object the user can use to request an action from another app component. This messaging system allows code reusability. If an application is performing some task all we need is intent to communicate with it and get the task done. However, intents are a powerful tool, if not used cautiously intent can leave an application vulnerable to various attacks. Chin et. al. (2011) [11] Broadcast intents are vulnerable to eavesdropping. Ordered Broadcast intent can be stopped from propagating to other apps or its possible to changes its content before propagation. In ordered mode, broadcasts are sent to each receiver in order (controlled by the android: priority attribute for the intent-filter element in the manifest file that is related to your receiver) and one receiver is able to abort the broadcast so that receivers with a lower priority would not receive it (thus never execute). Activity and Service intents are vulnerable to MITM attacks. A malicious app can intercept intent to start an activity and start its own activity; by this that malicious app can steal sensitive information from the user. Intent spoofing attack can be conducted on unprotected component receivers. A malicious application can spoof an intent and can make the unprotected app to behave in an undesired manner. Kantola et. al. (2012) [12]

International Research Journal of Computers and Electronics Engineering (IRJCEE) Vol. 2, Iss. 1, DEC 2014 IRJCEE-120914-TM-2014-I-1

4.

CRITICAL EVALUATION OF PROPOSED SECURITY MODELS

THE

4.1 Permission-based security Preventive measures suggested by Marforio et. al. (2011) [13] will be very effective in preventing application collusion attacks. Most of the preventive measures are fairly technical and might be difficult for a common user to understand. However, there is a solution in which aggregate permissions should be presented to the user for approval. It might be easy for common user to understand simple permissions like SEND_SMS, INTERNET etc. But providing aggregate permission will further confuse them. Instead a probable solution could be using other methods like static analysis, application review etc. by the virtue of which a degree of vulnerability can be measured. For example, if two applications (one can access contact and other can access internet) are communicating with each other and there is a chance of private data leak then user should be intimated that by installing this application the potential data leak may increase from 1 to 3 if rated on a scale of 1 - 5. This will abstract the understanding required to make a decision based on various android permissions. 4.2 Application-centric security Ongtang et. al. (2012) [14] provided a semantically rich security model using SAINT application, which installs a new layer of permission policies. Applications can use them to get more power and hence, it will secure them from vulnerabilities. However, there isn‘t much explanation available about backwards compatibility. In case the user installs SAINT but it breaks midway in any of the existing application, then there might not be a way to disable or bypass SAINT for that application. Also, if android comes up with new set of permissions in future, SAINT may not be able to adapt to it. SAINT appears to be a really promising application and the inventors give the necessary power to the applications using SAINT. But SAINT should not be an enforced layer of security; it should be an optional layer of security and the user should be informed that SAINT increases the security. So when user sees an application supporting and using SAINT, the user should be more comfortable in installing that application. 4.3 Data-driven security Feth and Pretschner (2012) [15] addressed the issues arising due to rigidity of android‘s permission-based security model. This idea may be inspired by Mockdroid in an attempt to make android‘s permission system more flexible. Their idea is simple and effective and if introduced it will probably be used by a considerable number of users. However, if implemented this may introduce a huge set of complications for user. The implementation will give

enterprise more power to configure the devices and make them more secure for their employees. But if we look it from the point of view of an end user who is hardly able to understand all the permissions in android, this will confuse him further. Too many options will overcomplicate his user experience and he‘ll feel overwhelmed by them. Instead of making this a mainstream service for all android devices, this should be a need-to-install basis application. For instance, if a company wants its employees to use this application, they can purchase the license and use it in the cellphones that the company distributes to its employees. 4.4 Taxonomy-based security Vidas et. al. (2011) [16] discussed about various classes of security vulnerability in android. Their findings suggest two important ways to mitigate attacks against all classes of attacks- reducing the length of android patch cycle and authenticating ADB to increase the security of Android. The first solution will give Android more flexibility in fixing the vulnerabilities and the second solution will thwart the attacks in case an attacker breaks-in a device. The third solution suggested in paper may be inspired by iPhone security model of not allowing any application installation without user credential Polla et. al. (2012) [17]. We suggest one more way inspired by iPhone security model- Android should provide a way to erase device contents after 10 wrong attempts on password or allow a way to remotely erase the device. 4.5 SSL-based security Fahl et. al. (2012) [18] suggested two major SSL Security solutions- Enforce Certificate Checking and HTTPS Everywhere. The first solution may be highly recommended; when it comes to securing users private data there is no room for mistakes or slackness. The second solution of using HTTPS everywhere works fine and it certainly increases the security of the application. However, it is not always necessary for all the applications to use HTTPS all the time. Using SSL over no-SSL may slightly reduce the performance. This performance is worth compromising when it comes to banking applications. But real-time gaming applications might suffer due to this performance depreciation. So, instead of forcing every application to use HTTPS, we suggest that applications should be divided into three categories: Security Level 1, Security Level 2 and Security Level 3. Level 3 would be most secure and will force complete HTTPS use, Level 2 will be partial HTTPS use and Level 1 will use no-SSL. Developer should choose a category for his application. User will be presented with the security level while installation. Based on the use of application and security level user can accept or reject the installation.

International Research Journal of Computers and Electronics Engineering (IRJCEE) Vol. 2, Iss. 1, DEC 2014 IRJCEE-120914-TM-2014-I-1

5.

CONCLUSION AND FUTURE WORK

Security vulnerability of any operating system revolves around data. However, we cannot simply lock the data and keep it safe. We need to process it to get information. This processing sometimes takes place inside the smartphone and sometimes at a remote server. Android security model provides certain protection to the data. Android allows an application to run in a sandbox environment, which prevents application to access, anything outside the boundaries of sandbox. However, an application can request permission to access various features outside the sandbox environment. A developer needs to declare these permissions and at the time of installation these permissions are presented to the user. If user trusts the application to grant those permissions he can continue with the installation. Otherwise user can always reject the installation. Heuristics should be implemented in Android operating system to prevent these vulnerabilities. This may prevent the naïve developers in android community from creating applications which may be susceptible to intra-application communication attacks. REFERENCES [1] Blasing, T., Batyuk, L., Schmidt, A. D., Camtepe, S. A., & Albayrak, S. (2010, October). An android application sandbox system for suspicious software detection. In Malicious and unwanted software (MALWARE), 2010 5th international conference on (pp. 55-62). IEEE. [2] Enck, W., Ongtang, M., & McDaniel, P. D. (2009). Understanding Android Security. IEEE security & privacy, 7(1), 50-57. [3] Bartel, A., Klein, J., Le Traon, Y., & Monperrus, M. (2012, September). Automatically securing permission-based software by reducing the attack surface: an application to android. In Proceedings of the 27th IEEE/ACM International Conference on Automated Software Engineering (pp. 274-277). ACM [4] Bugiel, S., Davi, L., Dmitrienko, A., Fischer, T., & Sadeghi, A. R. (2011). Xmandroid: A new android evolution to mitigate privilege escalation attacks. Technische Universität Darmstadt, Technical Report TR-2011-04. [5] Conti, M., Nguyen, V. T. N., & Crispo, B. (2011). Crepe: context-related policy enforcement for android. In Information Security (pp. 331-345). Springer Berlin Heidelberg. [6] Beresford, A. R., Rice, A., Skehin, N., & Sohan, R. (2011, March). MockDroid: trading privacy for application functionality on smartphones. In Proceedings of the 12th Workshop on Mobile Computing Systems and Applications (pp. 49-54). ACM. [7] Kern, M., & Sametinger, J. (2012, September). Permission Tracking in Android. In UBICOMM

2012, The Sixth International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies (pp. 148-155). [8] Elgamal, T., & Hickman, K. E. (1997). U.S. Patent No. 5,657,390. Washington, DC: U.S. Patent and Trademark Office. [9] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D., & Shmatikov, V. (2012, October). The most dangerous code in the world: validating SSL certificates in non-browser software. In Proceedings of the 2012 ACM conference on Computer and communications security (pp. 38-49). ACM. [10] Lee, Y. S., Kim, E., & Jung, M. S. (2013). A NFC based Authentication method for defence of the Man in the Middle Attack. In 3rd International Conference on Computer Science and Information Technology (ICCSIT'2013) (pp. 4-5). [11] Chin, E., Felt, A. P., Greenwood, K., & Wagner, D. (2011, June). Analyzing inter-application communication in Android. In Proceedings of the 9th international conference on Mobile systems, applications, and services (pp. 239-252). ACM. [12] Kantola, D., Chin, E., He, W., & Wagner, D. (2012, October). Reducing attack surfaces for intraapplication communication in android. In Proceedings of the second ACM workshop on Security and privacy in smartphones and mobile devices (pp. 69-80). ACM. [13] Marforio, C., & Francillon, A. (2011). Application collusion attack on the permission-based security model and its implications for modern smartphone systems. Department of Computer Science, ETH Zurich. [14] Ongtang, M., McLaughlin, S., Enck, W. and McDaniel, P. (2012), Semantically rich applicationcentric security in Android. Security Comm. Networks, 5: 658–673. [15] Feth, D.; Pretschner, A.; , "Flexible Data-Driven Security for Android," Software Security and Reliability (SERE), 2012 IEEE Sixth International Conference on , vol., no., pp.41-50, 20-22 June 2012. [16] Vidas, T., Votipka, D., & Christin, N. (2011, August). All Your Droid Are Belong to Us: A Survey of Current Android Attacks. In WOOT (pp. 81-90). [17] La Polla, M., Martinelli, F., & Sgandurra, D. (2013). A survey on security for mobile devices. Communications Surveys & Tutorials, IEEE, 15(1), 446-471. [18] Fahl, S., Harbach, M., Muders, T., Baumgärtner, L., Freisleben, B., & Smith, M. (2012, October). Why Eve and Mallory love Android: An analysis of Android SSL (in) security. In Proceedings of the 2012 ACM conference on Computer and communications security (pp. 50-61). ACM.