Android SMS Malware: Vulnerability and Mitigation

Abstract

In this paper, we study some messaging design decisions which resulted in a set of vulnerabilities in the Android operating system, and we demonstrate how a malware application can be built to abuse these vulnerabilities. The application presents itself as a regular SMS messaging application and uses its basic permissions to send/receive short messages. Since many operators worldwide provide services that allow users to transfer credits/units through SMS, the application abuses this service to transfer credits from users illegally. The "permission" subsystem, the "broadcast receiver" subsystem, and the message-sending mechanism contribute to forming a haven for SMS malware by granting them absolute control over sending, receiving, and hiding SMS messages. Accordingly, the malicious application hides any acknowledgments from the telecom operator that might appear after a credit transfer transaction. This enables malware to drain the balance of the attacked user and has the potential to cause damage to a large number of users as well as telecom operators. The application was demonstrated on a local operator and it successfully passed standard screening procedures that claim to catch malware. A set of possible solutions are also presented in order to mitigate the risks of such attacks.

Full text

Android SMS Malware: Vulnerability and Mitigation
Khodor Hamandi Ali Chehab Imad H. Elhajj Ayman Kayssi
Department of Electrical and Computer Engineering
American University of Beirut
Beirut 1107 2020, Lebanon
{kmh09, chehab, imad.elhajj, ayman}@aub.edu.lb
Abstract— In this paper, we study some messaging design
decisions which resulted in a set of vulnerabilities in the
Android operating system, and we demonstrate how a malware
application can be built to abuse these vulnerabilities. The
application presents itself as a regular SMS messaging
application and uses its basic permissions to send/receive short
messages. Since many operators worldwide provide services
that allow users to transfer credits/units through SMS, the
application abuses this service to transfer credits from users
illegally. The “permission” subsystem, the “broadcast
receiver” subsystem, and the message-sending mechanism
contribute to forming a haven for SMS malware by granting
them absolute control over sending, receiving, and hiding SMS
messages. Accordingly, the malicious application hides any
acknowledgments from the telecom operator that might
appear after a credit transfer transaction. This enables
malware to drain the balance of the attacked user and has the
potential to cause damage to a large number of users as well as
telecom operators. The application was demonstrated on a
local operator and it successfully passed standard screening
procedures that claim to catch malware. A set of possible
solutions are also presented in order to mitigate the risks of
such attacks.
Keywords - Android; Vulnerability; Malware; SMS; credit
transfer; Permission; Broadcast Receiver
I. INTRODUCTION
The digital mobile telecommunication is now in its third
decade and is steadily progressing. The advancement in
telecom has touched all its components including the mobile
stations. These mobile stations are cellphones that were
meant originally to do phone calls over Circuit Switched
(CS) networks and to provide basic text services like the
Short Message Service (SMS). These limited-features
devices evolved to become smartphones with enhanced
capabilities and this led to their wide proliferation across the
globe. In 2011, reports estimated that close to 500 million
smartphones were shipped, which represents an increase of
more than 60% over 2010 and at the same time representing
over 30% of all shipped mobile phones [1, 2]. Among these
smartphones, over 48% were based on the Android operating
system (OS) [3]. Moreover, by 2011, three billion mobile
applications were downloaded [4], while in 2012, 1.5 billion
applications are downloaded each month [5]. Android is, by
design, an open OS; users are able to access its source code
and can use the publicly-available application programming
interfaces (API) to build applications and publish them on
the Android application market [5]. This philosophy has
enriched the Android market with over 675,000 applications
by September 2012 [6], but has opened the door for a large
variety of malware. In fact, eight million new mobile
applications were identified by McAfee as malware between
April and June of 2012 [7]. The report [7] added that the
newly-discovered problems emanated from: SMS-based
malware, mobile botnets, spyware, and destructive Trojans
[8]. Trojan!SMSZombie, an SMS android Trojan, discovered
in July 2012, was able to infect 500,000 phones in China.
Many financial transactions and payments are processed
using SMS in China; the ability to intercept SMS payloads
and to have the privileges to send SMS messages has granted
this Trojan the capability to execute numerous attacks [9]. In
September 2012, a malicious Android game application (or
simply app) was detected and its developers were fined
77,500 USD. This app used SMS in order to make users
subscribe to a non-free service and was estimated to have
collected 397,000 USD [10]. Also in the same month,
FakeInst was discovered. This Trojan masquerades as a basic
text exchange app while secretly subscribing to premium rate
services by sending SMS messages silently. This Trojan was
reported to have stolen 10 billion USD [11].
In this paper, we discuss the main features and
vulnerabilities of the Android OS that allow the development
and infection of SMS malware. In addition, we demonstrate
how Android-based smartphones can be exploited by
deploying a malware that uses the SMS service as its
medium of operation. Typically, this type of malware relies
on vulnerabilities from two parties: the first is telecom-
operator dependent, while the other is Android-specific. For
the former, a good number of mobile operators use SMS text
messaging to transfer units/credits between two mobile users
without requiring any form of validation/authorization
beyond the message being sent from the phone. The
units/credits refer to the user balance or airtime that can be
used to make phone calls, to send/receive SMS messages, or
to access the Internet. For example, a user that wants to
transfer units builds a structure-defined text by entering two
elements: the amount they want to transfer from their
balance and the mobile number of the beneficiary. After
drafting the message, the user sends it to a specific number
and the transaction is completed by the operator through
balance transfer. This can be extended to other potential
financial transactions that are made through SMS as well. As
for the Android-specific vulnerabilities, the problem consists
of two design features relating to the way SMS messages are
sent and received on Android. To demonstrate these
vulnerabilities, we were able to build and test a proof-of-
2013 27th International Conference on Advanced Information Networking and Applications Workshops
978-0-7695-4952-1/13 $26.00 © 2013 IEEE
DOI 10.1109/WAINA.2013.134
1004

concept malicious mobile app. This malware masquerades as
a normal messaging application while in reality it would be
covertly conducting credit transfers without user knowledge,
while at the same time suppressing any confirmation
messages received from the operator.
Based on a survey we performed, we identified more
than 20 mobile operators that use such a service or a
variation of it for unit/credit transfer between users. These
operators are spread geographically in 28 countries (some
operators have presence in more than one country). As such,
the number of vulnerable users and operators at risk is
significant.
The rest of this paper is organized as follows. Section 2
presents related work. Section 3 presents some Android
background relevant to the work done, and section 4 presents
our application design. We detail the application testing and
analysis in sections 5 and 6, respectively. Finally, we present
our proposed solutions in section 7, and we conclude the
paper in section 8.
II. RELATED WORK
Golde was able to find a number of vulnerabilities in
SMS implementations that are used by the majority of the
feature phones on the market despite the closed-source
nature of these phones’ operating systems [12]. He showed
how SMS vulnerabilities can be used to disconnect the phone
from the network, end calls, crash, and reboot. In addition,
Denial-of-Service cases were also seen because of some tests
that made the phone crash before the SMS is acknowledged,
so the network was under the impression that the message
did not get delivered and hence continuously re-transmitted
it. Moreover, he showed how a SIM Data Download (a
management tool used by operators to remotely manage SIM
cards), through which SMS is directly sent to SIM (or
USIM), can be manipulated so the attacked phone will send
SMS from the phone to any number the attacker specifies, a
process through which user units/credits can be drained
slowly. Furthermore, he showed how this last feature can be
used to carry out a Denial-of-Service on a specific mobile
number. Traynor et al. demonstrated how SMS messaging
can be malicious and harmful to the network [13]. Many
mobile operators provide an Internet-based SMS service
through which users can send SMS messages directly from
the web to a mobile phone connected to the operator
network. This service, if exploited, can lead to Denial-of-
Service and thus prevent mobile users from making phone
calls in a targeted city. Mulliner et al. presented a general
framework that can be used specifically with smartphones
for testing and monitoring of SMS messages [14]. Although
many smartphones were investigated in [14], our main
interest is the Android-based ones. In their work, they
introduced a way to inject messages and monitor telephony
by modifying the serial line that the Radio Interface Layer
uses to communicate with the modem.
From a different perspective, the Android permission
system has been under study and proved to be vulnerable to
privilege escalation attacks. Davi et al. presented a method
whereby applications can place phone calls without having
such a privilege [15]. Although they added that this problem
was solved, they showed a proof-of-concept scenario
through which much more harm can be done whereby a
“non-privileged vulnerable application” was used to execute
Tcl commands, which ended up sending some 50 SMS
messages to any number the attacker specified. As a result,
not understanding the difference between different Android
permissions can put users at risk. This was also confirmed in
[16] where an online survey and interviews were conducted
with a group of Android users and the results showed that
only a minority of these users were able to understand the
reason for and the difference between the various
permissions required by applications. For SMS in particular,
it is very important to understand the difference between the
four available permissions: “SEND_SMS”,
“RECEIVE_SMS”, “READ_SMS”, and “WRITE_SMS”.
In [17], 1,260 Android malware samples were captured
and evaluated. The main focus was the mechanisms through
which the malware propagate, the activation procedures, the
permissions required, and the events also known as the
“broadcasted intents” that will be listened to by the malware.
Results have shown that 21 malware families of the 49
captured listen for incoming SMS messages, the second most
used broadcast after boot broadcast. Even more, 45.3% of
the malware samples “tend to subscribe to premium-rate
services with background SMS messages.” In addition, some
were found to do some filtering of SMS messages and even
some were discovered to reply to the received messages.
Furthermore, the antiviruses were not able to demonstrate a
full ability to detect malware beyond a best case detection
rate of only 79.6%.
In addition, the authors of [18] were able to develop a
malware in the form of a native “Linux binary” that can be
stored in an image, for example, and that can be used to
bypass Android permissions. Bypassing a specific
permission allows an intruder to do any operation, including
sending SMS messages.
III. ANDROID BACKGROUND
Android provides developers with a Software Developer
Kit (SDK) that exposes the API needed to build applications.
A comprehensive documentation along with the SDK is
provided on a dedicated website [19]. In what follows, we
will describe selected topics from the SDK that are relevant
to our work.
A. Activities
In Android, an activity is an essential component for an
application. Every application should at least have one
activity, the “main” activity. Usually, an application has
many activities and it can start another activity, where each
activity holds a state (e.g. stopped or paused). An activity is
the component that provides a user with a graphical user
interface (GUI) [19].
B. Services
Services are components in Android that do not provide
any user interface, and usually run in the background
conducting long running operations. Services are started by
other application components, so an activity or a service can
1005

start a service, and a service life is in
d
component that started that service [19].
C. Permissions
For security reasons, some subsets of
accessible by an application without acquiri
n
it. Usually, this permission-granting m
u
declared in a “Manifest.xml” file when
application. These permissions can be used
such as filtering in the Android store, noti
f
installation time only), and guarding these
c
malicious use [19].
D. Broadcast Receiver
Broadcast receiver is a mechanism t
h
Android forwards data to applications. T
h
these broadcast receivers is inter-
p
rocess co
m
tracking of specific events (e.g. arrival of a
n
the phone). Applications declare staticall
y
their interest in receiving a certain type o
f
accordingly the OS will try to deliver th
when available. For the procedure of sen
d
Android uses “Intents” which are data stru
c
be passed to “sendBroadcast”, for example.
two types of Broadcast Receivers: normal
a
normal ones are asynchronous and there is
according to which users registered to a
receive the data. As for the ordered ones, a
p
to require from the system to deliver the in
f
app in a certain sequence, and as such, som
e
information before others. This feature allo
capture and possibly modify the carrie
d
reaches lower-priority consumers. In this
c
prevent other a
p
ps from getting specific da
t
received data [19]. For a given broadcast, a
of all the registered apps:
Ըൌ
ሼܽ
଴
ǡܽ
ଵ
ǡܽ
ଶ
ǡܽ
ଷ
ǡǥሽ
where the a
i
are the apps.
If the broadcast is normal, the assumptio
n
elements will obtain the exact unmodif
i
information. On the other hand, if the bro
a
there is no guarantee that more than a
s
ingl
e
original information. According to our ex
p
app to ensure that it will obtain an ordered
to be the first application to register to the d
e
the highest priority. It is worth noting that a
n
for an intent with any priority it specifies w
i
or limitations after being given permission.
E. SMS Manager
The SMS manager, part of the Androi
d
p
rovides developers with the necessary f
u
messages. In order to send a text messag
e
getting the right permissions, an app can se
n
at any time by a simple function call. The
send SMS messages is “sendTextMessage”
d
ependent of the
the API are not
n
g permission for
u
st be statically
developing the
for many reasons
f
ying the user (at
c
ritical APIs from
h
at defines how
h
e main usage of
m
munication and
n
SMS message to
y
or dynamically
f
information and
e requested data
d
ing information,
c
tures that should
Android defines
a
nd ordered. The
no defined order
broadcast would
p
riority can be set
f
ormation to each
e
apps will get the
ws developers to
d
data before it
c
ase, an app can
t
a by aborting the
set is maintained
n
is that all the set
i
ed copy of the
a
dcast is ordered
e
app will get the
p
eriments, for an
broadcast, it has
esired inten
t
with
n
app can register
i
th no constrain
t
s
d
telephony stack,
u
nctions to send
e
, and apart from
n
d a text message
main function to
[19]. Calling the
send function displays no notific
a
sending process is seamless and tra
n
F. Logcat
Android has a special logging
s
OS stores the logs in several cir
c
events, and main). Developers can
b
to get information from the system
a
that purpose, a special command (
tool called the Android Debug Bri
d
from the targeted buffer [19].
IV. APPLICATIO
N
In this section, we describe the
p
application. As stated previously, t
h
to look like a normal SMS appli
c
required ability to send and receiv
e
many such applications for Androi
d
are popular due to the fact that us
e
p
lain SMS application with more
friendly SMS applications. Th
e
applications demonstrates the feasi
b
a malicious messaging application
by masquerading as a user-friendly
S
Malicious code was added to t
h
specifically target the unit/credit t
r
service. For that purpose, the app
single activity and three service
c
Figure 1.
Figure 1: The components o
f
A. Main Activity
The Main Activity component
user interface to read and send S
M
p
hones, SMS messages are inserte
d
queries to the Content Provider c
o
this component is the base compo
n
Listen Service and the Sender Ser
v
time. On the other hand, the Boot
after the first launch of the main act
i
B. Listen Service
This component listens for inco
m
takes actions according to pre-de
f
service needs to listen for incomi
n
registered as a broadcast receiver.
Upon receipt of an SMS mes
s
component gets notified. Incoming
checked. If the newly receive
d
acknowledgment related to the “ill
e
the component allows the message
a
tions on the phone; the
n
sparent to mobile users.
s
ystem through which the
c
ular buffers (for radio,
b
enefit from these buffers
a
nd debug their apps. For
logcat) can be used in a
d
ge (ADB) to extract data
N
DESIGN
p
roof-of-concept malware
h
e application is designed
c
ation that has the basic
e
SMS. There are in fact
d
use
r
s, and many of them
e
rs can replace the native
sophisticated and use
r
-
e
popularity of these
b
ility and ease with which
can be deployed simply
S
MS application.
h
e application in order to
r
ansfer through the SMS
lication needs at least a
c
omponents as shown in
f
the applicatio
n
has the entire graphical
S messages. On Android
d
and read using database
o
ntent://sms
/
. In addition,
n
ent that will launch the
v
ice, at least for the first
Service runs on its own
i
vity.
m
ing SMS messages and
f
ined criteria. Since this
n
g messages, it has to be
s
age from the radio, this
messages are parsed and
d
message is not an
e
gal” unit/credit transfer,
to pass unmodified, or it
1006

can directly insert it in the messaging database. If, on the
other hand, this message is related to the malicious activity,
it will be suppressed and will never reach the database or any
other application. It is important to note that the broadcast
that handles this transaction is an ordered broadcast.
Accordingly, the priority option available for a registered
broadcast receiver makes the suppression very efficient. This
feature might be useful in filtering spam SMS messages, but
based on its proven potential to cause harm, it tends to
introduce a vulnerability in the Android OS. It is worth
noting that the “Listen” service is made a sticky service; it
will rerun, even if the user intentionally terminates it.
C. Sender Service
This component handles the unauthorized sending
process of the SMS application. This service works in a
silent manner. This is guaranteed by conducting a malicious
action, such as a credit transfer, at random widely separated
time instants in order to make the attack non-deterministic
and undetectable by a simple observer of the phone activity
from the operator side. This component will prevent its
messages from being stored in the database; the user will not
be able to track when the transfer was made by looking at the
messaging database. In addition, this service is also sticky,
similar to the Listen Service, and will rerun on its own even
if it is intentionally terminated by the user. Several
refinements can be added to this service to make it stealthier;
for example, it can monitor the activity level of the user and
then execute the malicious transfers during the busiest
periods when the user is actually making phone calls and/or
sending SMS. This will lower the likelihood of the user
noticing the reduction in credit.
D. Boot Service
This component is needed to make the previously-
mentioned services run at the launching of the OS. This is
achieved by registering as broadcast receiver to
BOOT_COMPLETED event.
E. Permissions
The minimum permissions needed to carry out the
malicious activities are the “RECEIVE_SMS” and
“SEND_SMS” which are requested by SMS applications.
The most popular SMS applications surveyed on the Android
market, at the time of writing of this work, additionally use
the “READ_SMS” and the “WRITE_SMS” permissions.
Therefore, the request for these permissions is not unusual
and would not alert the user to the malicious behavior.
V. TESTING
In what follows, we demonstrate how we tested the
application, the types of security checks that were performed,
and the results that were obtained.
A. Implementation
Testing was conducted using two mobile phones. Since
the application needs an Android-based smartphone to run, it
is not a must to use two smartphones. We used a Samsung
Galaxy SII smartphone and a Sony Ericsson K770i feature
phone, as shown in Figure 2.
The application was installed on the “victim” phone, a
Samsung Galaxy SII. The Android OS version pre-installed
on this phone is 2.3.5 (Gingerbread), and the kernel version
is 2.6.35. On the other hand, the Sony Ericsson holds the
SIM card of the attacker which will get all the transferred
credits. The credit transfer operation in the experiment is
done by building a message that has the following format:
ܴ݁ܿ݁݅ݒ݁ݎܰݑܾ݉݁ݎ צ ܶ צ ܣ݉݋ݑ݊ݐ
This format is operator specific, and corresponds to one
of the operators where the experiment was conducted. The
message is usually sent to a special dedicated 4-digit number.
Once the message is sent, the credits (Amount in US Dollars)
are removed from the sender balance and added to the
receiver balance. Finally, both sender and receiver get a
message informing them that the credit transfer transaction
was completed. It is worth noting that many operators charge
transaction fees for this transfer. Therefore, we suspect that
most operators would not, for financial purposes, suspend
this service despite all its security concerns.
By design, the victim must not be informed of the
transaction, accordingly the sent and received messages
related to this operation are suppressed. We relied on the
logcat tool to check that the operation was accomplished
correctly. The output from the “main” buffer showed that the
transfer is being carried out. A sample output is shown in
Figure 3. Additional output from the “radio” buffer having
the same timestamp confirmed the operation and a sample is
shown in Figure 4.
At the time of writing this paper, the most downloaded
Android SMS applications have millions of users. If any of
these applications is designed to exploit the SMS credit
transfer, or any other type of financial transactions, it can
cause severe damage in a very short period of time. For
example, the impact of 10 million users of a malware
exploiting less than 1% of its users, could raise around
$100,000 per month, by transferring only $1 per month per
user. Such a small amount has a very low impact on a single
user and hence it has a good chance of going unnoticed.
Figure 2: The two used phones in our test, left: Samsung Galaxy SII, right:
Sony Ericsson K770i [20]
1007

Figure 3: Main buffer showing logs of the receipt and
s
Figure 4: Radio buffer showing logs of the sending an
d
B. Antimalware
In order to check if this malware is de
available service called “Virus Total” was
u
p
rovides an online scanning for URL
s
including Android application files, using
a
antimalware products currently available o
n
The report that was generated confirms th
a
antimalware packages was able to detect
t
application is malicious. This is expected si
n
tools are signature-based.
C. Android Market (Play Store)
The final test was to check the respons
Market (Play Store). The test goal is to c
h
store can detect that the application ex
e
activities. For that purpose and with a
guarantee that the risk of accidental release
o
is minimal, the application was pu
b
lished
s
very short period of time; we then quickly
order to make sure that it does not get do
w
user.
VI. ANALYSIS
Three Android SMS Trojans were prev
i
China and the UK. Such malware was e
s
stolen millions of dollars [9-11]. In previ
o
demonstrated that at least 28 countries
a
different type of SMS attack targeting a p
r
mobiles credit transfer, resulting in ste
subscribers if exploited. This leads to que
cause of the attack. As can be remarke
d
multifaceted and many factors contribute to
The permission system incorporated in
A
contributor to the risk. Each SMS appli
c
granted the permission to send/receive S
M
this decision is permanent. In this view,
t
work on guaranteeing the safe arrival
o
sending of SMS messages. Instead,
b
y usi
n
system, these functions are delegated to u
s
applications. Accordingly, it is assumed tha
t
and using an application, the user has given
s
uppression of SMS
d
receiving of SMS
e
tectable, a freely
u
sed. This service
s
and for files,
a
set of the major
n
the market [21].
a
t none of the 43
t
he fact that this
n
ce most of these
e of the Android
h
eck whether the
e
cutes malicious
modification to
o
f the application
s
uccessfully for a
unpublished it in
w
nloaded by any
i
ously detected in
s
timated to have
ous sections, we
a
re at risk of a
r
otocol for inte
r
-
aling credits of
e
stioning the roo
t
d
, this attack is
its feasibility.
A
ndroid is a main
c
ation has to be
M
S messages but
t
he OS does not
o
r the approved
n
g the permission
s
ers’ downloaded
t
by downloading
a level of trust to
this application and is fully aware o
and their implications. Based
vulnerabilities, it can be implied
require a high level of user awaren
knowledge typical users might not
a
In addition, as we demonstr
a
operation is not visible to the mobi
l
never notified if an SMS is se
n
seamlessly once permissions are gr
a
worth comparing this to other m
o
where an SMS cannot be sent wit
h
by taking action such as clicking in
a
The other root cause is the
h
messages, which is done using
discussed previously, this gives a
m
ability to suppress or modify a payl
o
installed on the phone or for the use
r
In fact, our app used the
downloaded SMS applications acq
u
minimal, and yet the app was ca
p
harmful transactions
b
ecause of t
h
decisions that eventually led to seri
o
VII. PROPOSED S
O
In this section, we propose
temporary solutions to SMS-
b
ase
d
address the following issues:
• The permissions that give a
n
control over the time, the des
t
of sending and receiving proc
e
• The unsafe application-depen
d
• The ability to hide or mo
d
accomplished through the use
Accordingly, the following are
order to address these vulnerabilitie
s
• The user must always
b
e n
o
receipt of an SMS message.
• Applications must be preve
n
receiving of SMS (and pre-e
m
from receiving messages)
b
y
s
• The user must grant explicit
p
send transaction, not onl
y
application at installation time
Based on [14], a monitoring
s
monitor incoming and outgoing S
M
the modem AT commands. Fo
r
command means that an SMS mes
sent an application-level notificati
o
address the uncontrolled hidden s
SMS, but would not stop them. In
the Android phones be rooted.
As for receiving SMS message
s
install a trusted application
b
ef
o
application is installed, and assigni
n
highest priority for the broadcast re
c
installed and having the highest pri
o
notification of arrival of SMS m
f the granted permissions
on alread
y
-discovered
that these assumptions
ess to potential threats; a
a
lways possess.
a
ted above, the sending
l
e subscriber. The user is
n
t, and this can happen
a
nted at install time. It is
o
bile operating systems,
h
out the user intervention
a
notification box.
h
andling of the received
ordered broadcasts. As
m
alicious application the
o
ad for other applications
r
.
permissions that most
u
ire, which is considered
p
able of performing very
h
e above Android design
o
us vulnerabilities.
O
LUTIONS
practical permanent or
d
malware. The solutions
n
application an absolute
t
inatio
n
, and the decision
e
sses of SMS messages.
d
ent sending of SMS.
d
ify the SMS payloads,
of ordered broadcasts.
recommendations for in
s
:
o
tified/interrupted of the
n
ted from controlling the
m
pting another application
s
etting its own priorit
y
.
p
ermission for every SMS
y
permission for the
.
s
ystem can be added to
M
S messages by filtering
r
example, the +CMT
s
age has just arrived and
o
n. This solution would
ending and receiving of
addition, it requires that
s
, a solution would be to
o
re any SMS message
n
g to this trusted app the
c
eiver. Being the first app
o
rity, this app will get the
e
ssages before all other
1008

applications, and will be able to notify the user of the arrival
of SMS messages. This solution should work on all Android
versions. It can be further enhanced by implementing the
logic of the app as middleware that resides between the OS
and all the other applications. This middleware would listen
to all installed and removed applications and then checks for
apps that request a permission to receive SMS messages.
Starting with Android version 4, a feature was added in the
OS to allow an application to send a broadcast to a particular
application. Hence, the middleware gets the permission to
broadcast SMS. Once an SMS is received, the middleware
receives the message first and aborts the broadcast. Then it
sends the SMS message to each of the n Apps, one by one.
This would guarantee that none of the apps can hide, modify,
or monopolize the receipt of SMS messages.
Finally, to mitigate the vulnerability of sending
unauthorized SMS messages, Android can be patched in
order to request user approval at each sending attempt.
VIII. CONCLUSION
In this paper, we studied the Android design features that
led to the widespread proliferation of SMS malware. Our
analysis highlighted three features that contribute to the
vulnerability: the permission system, the broadcast receiver
system and the sending process. The permissions granted to
an app were demonstrated to give the app absolute ability to
perform actions while no further checks are made. As for the
broadcast receiver, the problem is in the ordered types of
broadcasts which allow an app to drop, hide, or modify
payload. The sending process used in Android is a function
call that does not get approval for the sending operation. This
allows apps to send unauthorized SMS messages. These
design decisions, which can lead to vulnerabilities in the
Android OS, were highlighted by presenting the design,
development, and testing of a malicious prototype
application that can be deployed on Android-based
smartphones. This application appears as a regular SMS
application while in the background it is using the SMS-
based credit transfer service to carry out illegal transfers. We
implemented and tested our application on an actual Android
phone and the tests confirmed the objectives. The application
was also checked by antimalware tools that were unable to
detect any infection. In addition, the malicious application
was successfully published on the official Android market.
In summary, such an application would be difficult to detect
and would cause substantial losses. Finally, we presented a
number of possible practical solutions in order to mitigate
the effects of the SMS vulnerabilities.
ACKNOWLEDGEMENT
This research is funded by TELUS Corporation. The
authors would like to acknowledge the help of Mr. Gerard
Touma who conducted the survey on mobile operators.
REFERENCES
[1] IDC. (2012). Smartphone Market Hits All-Time Quarterly High Due
To Seasonal Strength and Wider Variety of Offerings, According to
IDC. [Online]. Available:
http://www.idc.com/getdoc.jsp?containerId=prUS23299912
[2] Strategy Analytics. (2012). Apple Becomes World's Largest
Smartphone Vendor in Q4 2011. [Online]. Available:
http://www.strategyanalytics.com/default.aspx?mod=pressreleasevie
wer&a0=5170
[3] Canalys. (2012). Smart phones overtake client PCs in 2011. [Online].
Available: http://www.canalys.com/newsroom/smart-phones-
overtake-client-pcs-2011.
[4] Daniel Ionescu. (2011). Google Brags About Android Market Stats.
[Online]. Available:
http://www.pcworld.com/article/225299/google_brags_about_android
_market_stats.html
[5] Android. (2012, Sept). Android, the world’s most popular mobile
platform. [Online]. Available:
http://developer.android.com/about/index.html
[6] Scott Lowe. (2012). Google Play celebrates 25 billion downloads
with 25 cent apps, discounted books, music, and movies. [Online].
Available: http://www.theverge.com/2012/9/26/3409446/google-play-
25-billion-downloads-sale
[7] Jeff Drew. (2012, Sept). Malware growth maintains rapid pace as
mobile threats surge. [Online]. Available:
http://www.journalofaccountancy.com/News/20126400.htm
[8] Hindustan Times (2012, Sept). Android users prime target of
malware: McAfee. [Online]. Available:
http://www.hindustantimes.com/technology/IndustryTrends/Android-
users-prime-target-of-malware-McAfee/SP-Article1-925986.aspx
[9] Jon Russel. (2012). SMS Payment Virus Identified in China, 500,000
Android Device Infected. [Online]. Available:
http://thenextweb.com/asia/2012/08/19/stealth-sms-payment-
malware-identified-chinese-app-stores-500000-android-devices-
infected/
[10] Charlie Osborne. (2012, Sept). SMS malware firm ordered to
compensate victims. [Online]. Availability:
http://www.zdnet.com/sms-malware-firm-ordered-to-compensate-
victims-7000003639/
[11] Sara Yin. (2012, Sept). Will Your Android Device Catch Malware?
Depends on Where You Live. [Online]. Available:
http://securitywatch.pcmag.com/none/302362-will-your-android-
device-catch-malware-depends-on-where-you-live
[12] N. Golde, “SMS Vulnerability on Feature Phones,” Master Thesis,
Berlin Institute of Technology, 2011.
[13] P. Traynor, W. Enck, P. McDaniel, and T. L. Porta, “Exploiting Open
Functionality in SMSCapable Cellular Networks,” in Journal of
Computer Security (JCS), 2008.
[14] C. Mulliner, C. Miller, “Injecting SMS Messages into Smart Phones
for Security Analysis,” in Proceedings of the 3rd USENIX Workshop
on Offensive Technologies (WOOT), 2009.
[15] L. Davi, A. Dmitrienko, A. Sadeghi, M. Winandy, Privilege
escalation attacks on Android. In Information Security, 2011.
[16] A. P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin, D. Wagner, (2012,
Feb.) “Android Permissions: User Attention, Comprehension, and
Behavior,” Not published. [Online]. Available:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-
26.pdf
[17] Y. Zhou, X. Jiang, “Dissecting Android Malware: Characterization
and Evolution,” in the 2012 IEEE Symposium on Security and
Privacy, 2012.
[18] A.-D. Schmidt, H.-G. Schmidt, L. Batyuk, J. H. Clausen, S. A.
Camtepe, S. Albayrak, and C. Yildizli, “Smartphone malware
evolution revisited: Android next target?” In Proceedings of the 4th
IEEE International Conference on Malicious and Unwanted Software
(Malware 2009), 2009.
[19] Android Developers, (2012, Sept). Android Developers. [Online].
Available: http://developer.android.com/index.html
[20] GSMArena. (2012). GSMArena.com - GSM phone reviews, news,
opinions, votes, manuals and more. [Online]. Available:
http://www.gsmarena.com
[21] Virus Total. (2012). VirusTotal - Free Online Virus, Malware and
URL Scanner. [Online]. Available: https://www.virustotal.com/
1009