Evidently there has been a large and sustained growth of Android use in Asia in recent times. With the increasing popularity of Android comes the danger of malware attacks. Studies on Android mobile security reveal that the growth rate of Android threats is at a faster pace than that for computer malware at the development stage.
Given the fact that the Android business model allows users to download new applications from the internet, no doubt social engineering will play a major role in propagating malware. Thus far, most of the identified Android threats avail of this simple route to reach a victim’s device, then obtain the user’s permission to get installed, and finally make use of the potential flaws in the Android security model to send out confidential data. The consistent increase in the number of threats suggests that it is high time that users are made aware of the possible ways in which their device could be compromised for them to safeguard against attacks. In addition, it is necessary that users be made aware of the current Android threat landscape to help identify and isolate the applications that could contain malicious code.
This paper will discuss the Android Security Model, and hopes to present a detailed account of the nature of the Android threat landscape so that users in Asia and elsewhere are made aware of the dangers involved in the use of Android, whilst also focussing on the ways and means of mitigating the risk.
Nurturing a Behemoth
The year is 2008. Android, the mobile operating system developed by Google, gains in popularity amidst other leading mobile platforms like iPhone OS, Symbian or Windows Mobile, because of its open source status. The success of Android mobiles will be a chain reaction, feeding on its own popularity, since people would prefer cost-effective devices with smartphone-like features rather than costly mobiles with a load of gimmicks.
Unlike Windows Mobile, iOS and Blackberry that have a limited number of applications and strict copyright policy, Android users have the choice of many applications. In other words, the openness in the Android application development environment, allows the application developers and handset manufacturers to develop customized applications which suit customer requirements. This also paves the way for new business opportunities for Android application developers.
The Android operating system is incorporated with the Dalvik VM , mainly for the reason that applications can run even on low-end mobile models with minimal memory usage. This stands as yet another advantageous feature of the Android platform as it overcomes the complaint of high memory usage, which results in application slow down, reported by the users of other high-end mobile platforms.
Given the above characteristics, Asian users are migrating to Android phones at a phenomenal pace, and Google’s plans to capture the smartphone market in Asia are succeeding. However, this increasing popularity provides hackers and malware authors an irresistible opportunity for exploitation and financial gain, and the number of Android mobile malware in the wild has grown at a very high rate, despite Android’s seemingly adequate security features.
Hark! Who Goes There?
Android was developed with the idea of delivering a cost effective smartphone with almost all of the features of a ‘real computer’. The above idea is greatly facilitated by allowing users to install applications of their choice. Unlike Apple or other smartphone markets, Android users are not restricted to download applications solely from one dedicated, proprietary site, i.e. Google’s Android Marketplace, but are free to obtain programs from different marketplaces. This idea of an open market exposes the user to a higher security risk, however Google has incorporated certain security features to protect users from malware attacks, with a negligible compromise on performance or flexibility.
With the target of security, Android isolates applications installed on the device from each other at the system level by assigning each application, and its dedicated process, a unique user identity that is visible only to the system. 
Whenever an installed Android application or one of its components is called to perform an action, the Linux kernel identifies the application by its assigned user ID and starts the corresponding process in its own sandbox. No two processes can generally run with the same user ID, i.e. within the same process space. This helps to protect the applications from intrusion by any other applications. If the same user ID needs to be shared by two applications, it can be done at install time, provided both the applications have the same certificate. Note, Google allows application developers to upload self-signed applications to the marketplace, i.e. the programs do not necessarily have to be signed by an independent certificate authority. The point made by the certificate concept is to distinguish the application author, and a formal registration process is in place.
The security enforcement of the Android OS is further strengthened with the concept of Capabilities of the components. Applications have a manifest file which defines the API levels that they need, and most importantly, the Capabilities, in other words the Access Permissions over and above the default level for the Dalvik VM, for each of the applications’ components to access device data. An application’s or component’s Capabilities to access another application’s components or the device data are declared statically at install time, perhaps requiring explicit user consent, and they cannot be changed dynamically. Inter-application communication happens only if the requesting application, the caller, has the authorized Capabilities with respect to the callee application.
In the above figure, Application 1 with Capabilities X is authorized to access a component of Application 2, and Application 2 with Capability Y is authorized to access a component of Application 3. Application 3 does not have the Capabilities to access the components of Application 1 or Application 2. All 3 applications run within their own Dalvik VMs and their access permissions are enforced by the Android OS.
Please Sir, Can I have MORE?
Since inter-component communication is really based on the Capabilities of the applications, and these Capabilities may require explicit user consent, malware applications can pretend to be legitimate and entice users into granting permissions to access sensitive areas such as the device or user data, the network, etc. Access permissions have to be requested and granted at install time itself. These malicious applications have to take advantage of social engineering techniques to receive the desired Capabilities to accomplish their tasks.
Hackers are able to enter the Android Marketplace by using the fact that applications can be self-signed, as mentioned earlier. Hackers upload self-signed malicious application to the market bundled with legitimate applications. For instance, the Android malware Nickispy is actually supposed to be part of an alarm receiver but it gains access from the user to make or cancel a call, send out SMS to the numbers in the contacts list, and other actions, by requesting permissions through its manifest file. Let us have a look at Nickispy’s manifest file:
Nickispy, a supposed simple Alarm Receiver application requests the below listed permissions from the user as shown in the figure below:
In fact Nickispy sends out data without the user’s knowledge.
Images courtesy of:
www.vetmed.vt.edu
neworganizing.com
canstockphoto.com
V.Dhanalakshmi
Malware Analyst, K7TCL
If you wish to subscribe to our blog, please add the URL provided below to your blog reader:
https://labs.k7computing.com/feed/
