Smartphone malware evolution revisited: Android next target?

Abstract

Smartphones started being targets for malware in June 2004 while malware count increased steadily until the introduction of a mandatory application signing mechanism for Symbian OS in 2006. From this point on, only few news could be read on this topic. Even despite of new emerging smartphone platforms, e.g. android and iPhone, malware writers seemed to lose interest in writing malware for smartphones giving users an unappropriate feeling of safety. In this paper, we revisit smartphone malware evolution for completing the appearance list until end of 2008. For contributing to smartphone malware research, we continue this list by adding descriptions on possible techniques for creating the first malware(s) for Android platform. Our approach involves usage of undocumented Android functions enabling us to execute native Linux application even on retail Android devices. This can be exploited to create malicious Linux applications and daemons using various methods to attack a device. In this manner, we also show that it is possible to bypass the Android permission system by using native Linux applications.

Full text

Page 1

Smartphone Malware Evolution Revisited: Android Next Target?
Aubrey-Derrick Schmidt, Hans-Gunther Schmidt, Leonid Batyuk,
Jan Hendrik Clausen, Seyit Ahmet Camtepe, and Sahin Albayrak
Technische Universit¨ a Berlin - DAI-Labor
Ernst-Reuter-Platz 7, 10587 Berlin
{aubrey.schmidt, hans-gunther.schmidt, leonid.batyuk,
jan.clausen, ahmet.camtepe, sahin.albayrak}@dai-labor.de
Can Yildizli
Sabanci University, Istanbul,
canyildizli@su.sabanciuniv.edu
Abstract
Smartphones started being targets for malware in June
2004 while malware count increased steadily until the in-
troduction of a mandatory application signing mechanism
for Symbian OS in 2006. From this point on, only few news
could be read on this topic. Even despite of new emerg-
ing smartphone platforms, e.g. Android and iPhone, mal-
ware writers seemed to lose interest in writing malware for
smartphones giving users an inappropriate feeling of safety.
In this paper, we revisit smartphone malware evolution
for completing the appearance list until end of 2008. For
contributing to smartphone malware research, we continue
this list by adding descriptions on possible techniques for
creating the first malware(s) for Androidplatform1. Our ap-
proach involves usage of undocumented Android functions
enabling us to execute native Linux application even on re-
tail Android devices. This can be exploited to create mali-
cious Linux applications and daemons using various meth-
ods to attack a device. In this manner, we also show that it is
possible to bypass the Android permission system by using
native Linux applications.
1Introduction
Smartphones get increasingly popular which also at-
tracted malware writers beginning from June 2004. From
this point on, malware count increased steadily while main
target remained Symbian OS2. After the introduction of ap-
plication signing, the amount of new appearing malware de-
1http://code.google.com/android/
2http://www.symbian.org/index.php
creased while only few news can be read up to today. Even
since new emerging platforms seem to be a valuable tar-
get, e.g. Android and iPhone, only first vulnerabilities were
published but no fully working malwares.
The contribution of this paper is twofold. We start with
revisiting the smartphone evolution starting in June 2004
and enter this evolution by presenting the first running mal-
ware for Android. Our intention is of course not to start a
new wave of emerging malwares for Android, instead, we
want to contribute to current smartphone malware research
by pointing to possible vulnerabilities concerning the An-
droid platform. This is of special interest since this new
platform targets for fully integrating Internet and general
network services to its devices. Attacking this ability and
also the increasing user dependence on these devices can
result in significant denial of service as well as high costs at
user side due to malicious service usage.
This work is structured as follows. In Section 2, we
present related smartphone malware research.
tion 3, we revisit smartphone malware history for showing
what happened up to date in this field. In Section 4, we
give a brief introduction to the Android platform followed
by Android-specific software engineering aspects that are
needed in order to create malware. In Section 5, we de-
scribe how to exploit the aforementioned techniques in or-
der to create Android malware. In Section 6, we conclude.
In Sec-
2Related Work
Since our work lies in the field of smartphone malware,
several related papers can be identified. Starting with the
first wave of Symbian OS malwares, several authors pointed
to the “new” threat targeting smartphones, e.g. Dagon et

Page 2

Smartphone Malware Evolution
0
50
100
150
200
250
300
350
400
450
1 2 3 4 5 6 7 8 910 11 121 2 3 4 5 6 7 8 910 11 121 2 3 4 5 6 7 8 910 11 121 2 3 4 5 6 7 8 910 11 121 2 3 4 5 6 7 8 910 11 12
200420052006
Time
20072008
Count
New Malware
Total Count
F-Secure Data
Figure 1: Mobile malware evolution basing on published malware including descriptions on their behavior. F-Secure data
was added for comparison.
al. [7], Jamaluddin et al. [12], Piercy [21], Niemel¨ a [20],
Leavitt [14], and Hypponen [11].
Overviews on smartphone malware appearance were
given by T¨ oyssy et al. [26], Gostev [9, 10], Fleizach et al.
[8], Lawton [13], Schmidt et al. [23], and Shih et al. [24]
while most of them end in 2005 or 2006. In this work, we
update these overviews by extending the list of appearances
to the end of 2008 while practically adding a new entry for
the beginning of 2009.
Android, but also iPhone malware propagation is still a
basically not investigated field of research. Since both plat-
forms mainly use a online store for distributing software,
metrics have to be found for predicting or simulating mal-
ware propagation. Valuable input is given by Mickens et al.
[15], Bulygin [6], and Wang et al. [27], who give interesting
insights into propagation models and estimations.
The possibility of attacking smartphones was investi-
gated by several researchers where especially the contin-
uous work of Mulliner et al. 2006 [16, 19, 17, 18] has to
be noted since essential work concerning Windows Mobile
and Symbian OS was presented. Related work was also
published by Racic et al. [22] who used MMS in order to
deplete the battery of mobile phones. Becher et al. [5] pre-
sented a promising approach for creating a worm for Win-
dows Mobile. Unfortunately, they were lacking the appro-
priate exploit for making a fully working malware. Jesse
D’Aguanno3gives detailed information on how to attack
RIM Blackberry supporting networks4.
3presented as speaker with the pseudonym “x30n”
4proof-of-concept at
presentations/blackjack.html
http://www.praetoriang.net/
3 Revisiting Smartphone Malware Evolution
Initial work on showing smartphone malware evolution
was published by Gostev [9] from Kaspersky Lab. Key re-
sults for the time span from June 2004 until August 2006
were that smartphone got an increasingly popular target for
attackers where mainly Symbian OS malwares appeared.
Our paper extends this work from a perspective not hav-
ing the same access to malware databases as most anti-virus
product vendors have. We noticed a great discrepancy be-
tween published malwares and corresponding available de-
scriptions on their behaviors. Especially in the last two
years, descriptions on the behaviors got scarce without ob-
vious reason.
For statistical purpose, we gathered all published mal-
ware descriptions5from various web pages, e.g. from F-
Secure, Kaspersky, McAfee, Symantec, Sophos, and sim-
ilar, for identifying key aspects of mobile malware. One
obvious aspect is their appearance in time. Figure 1 shows
mobile malware evolution from January 2004 to Decem-
ber 2008 based on published mobile malware with avail-
able behavior description. We found 288 smartphone mal-
wares until end of 2008 where peeks in new appearing mal-
ware can be found at the end of 2005 and in the middle of
2006. It is probable that these peeks were caused by the
introduction of a certificate-based signing of application for
Symbian OS6where malware writers might have feared a
decreasing number of possible victims. In the signing pro-
cess, a trusted Symbian partner checks the complete source
code and binaries for meeting certain criteria, like being
free from memory leaks and abusive methods. If the check
is successful, the application gets signed with an certificate
5malwares lacking descriptions were ignored
6http://www.symbiansigned.com

Page 3

Smartphone Malware Effects
174
143
114
5050
39
12
11
8
111
0
20
40
60
80
100
120
140
160
180
200
Manipulates files
Disables Applications
Drops
None
Disables Device
Targets Memory Card
Abuses Messaging
Accesses Private Information
Transmits Private Information
Infects Memory Card
Manipulates Private Data
Backdoor
Count
Figure 2: Smartphone malware effects
andstaysclearlyidentifiablethroughagivenuniqueID.Ad-
ditionally, signing restricts access to sensitive function calls
from certain APIs, e.g. network control, preventing abusive
usage of these. Application signing gets mandatory for the
current Symbian S60 3rd Version which is installed on most
Nokia smartphones since the end of 2005.
For comparison, we requested the corresponding num-
bers from F-Secure Research in Helsinki7. Comparing the
numbers from Figure 1, you can see that F-Secure counted
418 malwares, 130 more than we found, showing that there
are several malwares without publicly available descrip-
tions. Additionally, following the F-Secure numbers, in the
middle of 2006 more than 100 new malwares appeared.
Based on published malware descriptions, we listed the
malware effects which can be seen on Figure 2. Please note
that the categories are not disjunct, therefore the count of
malware having certain effects exceeds our total count of
288 malwares. Several different malicious behaviors were
recognized while more than half of the malwares manip-
ulated files for achieving application or device disabling.
Another interesting point is that 50 malwares did not have a
malicious behavior except their propagating functionality.
Smartphone malware uses various channels for infecting
new devices. What most malwares, especially for Symbian
OS, have in common is that they require an installation file
for propagation. Additionally, Bluetooth and MMS were
used for propagating these malwares which can be seen on
Figure 3.
All malwares basing on (Symbian OS) installation files
explicitly need user interaction for installing on the system.
Therefore, most smartphone malwares are categorized as
“Trojan horses” (84%), see Figure 4. Even worms (15%)
7We want to kindly thank Jarno Niemela for providing us these infor-
mation
Appeared Malware Categories
Trojan Horse
84%
Worm
15%
Virus
1%
Malware by Plattform
Symbian OS;
278
Windows M.; 4
Palm; 4
J2ME; 2
Figure 4: Left: appeared malware categories, right: mal-
ware per platform
need user interactions in order to get installed. Hence, prop-
agation schemes cannot be compared with Windows worms
using system vulnerabilities.
Interestingly, most of the malwares target Symbian OS
(283 malwares) where only 4 Windows Mobile and 2 Java
ME malwares were recognized. The payload of the Win-
dows Mobile and Java ME malwares included remote ac-
cess, file deletion, and abuse of the SMS in order to charge
high service usage rates.
ComingbacktoFigure1, malwareappearancedecreased
starting from the middle of the year 2006. Until end of
2008, only about 100 new malwares appeared while be-
tween the same time span from end of 2004 to middle of
2006 about 300 emerged. The reason for this can be seen
in the certification system of Symbian OS 3rd where de-
vices running this operating system version gained more
and more market share at this time. Since this OS version is
not vulnerable to the former malware and less possible vic-

Page 4

Smartphone Malware Propagation
285
58
23
4
22
0
50
100
150
200
250
300
Installer BluetoothMMS Memory
Card
File
Injection
Other
Count
Figure 3: Malware propagation
tims were targetable, this platform seemed less attractive.
Only the news that a spyware got certified for Symbian OS
3rd, called FlexiSpy [25], recalled the existing threat to this
new age of smartphone OS.
Besides the recognized malware “in the wild” several re-
search activities aimed for bypassing the security systems
of smartphones. One of the latest work of Collin Mulliner
resulted in the ability to bypass the security mechanisms of
Symbian OS 3rd which he presented on Black Hat Confer-
ence 2008 in Japan8. Short after this, in February 2009, the
first malware targeting Symbian OS 3rd appeared using a
valid certificate9.
4 Software Engineering Aspects of Android
For continuing the evolution of smartphone malware by
adding a new target platform we need to discuss essential
characteristics of Android OS which we already did in [4].
Therefore, we present an excerpt from [4] in this section
where we focus on discussing possible ways to develop na-
tive Linux software for Android. This will be exploited in
the following section in order create malware.
4.1 Android Linux Application Develop-
ment
From a Linux perspective, Android provides a complete
operating system running on an ARM-Architecture. Com-
pilingsoftwareforARMrequiresaspecificenvironment. In
followingsections, wewilldescribeapossiblewayforcom-
piling software successfully within an ARM-compatible en-
vironment. Additionally, we present relevant information
8http://mulliner.org/symbian/feed/
CollinMulliner_Exploiting_Symbian_BlackHat_Japan_
2008.pdf
9http://www.f-secure.com/weblog/archives/
00001609.html
on the operating system level and describe how to bridge
Android Java applications to Android native Linux applica-
tions.
4.1.1Base Environment
Ubuntu i686 GNU/Linux [3], a Linux-distribution provided
and supported by Canonical, provides the basis for all fur-
ther steps. Based on the Intel-architecture, a vast amount of
tools, especially for creating and compiling software, can
be obtained through Ubuntu’s package repositories.
4.1.2 Scratchbox Cross-Compilation Toolkit
Scratchbox [2] not only provides the necessary compilers
and linkers, it also provides a complete environment simu-
lating an ARM platform-based operating system. All tools
compiled within this environment can be tested immedi-
ately giving a very fast feedback to the developer. Once the
Ubuntupackagerepositoryhasbeenextendedbytheofficial
Scratchboxrepository, allnecessaryfilesforScratchboxcan
be easily installed via Ubuntu’s package management tools.
Scratchbox offers a wide variety of possible compilers, in
different versions and characteristics. After installation, a
user account has to be created for use within the Scratch-
box environment. Shortly after logging into the new en-
vironment, preliminary steps are required: select the de-
sired compiler and add additional tools if wanted (strace,
gdb). From this point, source code can be compiled as
usual, no specific parameters have to be provided. The host
and build type are distinguished automatically, standard lo-
cations for installing binaries, libraries, etc. are provided.
As longas thegiven sourcecode is ARM-compatible, it will
most likely compile within Scratchbox without any signifi-
cant problems. Having successfully compiled all files, these
can be packed into an archive for being transferred to the
Android environment for deployment.

Page 5

4.1.3Important Facts for Native Development on An-
droid
Filesystem Specifics
Google provides an ARM Linux with a filesystem layout
which greatly differs from usual Linux filesystem layouts:
• System relevant files are found in the System
image, mounted to /system (binaries are, for
the most part, found in /system/bin, libraries
reside in /system/lib, configuration files in
/system/etc, etc.)
• User data relevant files and applications reside within
the user data image, mounted to /data.
Handling these changes does not require much adaptation.
4.1.4Bridging Between Java and Linux
For creating a Android malware that is distributed via the
corresponding online store10, Java to C communication
might get necessary, at least to start the malware. There-
fore, we present two possible solutions - Java Native Inter-
face (JNI), a commonly accepted standard in the Java devel-
opment community, and named pipes which are commonly
used on unixoid systems for simple inter-process communi-
cation.
Java Native Interface (JNI)
JNI is used to call native functions of the underlying operat-
ing system. Using this interface, the developer risks losing
the platform independence of Java unless the native call ex-
ists on all intended platforms. At the moment, JNI is not
supported on Android although it is used across the system.
Following Romain Guy, an Android developer at Google,
Android currently uses JNI only for the framework and not
for the applications [1]. Nonetheless, Google seems to be
working on a native SDK officially providing JNI calls.
Despite the official Google statement that JNI is cur-
rently not supported for user applications and won’t work,
we have successfully compiled a Java application which
uses a custom JNI shared library. It was possible to install
and run the application on the retail G1 without any further
modification. Thenativecomponenthasbeenpackagedinto
an APK as a raw binary resource and unpacked upon first
execution of the Java program. After doing so, it is possi-
ble to load the shared object as a JNI library via invoking
java.lang.System.load(String filename).
From our point of view, JNI is rather hard to implement,
since compiling a shared library for Android is a challeng-
ing task because of the unusual page alignment. But, it
10Android Market, http://market.android.com
is most probably going to become the only official way to
include native code in Android applications, and also has
shown good performance.
Pipes
Using pipes is a commonly used technique in Linux and
Unix systems to allow communication between separated
processes.
For creating named pipes the command mkfifo can be
used. Additional information on pipes can be found in the
correspondingman pages. Using pipeson Androidfor com-
munication between Java and native executables is rather
straight-forward, since Java provides a lot of convenient
writer, reader, and stream classes. But, when it comes to
deployingandexecutingthebinaryintherestrictedenviron-
ment where an application can only write to its own folder,
this approach requires decent programming skills. The pipe
technique is much more complex in its deployment than
JNI, but it gives the developer a possibility to start a per-
sistent daemon on a Linux layer while being independent
from the Dalvik application lifecycle.
5Creating Android Malware
We exploit the aforementioned techniques in order to
create a “social engineering”-based malware. The concept
of this malware bases on the use of a malicious Linux ap-
plication packed into the installation file of a valid Android
application. The payload of this malware can be various,
where examples are shown next on.
First of all, a hosting application is needed that is
created as standard Android Java application. This appli-
cation can consist of a game or tool containing basically
only few lines of code that are important for getting the
malware run. The malicious Linux binary itself is packed
as “raw resource” into this Java application, e.g as .png
file, which can be seen on Figure 5. After installation,
the Java application has to be executed once in order
to rename the resource file into the appropriate binary.
After renaming the file, the file has to be made executable
which is currently impossible from within Java.
is where the sources of Android OS are needed - using
the Android Build System instead of Ant, it is possible
to utilize the class android.os.Exec, which is not
included in the SDK classpath. It allows execution of native
binaries as a subprocess of the Java application. Using
Exec.createSubprocess("/system/bin/sh",
...), it is possible to start the Linux shell and utilize
chmod to make the binary executable.
the application can be launched on a retail G1 Android
smartphone.
This
Afterwards,