a comprehensive study on security issues in android mobile phone — scope and challenges

International Journal of Innovative Research in Advanced Engineering (IJIRAE) ISSN: 2349-2763 Issue 03, Volume 3 (March 2016) www.ijirae.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

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

Shubham Chatterjee* Kasturi Paul Reek Roy AsokeNath Dept. Computer Science Dept. of Computer Science Dept. of Computer Science Dept. of Computer Science St. Xavier’s College St. Xavier’s College St. Xavier’s College St. Xavier’s College (Autonomous) (Autonomous) (Autonomous) (Autonomous) Kolkata, India Kolkata, India Kolkata, India 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 video-sharing 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)




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.




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].




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) 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.

ii) 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.




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:

TABLE I

EXAMPLES OF REPACKAGED APPS TYPE OF APP NAME OF APP REPACKAGED WITH

GAMING BUBBLEBUSTER DROIDDREAM LITE SPIDERMAN DROIDDREAM

CHESS DROIDDREAM UTILITY BATTERY SAVER GGTRACKER

SCIENTIFIC CALCULATOR 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.




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)




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 NAME DESCRIPTION CVE

< 2.2 USE-AFTER-FREE WEBKIT VULNERABILITY

Remote arbitrary code execution through NaN handling because of lacking floating point number validation

CVE-2010-1807

2.1, 2.2, 2.3 FOCUS STEALING VULNERABILITY

Any app may thieve another app’s focus and display its own Activity windows above the other app’s, thus making it impossible for any user to determine that this Activity initiates from another app. This allows for displaying login dialogs for stealing user qualifications.

TWSL2011-008

<=2.1 EXPLOID Hotplug Exploit, usable for malware

CVE-2009-1185

2.2.0, SOME 2.2.1/2.2.2 RAGEAGAINSTTHECAGE, ZIMPERLICH

RLIMIT_NPROC exhaustion, causing dropping privileges through suid() to fail because suid() cannot be called anymore – Zimperlich usable for malware

CVE-2010-EASY (NO OFFICIAL CVE)

<= 2.2.3, 2.3.[0–3], 3.0 GINGERBREAK mPartMinors[] (NPARTS) out of bounds write – can be used for malware

CVE-2011-1823

<=2.2.2 PSNEUTER, KILLINGINTHENAMEOF

Neuters the Android property Service, which is checked by adb when starting up to determine whether it should run as root or with low privileges.Variant “KillingMeSoftly”usable for malware.

CVE-2011-1149

2.2, 2.3 ZERGRUSH libsysutils root exploit useafterfree, not usable for inapp malware

CVE-2011-3874

4.0.[0–3] MEMPODROID Unauthorized write access to other processes’ memory; not usable for inapp malware: adb access required for exploitation

CVE-2012-0056

C. Android permission Model

The requests formally made by any app at the time of installation through its apparent file do not have to be the same to those actually made use of. Thus it is entirely impossible for any user to find out what activities an app performs with its requested permissions. Some examples of actions that can be carried out without the proper permissions are: RECEIVE_BOOT_COMPLETED, START_ON_INSTALL etc.




These types of permissions, if not formally requested and given to the user, remarkably eases out malware infection and concealment. Any app on the Android market may serve as downloader and installer for any other infectious app. This quality requires only few lines of code.

D. Zero Permission URI Handler Remote Shell

A recently found approach doesn’t require any exploit code to be implemented on a target device. Instead, it merges Android API characteristics to install a remote shell on an Android device. Interaction between any Android Device and a host acting as command and control server is attained through web

browsers. Any Android app may launch default web browser and direct it to any URL by using Intent. URLs may also include GET parameters, which are utilized to transfer data from an Android device to a web server.

If the consent to access the Internet has been accorded to any app on installation, it doesn’t need to wait for the display to switch off. Alternatively, it can redeem a URL in the background invisibly.

To attain both-way communication, the command and control server’s webpage, which an Android device calls, will consist of a redirect command to a URI of the narrated format. By sending this browser to the URI by itself, it gets transferred on to the malicious app. Hence, a full remote shell can be executed without any benefits required. Any valid app can hide it as a standalone app without the device users being able to identify it.

E. Google Services Authentication Token

Researchers from Ulm University discovered a data leakage related attack vector of high importance for all Android users of versions less than 2.3.4. The default Google Calendar Sync and Contacts Sync apps transmit Client Login authentication tokens unencrypted. Any Google service can be logged into by these authentication tokens under the authentication user’s identity and have validity of several days.[2]

Many rogue wireless network access points can simply intrude for such authentication tokens to imitate the actual user. Henceforth, all information stored on Google services can be attained, which contain details like phone numbers, home/email addresses, calendar data etc. Google has supplied patches for every version of the previously mentioned basic apps.

Fig. 9 Threats with Google (Source: www.ghacks.net)

F. Exploit Execution Framework

For the testing of present and future exploits in the controlled environment, an extensible client side architecture was developed for exploit implementation and privilege upsurge. This framework also analyzes exploitability of devices with certain test sets and payloads in a partially automatic condition. Its execution is a multi-level procedure: On startup, an arrangement file is brought from a remote server. The framework app extracts data from this arrangement file on which exploit to implement to increase its advantages and which payload to execute later on.




By this way, simpler extensibility of the configuration is attained. No source code alterations are needed as program nature is potently discovered through the configuration file.

After the configuration file has been loaded and parsed, an exploit binary acceptable for the device will be downloaded and executed. Upon successful completion, the exploit is provided with a payload to execute root privileges. This payload is again determined by the arrangement file and can be a shell script/ binary/ app installation file etc.

Through its dynamic exploit download and privilege surging behaviour, which is also positioned in real world malware, recognition procedures and mobile signature based antivirus software can be avoided. To avoid recognition before issuing to the Android Market, exploits will only be supplied once the framework, or similarly malware, has passed testing and provided to its users

V. SECURITY MEASURES

A. Use of Cryptography in data protection Cryptography is used extensively in Android in order to protect data from possible threats. Most the prevalent algorithms are used and adopted to ensure security of the device. The major uses of cryptography on the android device are:

1) Device Encryption: Encryption is the process of converting data into an unreadable format that is reversible with the use of a security key or password. There are three parts to encryption: restricted and confidential data to protect, an encryption cipher or algorithm and an encryption key. We have sensitive data to protect so encryption software uses an approved encryption algorithm to "scramble" the data and make it unreadable. The data is stored or transmitted and when someone needs to view the data they use the key or password to "unscramble" or decrypt it [7]. Android disk encryption is based on dm-crypt, which is a kernel feature that works at the block device layer. The encryption algorithm is 128 Advanced Encryption Standard (AES) with cipher-block chaining (CBC) and ESSIV: SHA256. The master key is encrypted with 128-bit AES via calls to the Android OpenSSL library. OEMs can use 128-bit or higher to encrypt the master key [5].

2) KeyChain and KeyStore [5][8]

Several APIs which implement the common cryptographic algorithms have been provided by the android. Some of the algorithms that have been implemented are AES, Rivest-Shamir-Adleman (RSA), Digital Signature Algorithm (DSA), and Secure Hash Algorithm (SHA). Moreover, APIs are provided for higher-level protocols, such as Secure Socket Layer (SSL) and HTTPS. The KeyChain class was introduced in Android 4.0. It allows applications to use the system credential storage for private keys and certificate chains. The KeyChain API is used for Wi-Fi and Virtual Private Network (VPN) certificates.

Applications accessing the KeyChain normally go through these steps:

1. Receive a callback from an X509KeyManager that a private key is requested. 2. Call choosePrivateKeyAlias to allow the user to select from a list of currently available private keys and

corresponding certificate chains. The chosen alias will be returned by the callback alias(String), or null if no private key is available or the user cancels the request.

3. Call getPrivateKey(Context, String) and getCertificateChain(Context, String) to retrieve the credentials to return to the corresponding X509KeyManager callbacks.

An application may remember the value of a selected alias to avoid prompting the user with choosePrivateKeyAlias on subsequent connections. If the alias is no longer valid, null will be returned on lookups using that value. An application can request the installation of private keys and certificates via the Intent provided by createInstallIntent(). Private keys installed via this Intent will be accessible via choosePrivateKeyAlias(Activity, KeyChainAliasCallback, String[], Principal[], Uri, String) while Certificate Authority (CA) certificates will be trusted by all applications through the default X509TrustManager.

The Android KeyStore class allows us to store private keys in a container to make it more difficult to extract from the device. It was introduced in Android 4.3 and focuses on applications storing credentials used for authentication, encryption, or signing purposes. KeyStore is responsible for maintaining cryptographic keys and their owners.

B. Application Security

1) Application Sandbox and permissions [5][9][10]

Android has another layer of protection in that it doesn’t give one app access to the resource of another app. This is known as the ‘sandbox’ where every app gets to play in its own sandbox and can’t use another app’s permissions.




Application sandboxing, also called application containerization, is an approach to software development and mobile application management (MAM) that limits the environments in which certain code can execute. The goal of sandboxing is to improve security by isolating an application to prevent outside malware, intruders, system resources or other applications from interacting with the protected app. The term sandboxing comes from the idea of a child's sandbox, in which the sand and toys are kept inside a small container or walled area. Developers that don't want an application to be touched by outside influences can wrap security policies around an app or isolate each application in its own virtual machine, an approach known as micro-virtualization. Android does this by giving each app a unique user id (a UID) and by running that app as a separate process with that UID. Only processes with the same UIDs can share resources, which, as each ID is uniquely assigned, mean that no other apps have permission. This means that if an app tries to do something it should not, like read the data from another app, or dial the phone (which is a separate application) then Android protects against this because the app doesn’t have the right privileges.

2) Application Signing [5][8]

Android requires that all apps be digitally signed with a certificate before they can be installed. Android uses this certificate to identify the author of an app, and the certificate does not need to be signed by a certificate authority. Android apps often use self-signed certificates. The app developer holds the certificate's private key. When the system installs an update to an application, it compares the certificate in the new version with those in the existing version, and allows the update if the certificate matches. The apps which are signed by the same certificate are allowed to run in the same process if the process so requests. This allows the system to treat both the apps as the same. Android provides signature-based permissions enforcement, so that an application can expose functionality to another app that’s signed with a specified certificate. By signing multiple apps with the same certificate, and using signature-based permissions, an app can share code and data in a secure manner.

VI. CONCLUSION

According to a new report from Bit9—a security vendor with a focus on defending against advanced persistent threats (APT)—there is a one in four chance that downloading an Android app from the official Google Play market could put us at risk. Bit9 analyzed 400,000 or so apps in Google Play, and found over 100,000 it considers to be on the shady side. The research by Bit9 illustrates some issues with app development in general, and should raise awareness among mobile users to exercise some discretion when downloading and installing apps, but it’s not a sign of any urgent crisis affecting Android apps. We must use discretion rather than blindly granting permissions to apps.

The report from Bit9 isn’t about apps that contain malware, or are even overtly malicious for that matter. Bit9 reviewed the permissions requested by the apps, and examined the security and privacy implications of granting those permissions. The reality is that many apps request permission to access sensitive content they have no actual need for. Bit9 says that 72 percent of all Android apps in the Google Play market request access to at least one potentially risky permission. For example, 42 percent request access to GPS location data, 31 percent want access to phone number and phone call history, and 26 percent ask for permission to access personal information. Bit9 discovered 285 apps that use 25 or more system permissions. In addition to analysing the apps in Google Play, Bit9 also surveyed IT decision managers about the mobile usage and security policies in place. The survey found that 71 percent of organizations allow employee-owned devices to connect to the company network, and 96 percent of those allow employees to access company email from a personal mobile device.

When we combine the two—the number of potentially risky apps, and the access companies grant personal mobile devices—it represents a security concern for organizations. When an employee allows an app to access sensitive information on a mobile device that is connected to the company network or email, it could expose customer, employee, or other company-owned data to the app. Again, it is possible that all of the “offending” apps are legitimate, and that none of them pose any significant security risk. The issue is that apps with access to personal information and sensitive data have the potential to be a security risk—either intentionally or inadvertently—and many apps don’t have a valid need for the access.

ACKNOWLEDGMENT

The authors are very much grateful to Department of Computer Science, St. Xavier’sCollege (Autonomous), Kolkata for doing research work in Computer Science and Engineering. One of the authors Asoke Nath is also grateful to Fr. Dr. John Felix Raj, Principal of St. Xavier’s College (Autonomous), Kolkata for his constant support and encouragement for conducting research work in Computer Science and Information technology




REFERENCES

[1] Ryan Farmer, “A brief guide to android security” [2] http://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices-with-android-os/ [3] Ori Bach, “Mobile Malware Threats in 2015: Fraudsters Are Still Two Steps Ahead”, July 13, 2015

(https://securityintelligence.com/mobile-malware-threats-in-2015-fraudsters-are-still-two-steps-ahead/) [4] Rafael Fedler, Christian Banse, Christoph Krauss and Volker Fusenig, “Android OS Security: Risks and

Limitations: A Practical Evaluation”, Fraunhofer Research Institution for Applied and Integrated Security. [5] Android for Work Security White Paper by Google [6] www.webopedia.com/TERM/mobile_botnet [7] www.security.uwmedicine.org/guidance/techinal [8] www.developer.android.com/android/security [9] www.seacrhmobilecomputing.techtaregt,com [10] www.androidauthority.com/secure-android [11] Tony Bradley, Study finds 25 percent of Android apps to be a security risk(http://www.pcworld.com/article/2013524/study-

finds-25-percent-of-android-apps-to-be-a-security-risk)malware-threats-in-2015-fraudsters-are-still-two-steps-ahead/) [12] Kirandeep, Anu Garg, “Implementing Security on Android Application”, The International Journal Of Engineering

And Science (IJES) , Volume 2, Issue 3, ISSN: 2319 – 1813 ISBN: 2319 – 1805 [13] Tiwari Mohini, Srivastava Ashish Kumar and Gupta Nitesh, “Research Journal of Computer and Information

Technology Sciences”, Volume 1(6), November 2013, ISSN 2320 – 6527 [14] Steffen Liebergeld, Matthias Lange, “Android Security, Pitfalls and LessonsLearned”. [15] Corey Beres, “An Analysis of open security issues of Android interfaces to cloud computing platforms” [16] Rushil Shah, “Analyzing and Dissecting Android Applications for Security defects and Vulnerabilities” [17] Cassandra Beyer, “Mobile Security: A Literature Review”, International Journal of Computer Applications (0975 –

8887) Volume 97– No.8, July 2014 [18] Prajakta S. Deshbhratar, Mayur S. Burange, Android Security –Big Challenge, International Journal of Emerging

Research in Management &Technology ISSN: 2278-9359 (Volume-3, Issue-3) [19] Pravin Kumar Takur, A Growing Cyber Threat: Mobile Botnets, October 25th, 2013 [20] http://www.safensoft.com/Online_Banking_Security/