A Comprehensive Study on Security issues in Android Mobile ... - ijirae

12 downloads 398 Views 2MB Size Report
Abstract—Due to tremendous development and growth in mobile phone .... 2 Graph showing mobile malware (Source: www.gdata-software.com) ... The android apps are created using Java and executed in a virtual machine called Dalvik VM.
International Journal of Innovative Research in Advanced Engineering (IJIRAE) ISSN: 2349-2763 Issue 03, Volume 3 (March 2016) www.ijirae.com

A Comprehensive Study on Security issues in Android Mobile Phone Scope and Challenges —

Shubham Chatterjee* Dept. Computer Science St. Xavier’s College (Autonomous) Kolkata, India

Kasturi Paul Dept. of Computer Science St. Xavier’s College (Autonomous) Kolkata, India

Reek Roy Dept. of Computer Science St. Xavier’s College (Autonomous) Kolkata, India

AsokeNath Dept. of Computer Science St. Xavier’s College (Autonomous) Kolkata, India

Abstract—Due to tremendous development and growth in mobile phone software and hardware technologies now Security issues is a very big challenge to all concerned persons such as scientists, manufacturers, designers, industrialists and so on. Usually, such technology takes time to be absorbed into the market and this gives time to the security teams to develop effective security controls. The rapid growth of the smart-phone market and the use of these devices for email, online banking, and accessing other forms of sensitive content has led to the emergence of a new and ever-changing threat landscape [1]. Along with this, the fact that anyone can be a user has led to the smart-phone appearing in the hands of almost every person before the proper security controls can be developed. Currently, android has the biggest share in the market among all the smart-phone operating systems. As the powers and features of such phones increase, their vulnerability also increases and makes them prone towards security threats. In the present paper, the authors have made a systematic study on why android security is important, what some of the potential vulnerabilities are and what security measures have been adopted currently to ensure security. Keywords— Android Security, Botnets, Cryptography, DroidDream, Online banking, Repackaging I. INTRODUCTION TO ANDROID SECURITY A. Some Recent Statistics on Android Security [2] Since the first quarter of 2011, Google’s mobile operating system, Android, has steadily increased its share of the global smart phone OS market and by the end of that year it had already crossed the 50 percent market share threshold. As of the fourth quarter of 2014, Android leads the global market with a 76 percent market share, while Apple’s iOS is second. Android is also the most often used operating system for tablet computers worldwide, with a 64 percent share of the global market. One of the reasons for the success of Google’s OS is the constant improvement of its many versions, with every new one offering more advanced features, faster access to the internet or increasingly better video and audio. The first commercial version, named simply Android 1.0, was released in September 2008, followed by the Android 1.1 update, released in February 2009. In April of the same year, Google launched the confectionery-themed collection, where every new version of its mobile operating system is named after a dessert. The first of these new versions was called Cupcake and displayed many new features, such the ability to copy and paste text in web browsers and the ability to upload videos to videosharing website YouTube. The following Android versions released by Google in alphabetical order were called Donut (September 2009), Éclair (October 2009), Froyo (May 2010), Gingerbread (December 2010), Honeycomb (February 2011), Ice Cream Sandwich (October 2011), Jelly Bean (June 2012), KitKat (September 2013) and Lollipop (June 2014). As of October 2014, the Android version with the highest market share is Kit Kat.Another reason for the Android’s popularity is its strong collaboration with mobile devices manufacturers, while its main global competitor, Apple’s iOS, is limited to operating only on Apple devices, such as the iPhone, iPad or Apple Watch. In 2009, around four percent of new smart phones sold to end users around the world had Android as its operating system, while, as of 2015, more than 82 percent of new smart phones were Android-operated devices.

Fig. 1 Graph showing use of Android (Source: www.android.stackexhange.com) __________________________________________________________________________________________________ IJIRAE: Impact Factor Value – SJIF: Innospace, Morocco (2015): 3.361 | PIF: 2.469 | Jour Info: 4.085 | Index Copernicus 2014 = 6.57 © 2014- 16, IJIRAE- All Rights Reserved Page -62

International Journal of Innovative Research in Advanced Engineering (IJIRAE) ISSN: 2349-2763 Issue 03, Volume 3 (March 2016) www.ijirae.com In Fig. 1, we can see a distribution of Android platform versions used by Android Smartphone owners in October 2015. The figures are based on the number of Android devices that have accessed the Google Play Store within a 7-day period ending on October 5th, 2015. B. Some Recent Statistics on Android Malware Threats From the above statistics, it is very clear that Android finds a special place in the hearts of the smart-phone users and its popularity is much more than any other smart-phone operating system which is currently in the market. The reason for the rise of Android is choice – consumers are able to choose from a broad range of manufacturers and price levels as opposed to Apple’s mono-device approach [1]. But fraudsters have all the tools they need to effectively turn mobile malware threats into one of the biggest security problems we’ve ever seen. As security measures lag and infection rates rise, cybercriminals use an increasingly wide array of schemes to monetize mobile malware [3]. Mobile malware remains a significant cyber-security threat, with 1.12 percent of mobile devices monitored by IBM Trusteer in the first half of 2015 exhibiting an active malware infection. This is equal to PC infection rates, signifying that cybercriminals are shifting their resources and attention to the mobile channel. Unsurprisingly, financial Trojans were the most prevalent form of mobile malware, with approximately 30 percent of the distinct variants targeted at stealing financial information. The remainders are capable of performing malicious actions such as stealing personal information, sending SMS to premium numbers, key-logging and deploying cryptographic ransom-ware on the device, effectively hijacking images and files stored on it.

Fig. 2 Graph showing mobile malware (Source: www.gdata-software.com) C. Threats Mobile malware threats form a rich ecosystem, and some of the most prolific mobile Trojans also act as distribution mechanisms for more targeted infections. For example, the DroidDream malware, which was the fifth-most prolific mobile malware, establishes a unique identification for the device and awaits further instruction from its operator, running in the background without the user’s knowledge. The operator can then instruct the malware to download additional malicious programs as well as open the phone up to remote control to allow for more targeted attacks, all without the user ever being aware. In another example, the third-most prolific mobile malware, AndroidExploit Masterkey, modifies Android application packages (APKs), the file format used to distribute and install applications onto Android OS. This effectively allows a hacker to turn any legitimate application into a malicious Trojan. Consumer awareness of mobile security threats still lags behind the reality of the situation. Users who would never install software from an unverified source on their PC readily click on links in SMS messages and unwittingly download files from unknown sources on their mobile devices. As a result, SMiShing (SMS phishing) campaigns designed to distribute mobile malware are exponentially more effective then email phishing, especially when customized to target the client base of a specific financial institution or service provider. Users are also notoriously slow to update their mobile devices’ OS. It is therefore no surprise that mobile malware commonly observed in attacks on consumers, such as the Basebridge Trojan, exploit vulnerabilities in outdated mobile systems.Worst yet, a significant segment of mobile users actually take steps to jailbreak or root their devices in order to access unofficial app markets or get free programs. __________________________________________________________________________________________________ IJIRAE: Impact Factor Value – SJIF: Innospace, Morocco (2015): 3.361 | PIF: 2.469 | Jour Info: 4.085 | Index Copernicus 2014 = 6.57 © 2014- 16, IJIRAE- All Rights Reserved Page -63

International Journal of Innovative Research in Advanced Engineering (IJIRAE) ISSN: 2349-2763 Issue 03, Volume 3 (March 2016) www.ijirae.com In doing so, they not only annihilate their phone’s built-in security, but also drastically increase the risk of downloading a malicious app. In fact, according to recent reports, up to 32 percent of apps on unofficial markets contain malicious content. According to a recent document published by MacAfee in November 2015, the following new malware threats have been reported: i) A new breed of file-less malware, which evades detection by hiding in the Microsoft Windows registry and deleting all traces of its infection from the file system. File-less malware evades detection by reducing or eliminating the storage of binaries on disk. The newest file-less malware leaves no trace on disk, making detection more difficult. ii) Some mobile app developers fail to follow the security guidance of their back-end service providers, potentially exposing customers’ information to attacks. Both legitimate mobile apps and apps that carry malware often have weak back-end security. iii) Macro malware has returned after a long hiatus. Successful campaigns deliver clever new macro malware through documents attached to sophisticated spam. The macros remain hidden even after they have downloaded their payloads

Fig. 3 Android Architecture (Source: www.elinux.org) II. ANDROID AND ANDROID SECURITY The functional and security requirements of almost all mobile operating systems are quite different than their desktop counterparts. Most often, the mobile platforms contain strongly interconnected, small and less-well controlled applications from various single developers as opposed to desktops and server platforms which mostly contain software from trusted sources. Moreover, on non-mobile platforms, the users have full access to the administrative controls whereas on mobile platforms, such access is restricted. Hence, various approaches are used by the android platform in order to enforce security. A. Android Platform The android operating system is shown in the Fig.3 given above. Android is an open source OS that is built on the Linux kernel. It provides an environment for multiple applications to run simultaneously. All these applications are signed and put into application sandboxes which are associated with their application signature. The application sandboxes are the privileges available to the application. Applications are generally built using Android Runtime and interact with the OS through a framework that describes system services, platform Application Programming Interfaces (APIs), and message formats. Other high-level languages (for example, JavaScript) and lower-level languages (for example, ARM assembly) are allowed and operate within the same application sandbox. System services are implemented as applications and are constrained by an application sandbox. Above the kernel, there’s no concept of a super user or root that has unconstrained access to the system. The android apps are created using Java and executed in a virtual machine called Dalvik VM. They are supported by the application framework, which provides frequently used functionality through a unified interface. There are various libraries which enable the apps to implement graphics, encrypted communication or databases easily. The Standard Library (“bionic”) is a BSDderived libc for embedded devices. The respective Android releases’kernels are stripped down from Linux 2.6 versions. Basic services such as memory, process and user management are all provided by the Linux kernel in a mostly unmodified form [4]. __________________________________________________________________________________________________ IJIRAE: Impact Factor Value – SJIF: Innospace, Morocco (2015): 3.361 | PIF: 2.469 | Jour Info: 4.085 | Index Copernicus 2014 = 6.57 © 2014- 16, IJIRAE- All Rights Reserved Page -64

International Journal of Innovative Research in Advanced Engineering (IJIRAE) ISSN: 2349-2763 Issue 03, Volume 3 (March 2016) www.ijirae.com B. File System and Permissions The basic access control is implemented using a 3-level permission model just like in any other Unix or Linux-like system. There are three classes of users-owner, group and other. Permissions to read, write or execute can be set for each of these three classes separately. In traditional desktops and servers, processes share the same group or even the user ID (of the user who started the program). Hence access is granted to all the files that are belonging to other programs but started by the same user. This might be sufficient in traditional systems where the applications mostly come from trusted sources but for mobile operating systems, this is insufficient. We need a finer permission distinction since an open app market is not a strongly monitored and trustworthy software source. In the traditional approach, any app executed under the device owner’s user ID would be able to access any other app’s data. Hence, a distinct user ID is assigned to each app on its installation which makes sure that an app can only access its own files the temporary directory and nothing else – system resources are available through API calls. This establishes a permission-based file system sandbox. C. Android API Permission Model Whenever an app is installed on any mobile, the user is shown a complete list of all the permissions that the app requires to function on the mobile. All such permission requests are defined in the Manifest File called AndroidManifest.xml. The AndroidManifest.xml file is the control file that tells the system what to do with all the top-level components (specifically activities, services, broadcast receivers, and content providers described below) in an application. This also specifies which permissions are required. However, this system has a few flaws: i)

ii)

There is no choice to grant certain privileges/permissions while holding back the others. Hence, the user generally grants all the permissions required to run the app. These might include some permissions which might not be required at all. The figure given below shows such permissions. In many cases, it is not possible for the users to judge which permission is required and which is not. More often than not, the users just breeze through the permissions and pay no attention to them.

Fig. 4 Android Permissions (Source: www.androidcentral.com) D. Android Market (“Google Play”) Google Play which was formerly called the Android Market is the digital distribution platform for applications for Android devices. When android users download the various apps from the Google Play, most of the time they do not pay attention to the extent of permissions an application can have on their phone. Google Play is itself one of the sources of potential security risks. The users unaware of this fact just accept all the permissions during installations and mostly a major number of these applications ask for more permissions than they actually require to get installed. __________________________________________________________________________________________________ IJIRAE: Impact Factor Value – SJIF: Innospace, Morocco (2015): 3.361 | PIF: 2.469 | Jour Info: 4.085 | Index Copernicus 2014 = 6.57 © 2014- 16, IJIRAE- All Rights Reserved Page -65

International Journal of Innovative Research in Advanced Engineering (IJIRAE) ISSN: 2349-2763 Issue 03, Volume 3 (March 2016) www.ijirae.com The Google Play is not a well-policed environment and hence there is a high probability that the applications here may contain a very high percentage of malware than the apps from any other app store. These security vulnerabilities are not only causing minor inconveniences but also affecting actual performance issues and data loss in the Android devices. Most of the malware is distributed through the free, illegitimate copies of paid apps. Users who want to use such apps but do not want to make any payment for the same often turn to pirated copies of such apps. These copies are often altered to deliver malicious code. This process is known as repackaging of apps. Repackaging is a very common tactic, in which a malware writer takes a legitimate application, modifies it to include malicious code, then republishes it to an app market or download site. The repackaging technique is highly effective because it is often difficult for users to tell the difference between a legitimate app and its repackaged doppelganger. In fact, repackaging was the most prevalent type of social engineering attack used by Android malware writers in the first two quarters of 2011. The types of applications most frequently repackaged with malware include games, utilities, and porn apps. For example, DroidDreamLight was originally found in 20 utilities, 9 porn and 5 game apps in the Android Market. Some examples of the types of apps that were repackaged with malware are:

TYPE OF APP GAMING

UTILITY

TABLE I EXAMPLES OF REPACKAGED APPS NAME OF APP BUBBLEBUSTER

SPIDERMAN CHESS BATTERY SAVER SCIENTIFIC CALCULATOR

REPACKAGED WITH DROIDDREAM LITE DROIDDREAM DROIDDREAM GGTRACKER DROIDDREAM LITE

Repackaged apps containing malware create a crisis of trust. To the naked eye, a legitimate app and a repackaged version often look the same with the exception of their permissions. Apps repackaged with malware typically, though not always, require a greater set of permissions than the original app. In some cases, malware writers will pirate paid applications and make them available for free, injecting malware into the pirated version. The illustration in the diagram details an example of the process used by malware writers to take legitimate apps from the Android Market, repackage them with malware, and introduce the repackaged versions into third party app stores.

Fig. 5 Repackaging (Source: www.fireeye.com) III. ANDROID AND ANDROID SECURITY A. Privacy Issues and Loss of Data Now-a-days mobiles are used in almost all online transactions, be it banking services or shopping. The tasks which we would typically accomplish using a desktop are now being accomplished using the mobile phone. All such applications tend to concentrate all out private data in one device. Since android is an open source platform and provides limited administrative control over a device, the private data are at risk of being stolen. The central Android logging service is a very exhaustive bank containing all our personal information. There are many apps which write status messages to the logging services. These messages contain parameters which disclose the personal details of the owners. For example, several GPS-based apps have been found to write the device’s geo-coordinates to the logging service in regular intervals. This gives away all the information on the device owner’s movements to other apps installed. Some apps log web requests or other network communication. Thus, by only reading log files, much sensitive information can be gathered, depending on the apps installed and their behavior regarding logging. __________________________________________________________________________________________________ IJIRAE: Impact Factor Value – SJIF: Innospace, Morocco (2015): 3.361 | PIF: 2.469 | Jour Info: 4.085 | Index Copernicus 2014 = 6.57 © 2014- 16, IJIRAE- All Rights Reserved Page -66

International Journal of Innovative Research in Advanced Engineering (IJIRAE) ISSN: 2349-2763 Issue 03, Volume 3 (March 2016) www.ijirae.com B. Online Banking The online banking system depend heavily on the mTAN method for the authentication of the transaction in question. mTAN stands for Mobile Transaction Authentication Number. Whenever a user initiates a transaction, the bank generates a TAN and sends it to the user’s mobile via SMS. This SMS may also include transaction data, allowing the user to verify that the transaction has not been modified in transmission to the bank. However, this method poses serious security threats. Under a threat named as SIM Swap Fraud, an attacker may impersonate a victim and obtain a new SIM card from the operator for the victim’s phone. The username and password may be obtained by keylogging or phishing. In this way, it is possible for the attacker to transfer the victim’s money to his own account.

Fig. 6 Bypassing Online Security for Online Banking (Source: www.safensoft.com) C. Mobile Botnets The word “Bot” is the short form of “robot.” Malicious software or malware is being distributed using mail, chat, apps, etc. that can turn our device into Bots (also referred as Zombie or web robots). Once this malware is installed, our device can perform automated tasks over the Internet, without us knowing it. Cybercriminals who control these bots are called “botmasters” or “Botherders”. These infected devices create networks called “Botnets” by sending messages from your contact list, and then infecting all those users who click or tap on the link. Bots often spread themselves across the Internet by searching for unprotected or vulnerable devices and then report back to its master. Their goal is to keep themselves hidden until instructed to carry out any tasks. A botnet targets mobile devices such as smartphones, attempting to gain complete access to the device and its contents as well as providing control to the botnet creator. Mobile botnets take advantage of unpatched exploits to provide hackers with root permissions over the compromised mobile device, enabling hackers to send e-mail or text messages, make phone calls, access contacts and photos, and more. Most mobile botnets go undetected and are able to spread by sending copies of themselves from compromised devices to other devices via text messages or e-mail messages [6].

Fig. 7 Botnets (Source: www.mportal.com) __________________________________________________________________________________________________ IJIRAE: Impact Factor Value – SJIF: Innospace, Morocco (2015): 3.361 | PIF: 2.469 | Jour Info: 4.085 | Index Copernicus 2014 = 6.57 © 2014- 16, IJIRAE- All Rights Reserved Page -67

International Journal of Innovative Research in Advanced Engineering (IJIRAE) ISSN: 2349-2763 Issue 03, Volume 3 (March 2016) www.ijirae.com IV. SECURITY GLITCHES Several security glitches have been discovered in the various elements of the Android Operating System. Until now, they have fundamentally served to permit device owners management benefits on their devices. Lately malware authors have started employing such glitches and publicly obtainable exploits for malicious code. A. Native Executable Code  All contemporary exploit based attacks dependon the potential to implement native code. It is the most important constraint for attacks which allow an attacker to possess full power over a device.  Limitations of the benefit to set the executable bit for files would notably decrease exploitability of Android devices. Consequently, apps would no longer be able to download and implement native binaries potently. B. Public Exploits As some exploits are based on consents available to only the shell user, these can’t be used for in app privilege upsurge to attain root access. Up till now, they are just used for providing users total administrative access. But, as these exploits can be implemented by the shell user with the use of the Android Debug Bridge, they can be utilized for device to device or PC based infection. The table below mentions all popular known exploits, their CVE (Common Vulnerabilities and Exploitability) number and infected Android versions: TABLE II ANDROID EXPLOITS

VULNERABLE ANDROID VERSIONS < 2.2

2.1, 2.2, 2.3

Suggest Documents